In this presentation, we will learn what is Micro Service, Advantages of Micro Services, case study, Microservice Design Patterns.

1. Microservices

2. What is Microservices ?
• The microservices architectural style is an approach of
developing a single application split into set of smaller,
interconnected services, distributed instead of building single
monolithic application. And each split will be developed
individually, packaged individually and deploy individually.

4. Differences Between Traditional Architecture
and Microservices

5. Disadvantages in Monolithic architecture
1. Continuous deployment integration will suffer a lot.
means a small modification in one component force to us to redeploy the entire application again
with a new release.
2. Monolithic application has a barrier for adapting new technology.
Since changes in framework will affect the entire application, that’s why it is extremely expensive
in both development time and development cost.
3. Exception propagation not proper.
For example let’s consider if my payments service go down then it impacts to my Entire
application.
4. Code Readability is not there.
5. As we deployed entire service as WAR, the performance of the application goes down because
of huge amount of data present in the war.
6. The size of the application can slow down the startup time.
7. We must and should redeploy the entire application for each update.
8. It also difficult to scale up when different modules have conflicting resource requirement.

6. Microservices Features

7. • Decoupling – Services within a system are largely decoupled. So
the application as a whole can be easily built, altered, and scaled
• Componentization – Microservices are treated as independent
components that can be easily replaced and upgraded
• Business Capabilities – Microservices are very simple and focus on
a single capability
• Autonomy – Developers and teams can work independently of each
other, thus increasing speed
• Continous Delivery – Allows frequent releases of software, through
systematic automation of software creation, testing, and approval
• Responsibility – Microservices do not focus on applications as
projects. Instead, they treat applications as products for which they
are responsible
• Decentralized Governance – The focus is on using the right tool
for the right job. That means there is no standardized pattern or any
technology pattern. Developers have the freedom to choose the best
useful tools to solve their problems
• Agility – Microservices support agile development. Any new feature
can be quickly developed and discarded again

8. Advantages Of Microservices

9. • Independent Development – All microservices can be easily developed
based on their individual functionality
• Independent Deployment – Based on their services, they can be
individually deployed in any application
• Fault Isolation – Even if one service of the application does not work, the
system still continues to function
• Mixed Technology Stack – Different languages and technologies can be
used to build different services of the same application
• Granular Scaling – Individual components can scale as per need, there is
no need to scale all components together

10. Microservice Architecture

11. 1. Clients
The architecture starts with different types of clients, from different devices
trying to perform various management capabilities such as search, build,
configure etc.
2. Identity Providers
These requests from the clients are then passed on the identity providers
who authenticate the requests of clients and communicate the requests to
API Gateway. The requests are then communicated to the internal services
via well-defined API Gateway.
3. API Gateway
Since clients don’t call the services directly, API Gateway acts as an entry
point for the clients to forward requests to appropriate microservices.
The advantages of using an API gateway include:
All the services can be updated without the clients knowing.
Services can also use messaging protocols that are not web-friendly.
The API Gateway can perform cross-cutting functions such as providing
security, load balancing etc.
After receiving the requests of clients, the internal architecture consists of
microservices which communicate with each other through messages to
handle client requests.

12. 4. Messaging Formats
There are two types of messages through which they communicate:
Synchronous Messages
Asynchronous Messages
5. Data Handling
Well, each Microservice owns a private database to capture their data and
implement the respective business functionality. Also, the databases of
Microservices are updated through their service API only.
6. Static Content
After the Microservices communicate within themselves, they deploy the
static content to a cloud-based storage service that can deliver them
directly to the clients via Content Delivery Networks (CDNs).
7. Management
This component is responsible for balancing the services on nodes and
identifying failures.
8. Service Discovery
Acts as a guide to Microservices to find the route of communication between
them as it maintains a list of services on which nodes are located.

13. Best Practices To Design Microservices

14. Microservice Design Patterns
1)Aggregator Microservice Design Pattern
2)Proxy Microservice DesignPattern
3)Chained Microservice Design Pattern
4)Branch Microservice Design Pattern
5) Asynchronous Messaging Microservice
Design Pattern

15. Aggregator Microservice Design Pattern
Aggregator is a simple web page that invokes multiple services to achieve the functionality
required by the application.
For example:
Let’s consider Service A, Service B, and Service C are exposed using a lightweight REST
mechanism, the web page can retrieve the data and process/display it accordingly.
• If there are multiple services that need to access Service A, B, and C, then its recommended
to abstract that logic into a composite microservice and aggregate that logic into one service.
• each individual microservice has its own caching and database. If Aggregator is a composite
microservice, then it may have its own caching and database layer.
• It can be scale up based on our requirement.

16. Proxy Microservice DesignPattern
• It is a variation of Aggregator. In this case, the aggregation need not to be required
on the client but a different microservice may be invoked based upon the business
need.
• It can be scale up based on our requirement as like aggregator microservice design
pattern.
• We need to go for this where each individual service need not be exposed to the
consumer and should go through an interface.

17. Chained Microservice Design Pattern
• Chained microservice design pattern produce a single or unified response to the
request.
• In this situation, the request from the client is received by Service A, which is then
communicating with Service B, which in turn may be communicating with Service
C. All the services are likely using a synchronous HTTP request/response messaging

18. Branch Microservice Design Pattern
• Branch microservice design pattern extends Aggregator design pattern.
• It allows simultaneous response processing from two chains of
microservices.
• Let’s Service A is either a web page or a composite microservice, it can
invoke two different chains simultaneously. It seems to be similar with the
Aggregator design pattern.

19. Asynchronous Messaging Microservice Design Pattern
• As The REST design pattern is quite widespread, and well understandable but it have some
limitation like being synchronous as a result it also quite blocking in nature.
• Even though we can achieve Asynchronous but that is done based on an application specific
way.
• Some microservice architectures use message queues instead of REST request/response for
achieving Asynchronous Messaging supports.
• In this pictorial diagram, the Service A may call Service C synchronously which is then
communicating with Service B and D asynchronously using a shared message queue.

20. Companies using Microservices

21. UBER CASE STUDY

22. The above diagram depicts UBER’s previous architecture.
• A REST API is present with which the passenger and driver connect.
• Three different adapters are used with API within them, to perform
actions such as billing, payments, sending emails/messages that we
see when we book a cab.
• A MySQL database to store all their data.
Problem Statement
• All the features had to be re-built, deployed and tested again and
again to update a single feature.
• Fixing bugs became extremely difficult in a single repository as
developers had to change the code again and again.
• Scaling the features simultaneously with the introduction of new
features worldwide was quite tough to be handled together.