Microservices architecture is an evolution of service-oriented architecture (SOA) principles applied to application design and development. Some key differences include: - SOA focuses on exposing application functionality as services at the enterprise level, while microservices focus on developing individual applications as a suite of independently deployable services. - Microservices are typically smaller, lighter weight services focused on a single task, as opposed to monolithic applications. They communicate with lightweight protocols like HTTP. - Microservices aim to support continuous delivery and deployment, with goals of automation, resilience, and loose coupling between services. - Individual microservices can be developed and scaled independently. This provides benefits like enabling continuous delivery and deployment. So in summary,

1. Micro Services
Prepared by – Ramesh Mavuluri

2. API – Application Programming Interface - It’s a way of making request into a
component.
Here the component means Model, Views, Controllers, Services, Plugins and Data
Access Objects …etc.
So a component that can be reused across multiple systems and applications can be
packaged and distributed as an API.

3. Developers are moving away from monoliths in favor of micro services
architecture. Why?
Because the main objective of the micro-services implementation is to split up the
application into smaller chunk of services and these services are very loosely coupled,
only communicate through APIs, and are less complex and thus smaller as they
generally focus only on a single functionality centered around a business capability of
the application.
It should be deployed independently on cloud and it helps us to achieve the
continuous delivery and integration.
Spring Cloud integrates the Netflix components in the spring environment in a very
nice way using auto configuration and convention over configuration similar to how
Spring Boot works.

4. Patterns in micro services architecture:
API Gateway:
1. Choose to build the application as a set of micro services
2. Decide how the application client’s will interact with the micro services
3. Micro services architecture, however each micro service expose a set of fine grained endpoints
Service Registry:
1. This will helps to determine the location of service instances to send the request to the
corresponding service
2. Netflix Eureka to register a service that are available to be registered in service registry server
and it can be identified through the router.
Service Discovery:
1. In the modern micro services based application typically runs in a virtualized environments
where the number of instances of a service and their location changes dynamically.
2. Each service can be identified using router that are registered with service registry server.

5. APPLICATION
Exposed API’s to the external world from application…!
DB

6. Traditional Monolithic Application: Micro services Application:
1 component 3 API’s 3 Components and 3
API’s
APPLICATION
1 2 3
Micro Service
Component
Micro Service
Component
Micro Service
Component
21 3
Break Down
Component
API’s
Ex: Developed using
Node JS
Ex: Developed using Java
Ex: Developed using
Python
Ex: Developed using Java
Component

7. DB
Client
WAR/EAR
Banking
Account
Transfer
…
Spring
Hibernate … etc.
In monolithic application, the entire application is a component and it consumes internal and third party api’s and expose
api’s to external world.

8. Monolithic Limitations:
1. Overloads your IDE & container
2. Obstacle to scaling development
3. Obstacle to frequent deployments
4. Modules having conflicting scaling requirement
5. Requires long term commitment to technology stack
Single DB Limitations:
1. Scalability
2. Distribution
3. Schema updates
4. O/R impedance mismatch
5. Handling semi structural data

9. Micro services architecture is really micro component architecture.
Micro Service
Component
Micro Service
Component
Micro Service
Component
21
Not all micro service
components expose api

10. Benefits of Micro services:
1. It tackles the problem of complexity
2. Service to be developed independently so developers are free to choose what ever
the technologies make sense.
3. Service to be deployed independently
4. Service to be scaled independently (you can deploy no of instances of each service
that satisfy its capacity and availability constraints)
Drawbacks:
1. One drawback in the name itself
2. Micro service is a distributed system so developers need to choose or develop inter-process
communication
3. Partitioned database architecture (Monolithic is single database)
4. Testing micro services application is also much more complex
5. Implementing changes that span multiple services

11. Sample Micro Service Architecture…!

13. API Gateway Capability Types:
1. Development Capability
 Configuration Management
 Micro services API design
 Micro services dev framework
 Micro services test management
 Container/Image creation
 Component discovery
2. Security Capability
 Authentication/Authorization
 Identity Management
3. Mediation Capability
 Service Discovery
 Registration
 Messaging/Content
 Routing/Aggregation(Map down stream request to upstream)
 Policy Enforcement (SLA, Audit Regulatory…etc.)

14. API Gateway Capability Types:
4. Deployment Capability
 Continuous Integration
 Continuous Delivery/Release Management
5. Monitoring Capability
 System Monitoring
 End user experience monitoring
 App performance monitoring
 Event Monitoring
 Logging
6. Analytics Capability
 Business Analytics
 Operational Analytics
 User Analytics
 Continuous Business Planning
