Microservices Architecture

Microservices Architecture is an approach where an application is built as a modular service. Each of these modules serves a specific business goal and there will be an interface through which it will communicate with other services. 

The principle of loose coupling is applied in Microservices architecture, so the dependencies between services and their consumers are minimized. And quite like monolithic services, there will be no change in the application’s performance when changes are implemented and the systems are modified. This is because each of the micro services have their own database, and the services can use a database suitable to their needs.

Here are the main services needed for a typical online service application

• Authorization Service
• Order Service
• Catalog Service
• Cart Service
• Payment Service
• Shipping Service 

Benefits of Using Microservices Architecture

• Microservices ensure continuous delivery and deployment of complex applications however big
• Each microservice is small and easy to manage
• The IDE is faster facilitating productive development in the shortest time
• Testing is easy because there are small services and they are faster to test
• Each of the services are deployed independently 

It is easy to share the project among multiple teams, and each team will manage one or more services. They can focus on the service, develop, deploy and scale them independently too

Isolate the problem, so if there is one problem with the application, the other services will not be affected, whereas in a monolithic architecture, the entire system will shut down

No long-term commitment to a technology stack. When a new service is created, the developers can use a different tech stack. Or they can rewrite an existing service using a tech stack. 

Disadvantages of using Microservices Architecture

Well, everything has a dark side, so before mentioning the transacting process, it is important to check out the cons of Microservices Architecture too.

• Distributed systems complexity is there. Creating distributed systems is not an easy task.
• Testing is not easy, testing in Monolith is easier
• Developers have to create an inter-service communication mechanism. And there should be careful coordination and management while implementing use cases that cover multiple services. 
• There is deployment complexity because there is this operational complexity of deploying and managing several service types. 
• In spite of the disadvantages, moving from monolith to microservices is a very important and valuable business tactic. 

As mentioned earlier, there will be a number of smaller components in micro services, and it is important that they be automated in every activity including builds, deployment and testing. With CI/CD servers this can be automated, leading to faster production release cycles. Tools like Selenium, Cucumber etc are available for the automation of UI testing . Back end testing process through Junit test cases.

All well-designed monolithic applications will project a separate UI layer from the Service layer, and this will be helpful during transformation. If there is no separation, then the first step would be to separate the UI layer from the service layer, and project them in respective containers. Moving forward to the next step would be an API on the backend so the components can communicate with the backend or the service layer. 

Now comes the next level of transformation. Here there will be a full separation, down the database level.  To make things easier, you can start with decomposing a domain that’s small. This will be easier to extract, and with little risk. 

As the next step, the UI layer specific to the microservice is separated.

Transaction Management

The transaction management itself happens in different stages, and it could be a complex thing. There are several aspects in transaction management like service availability, consistency between services, isolations and rollbacks that must be considered. 

Microservices are meant to be independent, so they can address the business problems on their own. 

API composition

With an API composer, data is extracted from multiple microservices. 

Two-phase commit protocol

This is a mechanism for implementing distributed transactions across other software components. 

In a distributed transaction, you have the transaction coordinator, while the transaction happens in two steps:

The preparatory phase and the Commit or Rollback phase

The Preparatory phase – In this phase, all the participants will be ready to commit to the transaction, and notify the coordinator.

The Commit or Rollback phase – In this phase, either a commit or rollback will happen when the transaction coordinator issues the command. 

The Distributed Saga pattern

The distributed saga pattern is the next stage, it is the solution to undo the changes that happen when a business rule is violated in a local transaction failure. A saga is s series of local transactions. Each time the local transaction updates the database, it publishes a message to trigger the next in line local transaction in the saga. 

Event-driven choreography

Each service listens to the other services and comes to a conclusion whether an action has to take place or not. Each service happens right after the other in a series, and in case of failure, there will be a rollback. 

In choreography, each part of the system will know what it has to do and the process goes smoothly with each part knowing when and what it has to do. There is also another style known as the orchestration, where there will be a central brain guiding and driving the process, just like there will be a conductor in an orchestra. 

[Image Courtesy : ResearchGate.NET]

It is important that Transaction Management be handled efficiently

Transaction Management does take its toll because when you have a number of different micro services, they will have their own independent business capability that connects to different databases. All the steps are to be completed logically or there will have to be a rollback. If there are multiple failure points, the challenges are high.

However, roll back is costly, and developers have to do another transaction or operation to compensate for the failure. The RollBack is the Compensating Transacting Phase to achieve eventual consistency. 

A monolithic architecture would be good for lightweight applications. It is also recommended to adopt the Monolithic approach first, and then shift to the Microservices architecture at a later stage when the needs/requirements change. 

However Microservices can break your large application into different domains, so there will be a separation of responsibilities. It will not impact the work on other services. So as the application scales, you will need micro services. Big organizations like Uber, Netflix followed this procedure from Monolith to Microservices. 

If you are ready to shift from Monolith to Microservices, make sure you get the right partner who can explain the process in detail so you will know how to go about it smoothly.