DEV Community

Cover image for ​​Moving from monolith to microservices? Take a leaf out of the Strangler Fig Approach
CloudNow Technologies
CloudNow Technologies

Posted on • Updated on

​​Moving from monolith to microservices? Take a leaf out of the Strangler Fig Approach

There are a number of ways to modernize an application from a monolithic architecture to microservices. One method that stands out for ensuring a smooth and stable transition is called the Strangler Fig approach.

British software developer and author, Martin Fowler, came up with the metaphor of ‘strangler fig’ trees to illustrate this journey between architectures. What a strangler fig does is to envelope and gradually strangle the host tree on which it grows, until the original tree dies and only the strangler fig remains. 

In the world of app redevelopment, the metaphor stands for incremental migration. Fowler believes that app development into a monolith and then cutting it back into microservices is actually even better than developing head-on into microservices. He also says that almost all cases of a system built as a microservice system from scratch ended up in serious trouble. 

In his opinion, the Strangler Fig Application is an effective migration technique as it allows for migrating a legacy system incrementally by replacing existing functionalities with new applications and services in a phased manner.

A hasty overhaul of an old system can be disastrous, while a gradual migration reduces the risk of major failures. And once all the monolithic functions are transformed to the new microservice application, the monolith can simply be retired.

So, what are the advantages of the Strangler Fig approach?

  • It allows you to pause or stop the migration in the middle of the process if needed, while continuing to use whatever has already been redeveloped. Every step is incremental and reversible.
  • This approach delivers reduced risk. Shorter and more frequent release cycles would mean more time for testing and therefore fewer rollbacks. Also, there are continuous value launches. However, this may not be suitable for smaller systems with low complexity and size as it involves high effort and commitment.
  • The process keeps clients in the loop. When running two separate versions of an application, clients must be kept informed of where each feature is located. The Strangler Fig approach overcomes this challenge as it works by creating a routing façade that intercepts requests going to the legacy system and routes them either to the legacy application or new application. The interface continues even while the technology migration is in progress.

How does the Strangler Fig approach work?

Step 1:

Identify the element that you want to migrate.

Step 2: 

Analyze the current legacy application to split your application based on functional transactions by accounting for code complexity. Perform analysis for security threats in the new architecture.

Step 3: 

Implement elements in a new microservice.

Step 4: 

Create the proxy or alternate routing façade between the legacy app and user; when the component is ready, link it to the proxy and serve traffic to the page, slowly increasing the amount of traffic going to the new page.

Step 5: 

Incrementally reroute calls from monolith to new microservice.

Step 6: 

Test new functionality comprehensively.

Step 7: 

Finally, eliminate the legacy module.

Step 8: 

Keep repeating steps 1-4 until the entire functionality is handled by the new stack.

Note: 

The legacy and new functionality/module/application need to run in parallel; eliminate the legacy app ONLY after testing is complete.

As monolithic systems become too large to deal with, many enterprises are drawn to breaking them down into microservices, certainly a worthwhile journey. At CloudNow we’ve learned to deploy this migration process seamlessly. So, if you are looking for assistance in this direction, do contact us.

This blog originally published at CloudNow Blog. Link to the original blog

Discussion (0)