Application Development & Modernization

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.

SatyaDev Addeppally

Enterprising leader with an analytical bent of mind offering a proven history of success by supervising, planning & managing multifaceted projects & complex dependencies; chronicled success with 22 years of extensive experience including international experience.

Recent Posts

Deploying Boundary for secure developer access to your cloud resources

Whether databases, Kubernetes clusters, or storage, exposing them to the public internet can pose significant…

1 week ago

Ensuring high availability: Testing Kubernetes cluster resilience with Chaos Monkey and Litmus Chaos

With more organizations adopting Kubernetes to orchestrate containerized workloads, there is a growing need to…

2 weeks ago

Elevating Security with DevSecOps Services: A Comprehensive Guide

DevSecOps - short for Development, Security, Operations - picks up where DevOps leaves off, adding…

1 month ago

From DevOps to DevSecOps: Seamless Transition Tactics for Businesses

DevOps is essentially a collaborative model that brings together software development and operations. DevSecOps integrates…

2 months ago

Azure DevOps vs AWS DevOps vs GCP DevOps: Unique Tools & Techniques Explained!

  DevOps promotes collaboration, continuous integration and deployment, real-time monitoring, and immediate feedback, leading to…

2 months ago

Setting Up your Internal DevOps Practice through DevOps Consulting Services: The 7 Key Stages

It was 2007, and Patrick Debois, an IT administrator, increasingly frustrated by conflicts between developers…

3 months ago