MICROSERVICES DESIGN PATTERN, DESIGN PRINCIPLES, COMPANY CASE STUDY ON MICROSERVICES
WHAT ARE MICROSERVICES?
It is cloud-native practical architectural approach in which a single component which usually of many loosely coupled and independently deployable smaller components or services.
DESIGN PATTERNS OF MICROSERVICES:
- AGGREGATOR:
Image Source Credit: Courtesy: https://www.medium.com
It is a basic web page which invokes various services to get the required information.
For example, if we have two services each having its respective database, then aggregator having a unique transaction ID would collect the data from each individual microservices, apply business logic and publish it in endpoints.
2. API GATEWAY:
Image Source Credit: Courtesy: https://www.wallarm.com/
Since microservices are divided into small modules the API Gateway also acts as an entry point or endpoint to connect different microservices modules functionality.
Microservices uses Service Directory which helps to find different communication routes via stateless server like HTTP Request.
3. CHAINED OR CHAIN OF RESPONSIBILITY:
Image Source Credit: Courtesy: https://www.edureka.co
It is a single out which a combination of multiple chained outputs.
For example, if there are three services lined up in a chain, request from client is first received by service A than Service A communicates with Service B and finally Service B communicates with Service C at which it produces the consolidated output.
All these services work synchronously with help of synchronous HTTP request and HTTP response.
Response in other hand might be different from Service C to Service B and different from Service B to Service A.
4. ASYNCHRONOUS MESSAGING PATTERN:
Image Source Credit: Courtesy: https://www.edureka.co
In order to reduce waiting time of client which can use Asynchronous Messaging services.
All services can communicate with each other but not necessary the communication occurs sequentially.
Request can be sent to Service B and Service C simultaneously from client’s end.
These service request will be in queue.
Request can also be directly made to Service A, but response can be expected from any of the services being requested.
5. DATABASE OR SHARED DATA PATTERN
Image Source Credit: Courtesy: https://www.edureka.co
Each microservice has to process huge data.
So, in order to process data efficiently and smoothly, we can use database per services or shared database per services.
During process we encounter various database processing related to:
1. Duplication of data and inconsistency
2. Different services having different kinds of storage requirements.
3. Data De-normalization
Above two problems can be solved by implementing database per service and Data De-normalization issue can be solved by Shared Databases per service.
6. BRANCH PATTERN:
Image Source Credit: Courtesy: https://blog.devgenius.io/
In these patterns we can simultaneously process the requests and responses from two or more independent microservices.
Example an e-commerce application like Amazon, needs to retrieve data from multiple sources and it can be a collaborated output from multiple various data sources. Due to which you need a branch pattern to operate in such cases.
7. COMMAND QUERY RESPONSIBILITY SEGREGATOR:
Image Source Credit: Courtesy: https://www.edureka.co
As we have understood in Database and shared Data model that every microservices has either database per service or shared database per service model, but we cannot implement a query since data access is limited to single database of that respective microservices.
Thus, it becomes very much important to implement CQRS pattern.
According to CQRS pattern, the application is divided into two parts:
a. Command: Commands are responsible to handle all the requests related to CREATE, UPDATE, DELETE.
b. Query: Query are responsible to READ / VIEW any updates through sequences of events.
8. CIRCUIT BREAKER:
Image Source Credit: Courtesy: https://en.wikipedia.org/
These Design Pattern is used to stop process of request and response if the service is not working properly.
Example, Client is sending a request to retrieve data from multiple services but if services is down due to any issue that client is unaware of than client can face problem to continuously sending that request to that service even without knowing its services are down.
Due to which network resources are also exhausted due to low performance and bad experience.
So, to avoid above mentioned problem you can use Circuit Breaker Design with help of which the client will invoke a remote service via a proxy.
This proxy will behave as a circuit barrier.
When the number of failures crosses the threshold number, the circuit breaker trips for a specific time period.
Due to which all attempt to invoke remote services will be stop during that time frame.
Once the time frame is completed then circuit breaker initially allows a limited number of tests. If test of those requests is successful then the circuit breaker resumes back to normal operations.
9.DECOMPOSITION DESIGN PATTERN:
Microservices are decomposed into small independently functional services with help of Decomposition Patterns.
These applications are decomposed based on:
A. BUSINESS CAPABILITY.
B. SUB-DOMAINS.
A. BUSINESS CAPABILITY:
Image Source Credit: Courtesy: https://www.learncsdesign.com/
Ecommerce Application like Amazon, then you can have separate services for orders, payment, customers, products, catalog, login.
B. SUB-DOMAINS:
Image Source Credit: Courtesy: https://www.learncsdesign.com/
If microservices applications are designed by decomposing sub-domains, then you can service for each and every class.
10. STRANGLER PATTERN OR VINE PATTERNS:
Due to these patterns a call goes back and forth for each URI call and the services are broken down into different domains.
These domains are hosted as a separate service.
Two separate application live side by side in same URI space and one domain will be taken into account at any instance of time thus it also makes much easier for monolithic based applications.
DESIGN PRINCIPLES FOR MICROSERVICES:
1. SINGLE CONCERN MICROSERVICES:
- It means a microservice should do one thing and one thing only.
Example: If microservices is intended to perform authentication than it should do authentication only.
Authentication Access point interface should only be exposed which are relevant with authentication.
Internally also microservice should perform authentication operation only and no other side operations should be peformed.
2. DISCRETE MICROSERVICES BOUNDARIES:
- A microservice must have clear boundaries seperating it from its environment.
- It should also be well encapsulated.Means all logic and data relevant concern must be encapsulated into a single deployment unit.
3. TRANSPORTABLE MICROSERVICES:
- Microservices can be moved from one runtime to another runtime with little effort.
- Means if microservices module is made for kubernetes and in future if that same functionality is required in AWS that by little effort and some changes entire microservice can be transported to AWS as well.
4. CARRY-ITS-OWN-DATA MICROSERVICES:
- A microservices should have its own data storage mechanism that is isolated from all other microservices.
5. INHERENTLY EPHEMERAL:
- It means that microservices can be created, destroyed and replenished on-demand target easily and quickly with no side effects.
- Example: This is most common with Kubernetes Horizontal Pod Autoscaler (HPA) to accommodate scaling demands.
- HPA creates and destroys containers according to momentary demands.
- Each time a container is created, an IP address is assigned dynamically. Sometimes in certain situation port numbers are assigned dynamically too.
COMPANIES WHICH ADOPTED MICROSERVICES ARCHITECTURE:
1. AMAZON:
Amazon employed microservices “To Streamline and Reduce Process Time”. By dividing the entire structure into different component services the developers were able to determine were the problem was, nature of slowdown and were easily able to rebuild structure as service oriented architecture, each with a small team devoted to a single service.
2. UBER:
Due to Uber’s previous Monolithic architecture any small error in application led to a serious implication which were hard to solve. Thus, Uber also developed and implemented microservices for several operations which includes trip management, invoice, number of passengers. API gateways are used to communicate with those services.
4. NETFLIX:
Netflix initially started with AWS for all of its horizontally scalable systems, eventually it continued converting all of its interface(user-facing) applications into autonomous microservices.
5. EBAY:
eBay also supports thousands of microservices starting from its user interface which is front-end, web, Android, iOS via contact intermediary services that coordinates with communicating with back-end services.
CASE STUDIES ON MICROSERVICES:
CASE STUDY 1:
TWITTER’S IMPROVED UPTIME CASE:
PROBLEM:
Twitter utilized monolithic design, but when more individual registered the SDLC grew larger and took longer build times and scalability deteriorated significantly, with over-capacity error warnings.
SOLUTION:
Twitter changed its Architecture to Microservices to resolve this issue.Where each microservices was created to be modular, independently functional, well defined and autonomous. Thus, made very easy for them to test and deploy each component and easy scale as well. The error warnings also vanished entirely.
CASE STUDY 2:
UBER AND RAPID EXPANSION CASE:
PROBLEM:
The single package of application (ie. monolithic) served and managed all of the major business activities, including billing, payments, driver connection services.As company developed, thus things became hard to expand rapidly and decline started. As more features were added the packages grew more cohesive. All logic was contained in one location and Continuous Integration became a major liability. Due to major dependency within the monolithic software, it became really hard for developers to migrate, since even the minor change occured it had a very serious consequence.
SOLUTION:
Soon the implementation of microservices took place. They disassembled the whole service and migrated the monolithic application to a micro service architecture which made development, scalability easier.
CASE STUDY 3:
EBAY’S BALANCE REGAINED CASE:
PROBLEM:
eBay was built on monolithic application with Pearl and C++.
All the front-end related services like API calls and backend services managing administrative, database and shipping related operations.
The need to add several incremental features to eBay website continued to increase and this type of website had to be accessible 24 hours a day, seven days a week. As new feature was being added the downtime of application needed to be minimized.
SOLUTION:
For minimizing downtime, eBay implemented microservices architecture. This allowed the site to become more stable and promoted asynchronous integration due significant improvement were made to deployment flexibilty. When services ran isolated, performance efficiency increased and scaling out was also easily possible for developers.
REFRENCE LINKS:
Thank you for your time and for your reading. I hope this article becomes helpful for you all. Be Curious. Keep Sharing. Keep Learning. Keep Helping. Keep Growing.
