Strategies to migrate Monolithic Application to Microservices

Microservices are a new norm for the enterprise development and many newly built applications are inherently adopting MS core principles. However many enterprise organizations are seriously thinking/working to migrate their existing monolithic applications to microservices. However, this is where most interesting challenges lie, primarily because these monolithic applications are generally mission critical to the continued success of the business. Hence migration must be as smooth as possible and we need to put right strategy to reap good benefits. This blog covers the different strategies that we can adapt to break/migrate the monolithic application to microservices

Table of Contents:

• Introduction
• Standard Constraints
• Strategies to Migrate
  • Parallel full redesign
  • Standard Microservices
  • Self Contained Systems
• Migration best practices
• Summary

Standard Constraints

• A production application must continue to work smooth and end user should not feel any unwanted change in experience while migrating
• Migration should not hinder the team in adding more functionality to the existing system
• During migration also, production support and devops team should look at one source of truth rather than multiple

Strategies to Migrate

There are few high-level strategies we can follow while migrating monolithic applications. The approach will vary based on project conditions and as an architect you should take a call on the right approach based on multiple constraints in the project.

Parallel full redesign

Do not touch monolithic application, but start building a parallel application with MS architecture principles. This like a building a new application which exhibits same functional behavior but with microservices.

Pros:

• Existing monolithic application won’t be disturbed, hence user will not experience any challenges related to migration
• Will have lesser constraints for developers, hence it is easy to architect, design and code

Cons:

• Leads to typical waterfall model. Don’t know the outcome of the effort until the last leg i.e. till all the time and money are spent

Standard Microservices

Identify the independent modules in existing monolithic application and convert the backend functionality into Microservices and replace all the direct calls for this module across the application( including UI and Backend) with microservice calls. Keep doing the same step for all the modules in iterative form till complete application is broken into microservices. Sometimes you may need to divide a microservice module into multiple microservices in order bring in better granularity.

Pros:

• Part of application will be migrated in each iteration, hence customer can see iterative progress on migration
• Lessons learned in the previous iteration can be adopted in next iteration, hence team will continue to grow strong with each iteration

Cons:

• Changes in existing monolithic application will be high in order to integrate with newly created microservices module.
• UI code will continue to be monolithic

Self Contained Systems:

Identify the module which can work independently, then convert the backend into microservices and rebuild UI for that specific portion as independent UI module. Then replace old functionality with both UI and Microservices(Self Contained Systems).  Self Contained Systems contains both backend and UI and all the time they are expected to work as a complete and independent module. These modules are loosely integrated with main monolithic application i.e. many times with simple URL reference. Iterate the above process till the complete monolithic application is migrated to Self Contained Systems. After completion of migration, an application will be loosely coupled group of UI components and set of microservices.

Pros:

• Part of application will be migrated in each iteration, hence customer can see iterative progress on migration
• Lessons learned in the previous iteration can be adopted in next iteration, hence team will continue to grow strong with each iteration
• UI also gets migrated to independent modules hence development will become faster and quicker for each module
• The user will see visible changes for each iteration in the application

Cons:

• As more modules move to Self Contained Systems, communication among these modules will become much more complex especially at UI level
• Not all famous UI frameworks we have now has very good support for versioning management for modules. As this support is not foolproof, we may end up having regression issues when two UI independent modules become incompatible.

Migration Best Practices

Best practices vary from one strategy to another strategy. However there a generic practices that we must adopt irrespective of strategy we choose. We will cover those generic practices here.

• Identify the most independent module and migrate that first.
• Never allow the migrated microservices module code to continue in the monolithic application.
• Build or Choose a framework which takes care of cross-cutting concerns and developers will focus only on business functionality
• Do not hesitate to break the existing microservice to further smaller microservices

In this blog we covered different strategies that we can adopt while migrating monolithic application to microservices and pros and cons for each strategy. I hope this blog will help you to take informed decision while choosing the strategy for migration.

We have conducted a Free webinar on the above discussed topic on 26th May 2018. The webinar was hosted by Walking Tree Technologies and the presented by Suman Ravuri, V.P of Engineering.

You can watch the webinar here: Watch now!