How to use strangler pattern for microservices modernization

by

How do you modernize a legacy monolith application to a microservices architecture? – Very often, the answer that you would hear is ‘Strangler Pattern’.

What is Strangler Pattern?

Strangler-pattern-fig-tree

Strangler Pattern is a way of migrating a legacy system incrementally by replacing existing functionalities with new applications and services in a phased approach. After the replacement of the entire functionality the new application system eventually replaces all the old legacy system's features. The name "strangler pattern" was inspired from strangler fig trees.

Why choose Strangler Pattern for microservices modernization?

A big bang application approach or completely replacing a complex system with microservices can be a huge risk. So, adopting the strangler pattern to gradually migrate into a new system reduces the risk of a complete failure. However, running two separate versions of an application means that clients must know where each feature is located. Every time a feature or service is migrated, clients need to be updated to point to the new location. Strangler pattern overcomes this challenge of accessing multiples applications by creating a routing facade.

The routing facade intercepts requests going to the backend legacy system and routes these oncoming requests either to the legacy application or the new application. The client’s interface continues the old way unaware that any technology migration has taken place or is in progress.

Why haven’t you done this already?

The challenge in implementing this pattern is to be able to evaluate the functionalities and dependencies to identify components for separation and figure out the right migration strategy. In a complex legacy system, especially when the original developers of the core functionality are no longer there, it’s hard to be certain where to “cut” and how to adapt the software architecture correctly. You have to be able to make tradeoffs between complexity of target architecture and the desired level of functional separation.

New call-to-action

To split your legacy application into fine-grained functions that are lightweight, independently deployable, scalable, and portable, you need to:

  • Analyze the current legacy application to split your application based on functional transactions by accounting for code complexity. The complexity factor is crucial for the transformation decision using the strangler pattern.
  • Visualize the legacy components and new digital application in a single view to scope both the code bases
  • Identify the strangler facade and find whether there are any single points of failure proactively
  • Perform analysis for proactive security threat determinations in your new architecture.


So, what is the strangler path to microservices modernization?

  1. Monolithic legacy application architecture discovery and functional understanding, isolation of components & separation.
  2. Start developing your modernized microservices application as per functional isolated components as service.
  3. Include a strangler façade which can route the functional transactions to legacy or modernized microservices from access channels.
  4. Early stage viewpoint, legacy will be bigger in size handle more functional transaction and modernized microservices application will handle only the migrated functionality.
  5. Functional Microservices transformation will happen in incremental fashion for identified system functions of legacy over a time period to microservices and modernized application will grow bigger in size and handle more functions than monolithic legacy application.
  6. Once all the monolithic functions are transformed to new microservice application, completion stage is achieved as all the functions are on microservices platform and monolithic application can now retire.

Here's a pictorial view of strangler pattern implementation, showing the architecture transformation from legacy to microservices.

Early Stage

strangler-pattern-implementation-early-stage




Late stage

strangler-pattern-implementation-late-stage

Strangler Pattern Completion Stage

Once the migration is complete, the strangler interface facade will either go away or evolve into an adaptor for legacy clients. Strangler pattern’s clear benefit is to minimize risk in migration and to plan the development effort over time. As all features are migrated to the new system, the old legacy system is eventually "strangled" and ready to sunset/retire.

 

What to consider before using Strangler Pattern for microservices modernization

  • Size of the application: This pattern will not be suitable for small systems where the complexity and size are low.
  • System Compatibility: This pattern cannot be used in systems where requests to the back-end system cannot be intercepted and routed
  • Strangler Facade (Router) issues: Ensure the facade doesn't become a single point of failure or a performance bottleneck.

 

Useful tip

By the way, the above pictures of software architectures are all real images made with the new CAST Imaging system. CAST Imaging ingests your legacy system (the biggest one we analyzed so far with CAST Imaging is 13.5 million lines of code) and creates a visual representation of all of its components – from mobile interface down to the RDBMS. This makes deploying the Strangler Pattern much more plausible, because instead of hunting in the dark you can easily navigate and see all the impacted dependencies in whatever area of the application you’re trying to separate. You can take a look at a 1-minute video description of CAST Imaging below.

Get the Pulse Newsletter  Sign up for the latest Software Intelligence news Subscribe Now <>
Open source is part of almost every software capability we use today. At the  very least libraries, frameworks or databases that get used in mission critical  IT systems. In some cases entire systems being build on top of open source  foundations. Since we have been benchmarking IT software for years, we thought  we would set our sights on some of the most commonly used open source software  (OSS) projects. Software Intelligence Report <> Papers
In our 29-criteria evaluation of the static application security testing (SAST)  market, we identified the 10 most significant vendors — CAST, CA Veracode,  Checkmarx, IBM, Micro Focus, Parasoft, Rogue Wave Software, SiteLock,  SonarSource, and Synopsys — and researched, analyzed, and scored them. This  report shows how each measures up and helps security professionals make the  right choice. Forrester Wave: Static Application Security Testing, Q4 2017  Analyst Paper
Making sense of cloud transitions for financial and telecoms firms Cloud  migration 2.0: shifting priorities for application modernization in 2019  Research Report
N Natesan
N Natesan Principal Architect - SME
Proven technology architect, with 21 years of global experience in building enterprise platform, framework & application products. Expertise in digital transformation, cloud migration and microservices implementation mostly for banking and financial organizations across US & Europe.
Load more reviews
Thank you for the review! Your review must be approved first
Rating
New code

You've already submitted a review for this item

|