Monolith to Microservices — Migration patters

Img src : Checklists and Tools for Software Migration Planning | Smartsheet

In the last article, we have discussed how and when to migrate from Monolith to Microservices. This article is focusing on the migrations patterns from Monolith to Microservices.

Here, we shall look at patterns that would work for black-box vendor software, legacy systems, or monoliths that you could plan to continue to maintain and evolve. Initially, we will consider only where the application code lives. Following are some of the most commonly used techniques for migration patterns.

Strangler-Fig Pattern

Img Src : Strangler fig - Wikipedia

This pattern is named after a small fig wraps around a large tree, starts to live within the tree, and finally eats up the tree and continues to live.

As shown in figure 1, this pattern allows you to move functionality over to your new services architecture without changing your existing systems. Moreover, it is beneficial when the monolith affects a black box system such as third-party system software or a SaaS service. Implementation in a Strangler fig pattern requires only three steps.

Figure 1 : Strangler-Fig Pattern
  • Identifying parts of the existing system that you wish to migrate
  • Implement this functionality into your new microservice
  • Consider using a pattern like ‘parallel run’ to give more functionality to the system

We can use a reverse proxy to handle the request navigation. Strangler-Fig Pattern is one of the most used migration patterns where you would have minimal impact on the existing system. It is almost impossible to stop all your other support work and rewrite the system from scratch. Hence, this pattern would be suitable for most migrations.

Branch by Abstraction Pattern

These are the six phases that are being followed in Branch by Abstraction:

  • Build an abstraction for the functionality to be replaced.
  • Implement the newly build abstraction in the existing module.
  • Implement the new functionality in a new service. For some time, this implementation would be idle and would not connect to any functional flow.
  • Implement a service provide or some kind of wrapper/face to communicate with the freshly build service by implementing the abstraction.
  • Now your data flow is using the new service and you can get rid of the abstraction if you wish to.
  • Remove the old module/ functionality.

Decorating collaborator pattern

Figure 2: the Decorator Collaborator Pattern

Parallel Run Pattern

But in the Parallel run, as shown in Figure 3, both of the implementations are called out, giving us to compare the results to check their equivalency. For decades, this pattern was used even though it is usually used to run two systems in parallel. Most importantly, this method could be used to verify that new implementation is giving answers as same in the old and working and operating within acceptable nonfunctional parameters.

Figure 3: Parallel Run Pattern

Thats all folks. Thanks for reading and I hope you learned something new from this.

Please find my video related to this in following link.

References :

CTO @ ZorroSign | Seasoned Software Architect | Expertise in AI/ML , Blockchain , Distributed Systems and IoT | Lecturer | Speaker | Blogger

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store