When too many people are working on a single tightly coupled codebase, as is normal in monolithic applications, bottlenecks are a usual challenge together with reliability and scaling problems. This is why, a Statistics survey says that 85% of respondents of large organization have migrated to a loosely coupled microservices architecture. While this could be interpreted as bigger organizations are the ones gaining benefits from microservices, this is far from the truth. Smaller companies can also benefit from a microservices architecture and in fact many already do so. If you are not sure whether your business is a good candidate for migrating to microservices, then this article provides a checklist.
If your organization is planning to start migrating partially or wholly from monolith to microservices then this article is for you. Here is an insight on what iTech advices our customers when it comes to a successful migration.
Incrementally extract modules out of the monolith – Strangler Pattern
Microservices-based apps uses business logic to divide the components into a single purpose, stand-alone units. To enable such independence, each microservice is developed as a separate software container that has its own code and database.
When refactoring from monolith to microservices, one of the recommended ways is to start implementing any new functionality as separate services right away. However, since the existing monolithic architecture still supports the majority of the existing functionality, the only way to eliminate the monolith entirely is to start incrementally refactoring modules one by one into the new microservices architecture. This is the Strangler Pattern of transition – transform, co-exist, eliminate. This is the recommended method to refactor code in a large web application by replacing incrementally each functionality with a new web service.
Here is an example that will more easily explain the concept of incremental migration. In a courier company, the order and delivery management were part of a single system. This made it difficult to improve on the algorithms of the delivery system ( to meet new market demands) without affecting the order management system since both were intertwined in the monolith application. The result was a loss in efficiency as well as customer satisfaction. The decision was made to separate the delivery management system but in incremental stages that would not affect the existing business workflows. This was how it was done:
Step 1: Split the code of order management and delivery management and keep it as loosely coupled modules in the same monolithic system.
Step 2: Split the database into two with a separate database schema for each. Data from the monolithic database are segregated into their respective databases. Triggers are also defined that replicates the data into each new database.
Step 3: Define a separate service for each of these workflows. The two new microservices still remain in test phase and will not go into production yet. Even when functionality is extracted into the new service, it is important that if unexpected errors arise in production, in the initial stages, that a switch back to the old monolith service can be done without affecting existing business.
Step 4: Eliminate or decommission the old monolith. Once any glitches in the new system have been identified and resolved , it is time to fully direct production traffic into the new stand alone microservices driven functionality. At this point the monolithic system is switched off.