7. Platform Capability
 Container Hosting
 Infrastructure As-a-service
 Platform As-a-service

15. Why Spring Boot and Spring Cloud are a good choice for Micro Services?
Spring Boot is the most popular and widely used Java framework for building Micro Services. These days many
organizations prefer to deploy their applications in a Cloud environment instead of taking all the headache of
maintaining a datacenter themselves.
But we need to take good care of the various aspects to make our applications Cloud Native. There comes the
beauty of Spring Cloud.
Spring Cloud is essentially an implementation of various design patterns to be followed while building Cloud
Native applications.
Instead of reinventing the wheel, we can simply take advantage of various Spring Cloud modules and focus on our
main business problem than worrying about infrastructural concerns.

16. Micro services Architecture via Netflix Components :
Operations Component Spring, Netflix OSS
------------------------------------------------------------------------------------------------
Service Discovery server Netflix Eureka
Edge Server Netflix Zuul
Central configuration server Spring Cloud Config Server
Dynamic Routing and Load Balancer Netflix Ribbon
OAuth 2.0 protected API's Spring Cloud + Spring Security OAuth2
Monitoring Netflix Hystrix dashboard and turbine

17. Major Components of Netflix :
1. Netflix Eureka - Service Discovery Server :
Netflix Eureka allows micro services to register themselves at runtime as they appear in the system landscape.
2. Netflix Ribbon - Dynamic Routing & Load Balancer :
Netflix Ribbon can be used by service consumers to look up services at runtime. Ribbon uses the information
available in Eureka to locate appropriate service instances. If more than one instance is found, Ribbon will apply
load balancing to spread the requests over the available instances. Ribbon does not run as a separate service but
instead as an embedded component in each service consumer.
3. Netflix Zuul - Edge Server :
Zuul is (of course) our gatekeeper to the outside world, not allowing any unauthorized external requests pass
through. Zulu also provides a well-known entry point to the micro services in the system landscape. Using
dynamically allocated ports is convenient to avoid port conflicts and to minimize administration but it makes it of
course harder for any given service consumer. Zuul uses Ribbon to look up available services and routes the
external request to an appropriate service instance.

19. Following are just a few of Spring Cloud modules that can be used to address
distributed application concerns:
Spring Cloud Config Server: To externalize configuration of applications in a central config server with the ability to update the configuration values without requiring to restart the
applications. We can use Spring Cloud Config Server with git or Consul or ZooKeeper as config repository.
Service Registry and Discovery: As there could be many services and we need the ability to scale up or down dynamically, we need Service Registry and Discovery mechanism so that
service-to-service communication should not depend on hard-coded hostnames and port numbers. Spring Cloud provides Netflix Eureka-based Service Registry and Discovery support
with just minimal configuration. We can also use Consul or ZooKeeper for Service Registry and Discovery.
Circuit Breaker: In micro services based architecture, one service might depend on another service and if one service goes down then failures may cascade to other services as well. Spring
Cloud provides Netflix Hystrix based Circuit Breaker to handle these kinds of issues.
Spring Cloud Data Streams: These days we may need to work with huge volumes of data streams using Kafka or Spark etc. Spring Cloud Data Streams provides higher-level abstractions
to use those frameworks in an easier manner.
Spring Cloud Security: Some of the micro services needs to be accessible to authenticated users only and most likely we might want a Single Sign-On feature to propagate the
authentication context across services. Spring Cloud Security provides authentication services using OAuth2.
Distributed Tracing: One of the pain-point with micro services is the ability to debug issues. One simple end-user action might trigger a chain of micro service calls, there should be a
mechanism to trace the related call chains. We can use Spring Cloud Sleuth with Zipkin to trace the cross-service invocations.
Spring Cloud Contract: There is a high chance that separate teams work on different micro services. There should be a mechanism for teams to agree upon API endpoint contracts so that
each team can develop their APIs independently. Spring Cloud Contract helps to create such contracts and validate them by both service provider and consumer.

