Patterns for Refactoring a Monolith Application into Micro services

The Microservices Architecture is the flavor of the season with Application Architects and Developers. This approach of developing an Application as a collection of loosely coupled, light weight, autonomous services is increasing becoming popular, due to the plethora of benefits it offers. As Enterprises adopt Digital trends like Cloud, DevOps and Containers, they are keen on maximizing the returns from these investments. To this end, they are looking at refactoring their existing monolithic applications into modern microservices, so those applications can also take advantage of modern infrastructure and development methodologies.

Refactoring Monoliths:

Advancements in Languages, Frameworks, Platforms, Tools and Infrastructure have made green field microservices development quicker and easier. Whereas refactoring Monoliths can be a daunting exercise since this relies primarily on domain knowledge, capability to accurately assess trade-offs and getting to arrive at the perfect approach to take. Refactoring Monoliths is not a straight-forward approach and it requires several thoughtful considerations in order to be successful. In this blog, I have summarized two effective patterns that I have successfully used in refactoring monoliths.

Adding New Features as Microservices:

If an Application is determined to be a good fit for refactoring, all efforts should be made to refrain from adding new features into it. New features should instead be developed as microservices, wherever feasible. This means services or clients that require this new feature should be modified to consume it directly via it’s API. Such new microservices should ideally expose coarse-grained APIs so that code changes in clients are minimal. If fine-grained APIs are the only option, then an API-gateway should be introduced, that performs the necessary API transformations. You need to carefully consider if the newly developed microservice requires data from the monolith. Remember that microservices are highly domain-oriented and are designed to solve a single problem well. In some cases this would require state information from the monolith; a popular pattern is to have the interface between the new microservice and the monolith protected by an anti-corruption layer. 

This pattern is very useful when the Monolith application is prone to frequent feature additions. This pattern might eventually lead to a desired situation where the microservices portion of the Application is much larger than the Monolith portion. The Monolith portion can then be either left as it is or decomposed into microservices. 

Separating out the Presentation layer into a Microservice: 

A typical Monolith has a Presentation layer, responsible for the User Interface of the App. This layer handles the HTTP requests, co-ordinates the interactions with the backend modules, and generates the necessary client code for the User Interface. The Presentation layer is a perfect candidate for ripping it off from the Monolith. Why? This layer is either stateless or only relies on the Business Logic layer for accessing state information. Often, the interface between the Presentation layer and the Business Logic is relatively clean and hence carving out the Presentation layer into a separate microservice is easier and less riskier. Code changes are required in the Business Logic layer to expose well-defined APIs that will need to be consumed by the Presentation microservice. Adequate care should be taken to implement security mechanisms to lock down the Business Logic APIs.

This pattern results in a much lighter Monolith, encapsulating the Business Logic and the Data layers alone. And having implemented API’s for accessing the Business Logic, this opens up doors for other Systems and Clients to consume it’s services. For instance, if you need to add support for Mobile clients to access your Web application, such clients can be written to directly use the Business Logic API’s. And of course this would lead to situations where the Business Logic would need to expose and implement special API’s for these clients.

Conclusion:

Refactoring Monolith Applications into Microservices is definitely worth the time, given the huge amount of benefits microservices bring. A complete re-write of the Application is seldom the recommended approach, given the high cost and risk involved. I suggest you take a evolutionary approach, leveraging the above two patterns.