How will you migrate monolith application to micro services?

Micro services has become widely celebrated buzzword these days. Many of us know where  to use this architecture and fairly know pros and cons around it. But whenever we talk with customers around it 99 percent of time they naturally come up with below question. they often say

“Ok We got the Essence. But how you guys are going to migrate this monolith to match it in micro services?”

So let’s not grim over it next time.

Million Dollar Question that most of the customers ask us is finally here. I’ll try to explain possible approach to solve it based on my Experience. Breaking the monolithic ( also commonly referred as big ball of mud ) application to micro services is one of the task which should be properly designed and planned.

This approach can be different for particular size of application. For Example It might be different approach for small applications ( say where lines of code is in thousands. ) and the approach might be different for applications which actually is million lines of code often called as big giant monolith.

Treatment for Small Applications

Lets talk about small applications first. For small applications Application Snap Analysis can serve a purpose. Snap Analysis is a technique where we try to analyze application by doing SWOT. Even though small applications tend to look straightforward it have tremendous potential in future so it should also be designed by thinking Big. We need to categorize application in Logical Services by considering its core functionalities plus accessory functionalities.

Step 1: Snap Analysis

SNAP analysis helps us to understand application complexity and suitability to convert that into micro services and its applicability and suitability on or over to cloud.

SNAP analysis is basically set of  4 types of understandings of application. These are as below:

  1. Risks
  2. Characteristics
  3. Stories
  4. Metrics

We can brainstorm with related application stakeholders and technologists for this process and ask relevant questions to them. Then ahead after proper understanding of application we can come up with outline / document like below:

It’s time now to look up bit to actual application. We can use tools like  Structure 101 , JDepend, XRay for analyzing existing relation ship and coupling between dependent systems in application. Our first goal should be to find out most loosely coupled component from monolith. This loosely coupled component is absolutely alone and work alone. This component is often called as SEAM.  Spot these Seams using above said tools and start converting it to micro services using relevant technologies.

Treatment for Medium to Giant size Applications

Approach is slightly different for medium size to very big portfolios. For very big portfolios we need to do portfolio analysis first. Portfolio in other word is giant enterprise which might have number of monoliths catering to its technology.So in this case we need to do analysis of entire portfolio. for Example, If organization XYZ have 20 monolithic applications in place then we need to choose one of the monolith to act on first.

Step 1 : TIME analysis

TIME graph help us to understand out of given which monolithic application  to choose for decomposition. TIME here is actually T.I.M.E. Let me elaborate it further.

T.I.M.E. acronym can be segregated in following terms:

  • T –  Tolerate
  •  I  – Invest
  • M- Migrate
  • E – End of Life

To come up with results we can plot monolithic application on TIME graph. It is basically four quadrant graph. Which have business value on X axis and Technical Quality on Y axis. So if we plot this graph and plotted application in graph then we can select important monoliths for organization plus they will also have good technical quality. They generally resides in first quadrant.

Most of the time customers themselves do these kind of analysis and readily give applications to us migrate.

Step 2 : Application Event Storming

Then ahead we can perform event storming on chosen application. Event Storming is very brainstorming intensive interesting activity. Event Storming is technique in which we can model our application around Domain Driven Design. I preferably assume that most of the readers are in sync with Concepts of DDD ( long form covered already 🙂 ). If not aware I will strongly recommend read book from Domain Driven Design by Eric Evans or Domain Driven Design Distilled by  Vaughn Vernon.

Event Storming is technique in which we can identify event flow and domain model of application. We call every possible stakeholder and technical staff for this activity. We motivate them to give us events that occur in in entire application. Then ahead we Identify commands that triggers these events and lastly with proper discussion and brainstorming with customer we come to know operating boundaries of different parts of application. In Domain Driven Design terminology this is called as Bounded Context. This is generally one to two days activity and Sticky Notes and Full Wall is needed instruments for this activity.  Following picture might idea about it.

We can then do SNAP analysis of each bounded context. Few of the tools such as XRay , JDepend or Structure 101 can help more in understanding coupling and complexity of application part pertaining to given bounded context. You can identify Seam in application using above tools. Husshh.. We can start planning our migration from this point.

There is one design pattern monolith micro service migration which is called as Strangler. It says we should incrementally convert monolith to micro service by migrating one micro service at a time. and eventually incrementally with proper careful baby steps we will almost migrate entire application to micro service. If you have new requirement to implement in application so that in appropriate service and never do that in existing monolith.

Note – Never migrate entire application to micro service. It will yield a disaster and can go in catastrophic application failure. As Martin Fowler has rightly said:

“Big bang rewrite will almost  always  result in Big Bang and nothing else.”

One more thing we need to take into consideration is communication of micro service with original monolith. This can be achieved through concept called Anti Corruption Layer. ACL is basically combination of Facade which can be implemented in monolith plus adapter or translator in between micro service and monolith. We also need to introduce router which can route URL to appropriate microservices and few of those to monolith which are still intended to go to monolith site.

Organization Level Changes

In complement with application design level changes some organization level changes are helpful for micro services architecture. Silos are hindrances for rapid migration of monolith to micro services.  Think about adopting Dev Ops architecture as part of migration. We also should target to organize 2 pizza team for each micro service.

I Hope I covered explanatory answer for “How will you migrate monolith application to micro services?”

Similarly Database Decomposition is equally important. You can read my How will you break and migrate our monolithic database matching to micro services? blog to have more insights into approach to solve this problem.

Let me know your comments in comments section.

So the conclusion is migration strategy should be well thought and well designed strategy to yield best result. All the Best!!





Your like and share is best motivation booster:

3 thoughts on “How will you migrate monolith application to micro services?

  1. Brief, clear, precise and to the point explanation Pramod !! 👍💐
    Nice use of quotes and a handsome presentation. Keep it up!

Leave a Reply

Your email address will not be published. Required fields are marked *