20. What is the need for Spring Cloud Config and Vault?
Spring Boot already provides a lot of options to externalize configuration properties.
However, once the application is started you can’t change those property values at runtime. You need to update the properties and restart the
application to take those changes into effect.
In the micro services world, there could be a large number of micro services and multiple instances of those micro services are running. Updating
configuration properties and restarting all those instances manually or even with automated scripts may not be feasible. Spring Cloud Config
addresses this problem.
We can create a Spring Cloud Config Server which provides the configuration values for all of our micro services. We can
use git, svn, database or Consul as a backend to store the configuration parameters. Then we can configure the location of Spring Cloud Config
server in our micro service so that it will load all the properties when we start the application. In addition to that, whenever we update the properties
we can invoke /refresh REST endpoint in our micro service so that it will reload the configuration changes without requiring to restart the
application.
In our applications, we also need to configure various sensitive data like database credentials, keys, tokens etc. Obviously, we don’t want to store
them in plain text. A better approach would be to store them in an encrypted format and Spring Cloud Config Server provides the ability to encrypt
and decrypt the data. Even better we should use secure data storage tools like Vault. Spring Cloud also provides the integration with Vault so that
we can store any sensitive configuration properties in Vault.

21. What is Service Registry and Discovery?
Suppose we have 2 micro services catalog-service and inventory-service and we are running 2 instances of inventory-service at
http://localhost:8181/ and
http://localhost:8282/.
Now let’s say we want to invoke some inventory-service REST endpoint from catalog-service. Which URL should we hit?
Generally, in these scenarios, we use a load balancer configuring these 2 URLs to be delegated to and we will invoke the REST
endpoint on load balancer URL. Fine.
But, what if you want to spin up new instances dynamically based on load? Even if you are going to run only few server nodes,
manually updating the server node details in load balancer configuration is error-prone and tedious.
This is why we need automatic Service Registration mechanism and be able to invoke a service using some logical service id
instead of using specific IP Address and port numbers.
We can use Netflix Eureka Server to create a Service Registry and make our micro services as Eureka Clients so that as soon as we
start a micro service it will get registered with Eureka Server automatically with a logical Service ID. Then, the other micro
services, which are also Eureka Clients, can use Service ID to invoke REST endpoints.
Spring Cloud makes it very easy to create a Service Registry and discovering other services using Load Balanced RestTemplate.

22. What is Circuit Breaker?
In the micro services world, to fulfill a client request one micro service may need to talk to other micro
services.
We should minimize this kind of direct dependencies on other micro services but in some cases it is
unavoidable.
If a micro service is down or not functioning properly then the issue may cascade up to the upstream
services.
Netflix created Hystrix library implementing Circuit Breaker pattern to address these kinds of issues.
We can use Spring Cloud Netflix Hystrix Circuit Breaker to protect micro services from cascading
failures.

23. What is API Gateway? (Spring Cloud Zuul Proxy as API Gateway)
In micro services architecture, there could be a number of API services and few UI components that
are talking to APIs. As of now, many micro services based application still use monolithic front-ends
where the entire UI is built as a single module. You may choose to go with micro-frontends where the
UI is also decomposed into multiple micro service talking to APIs to get the relevant data. Instead of
letting UI know about all our micro services details we can provide a unified proxy interface that will
delegate the calls to various micro services based on URL pattern.
An API Gateway, aka Edge Service, provides a unified interface for a set of micro services so that
clients no need to know about all the details of micro services internals.

24. Distributed Tracing with Spring Cloud Sleuth and Zipkin
One of the challenges in micro services architecture is the ability to debug issues. A simple user action might trigger
a chain of downstream micro service calls. It would be tedious to trace the logs related to a particular user action
across micro services. In addition to that, we might want to track down why a certain micro service call is taking so
much time. We can use Spring Cloud Sleuth to handle these kinds of issues. Spring Cloud Sleuth provides the
distributed tracing capabilities and we can also export these trace information to Zipkin to visualize the call traces.
Tracing Distributed Service Calls
In the micro services world, a user action on UI may invoke one micro service API endpoint, which in turn invoke
another micro service endpoint.
For example, when a user sees the catalog, shoppingcart-ui will invoke catalog-service REST API
http://localhost:8181/api/products which in turn calls inventory-service REST API
http://localhost:8282/api/inventory to check for inventory availability.
Suppose, an exception has occurred or the data returned is invalid and you want to investigate what is wrong by
looking at logs. But as of now, there is no way to correlate the logs of that particular user across multiple services.

25. Is micro service architecture an evaluation of service oriented architecture? Or
Is it something completely different?
Application 1 Application 2 Application N
Enterprise
1 1 1 1 1 1 1 1 1
Monolithic Micro Service
 Micro service relate to application
architecture
 SOA relates to enterprise service
exposure

26. As per wiki - A service-oriented architecture (SOA) is a style of software design
where services are provided to the other components by application components,
through a communication protocol over a network.
The basic principles of service-oriented architecture are independent of vendors,
products and technologies. A service is a discrete unit of functionality that can be
accessed remotely and acted upon and updated independently, such as retrieving a
credit card statement online.