Transacting monolith to microservice
10th November, 2021
Developing applications in the monolithic style may seem like you’ve gone back in space and time or something that people would term being stuck in the sphere of architectural evolution. Transferring from monolithic to micro service architecture is important to keep up with the recent trends.
Monolith means packed in one piece, here in our context. In a monolithic application, the program is built as a single unit, and this makes it too large and complex. It becomes tedious when errors come up, and so making changes becomes a problem. And, next to impossible to do Continuous Integration and Continuous Deployment.
The typical components of a monolithic application are combined into a single platform:
- Presentation layer
- Business logic
- Database layer
- Application Integration
- Notification Module
The reason why monolithic applications are built is because it is quite simple to develop and deploy. In spite of the different components and modules, developers find that the initial part of the project is easy in Monolithic Architecture. They do the UI testing with Selenium. A monolithic application is easy to scale horizontally, and it is possible to run multiple copies behind a load balancer.
However, the multiple drawbacks to having a monolithic architecture makes it pertinent that you should start switching to Microservices Architecture. Let’s have a quick run-through of the monolithic application:
Maintenance – It is not easy to maintain or make changes to a large and complex application.
Deploying – With each update, you will have to redeploy the entire application
Startup time – When the application is too large, this slows startup time.
Bugs – The entire application will not function properly when there is a bug. This is because all the instances of the application are identical and so the entire application will be affected.
New and advanced technologies – The developer might find the initial stages of the application easy, but as they move onto the advanced stages, the entire process becomes cost and time consuming.
Scalability – Scalability becomes a nightmare because of conflicting resource requirements.
[Image Courtesy: NORDIC APIS]
Shifting to 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.
Automation in Microservices
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.
Moving from Monolithic to Microservices
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.
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.
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.
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.
Refactoring legacy applications is one of the natural incidents in application development. As an application is developed, eventually, it will go through a number of code changes, and sometimes, it will go through the hands of different developer teams. This could cause the application to cease functioning, behave abnormally or freeze, especially if the code base isn’t neatly structured.
There is no doubt that Web 3 is the future of the internet. The promise of a decentralized internet built on blockchain indeed solves a number of problems that users faced with Web 1 and Web 2, because the technology is Open, Trustless and Permissionless. The concept of Web 3 makes the applications safe because the data is not stored on a single server, but on decentralized networks..
We described the importance of Web 3.0 as the third phase of innovation after Web 1.0 and Web 2.0 in an earlier article. In this article, we will describe at length how this new and trendy technology can influence the future of the internet. Look how the internet has come from what it was just 10 years ago. There was an innovation every day, with something new provided to the users
Talk to Our Team for Expert Opinion.
Scalan Labs is a full-service product engineering company that provides dedicated teams for full stack development. We have the top1% talent for product engineering and dedicated teams to help you reach your business goals. Contact us today to learn more about how we can help you!
We are sorry that this post was not useful for you!
Let us improve this post!
Tell us how we can improve this post?