The Strangler Pattern: Kill Legacy Like a Boss

Image from Britannica

Quick note: If the theoretical aspects of this pattern are not relevant to you and you prefer to get hands-on immediately, feel free to skip to the Real World Example section.

Introduction

Definition of the Strangler Pattern

The Strangler Pattern is a software design and architectural pattern used in the context of legacy system modernization or application migration. The pattern’s name comes from the way certain plants, like strangler figs, grow around host trees, eventually replacing or “strangling” them entirely. Similarly, the Strangler Pattern aims to replace or evolve an existing system gradually, without causing any significant disruptions to the overall system functionality.

The Strangler Pattern and Its Origin

The Strangler Pattern is a software design and architectural pattern that was first introduced by Martin Fowler, a renowned software engineer and author, in his book “Patterns of Enterprise Application Architecture.” The pattern draws its name and analogy from the way certain plants, like strangler figs, envelop and eventually replace host trees in nature.

In the context of software development, the Strangler Pattern was coined to describe a gradual and non-disruptive approach to modernizing legacy systems. It was developed as a response to the challenges associated with dealing with aging, monolithic applications that are often difficult to maintain, inflexible, and lacking in modern technology capabilities.

How the Pattern Addresses Legacy System Modernization Challenges

Legacy systems pose several challenges when it comes to modernization, including:

• Risk and Complexity: Legacy systems often have complex codebases and undocumented functionalities. Undertaking a full-scale rewrite can be risky, time-consuming, and costly. The Strangler Pattern helps mitigate these risks by allowing modernization to occur incrementally, one component at a time.
• Business Continuity: Many legacy systems are critical to an organization’s daily operations. Interrupting these systems for a major overhaul can lead to disruptions, downtime, and financial losses. The Strangler Pattern enables the coexistence of old and new components, ensuring that the system remains functional during the migration process.
• Inflexibility: Legacy systems may not support modern technologies or meet current business requirements. The Strangler Pattern addresses this by allowing organizations to gradually introduce new technologies and features while retaining existing functionality.
• Resource Allocation: A complete rewrite of a large legacy system requires significant resources, including time, money, and skilled personnel. The Strangler Pattern enables organizations to allocate resources based on priority, focusing on areas that require immediate attention.

Identifying Scenarios Suitable for the Strangler Pattern

The Strangler Pattern is most suitable in scenarios where organizations need to modernize or migrate a legacy system, but a complete system rewrite is impractical or too risky. Some common situations where the Strangler Pattern can be applied include:

1. Monolithic Legacy Systems: When dealing with large monolithic applications that have grown complex and difficult to maintain, using the Strangler Pattern allows the gradual replacement of components, making the modernization process more manageable.
2. Business-Critical Applications: If the legacy system is critical to the organization’s day-to-day operations, a full replacement could cause significant disruptions. The Strangler Pattern enables continuous operation during the migration, minimizing downtime.
3. Limited Resources: When an organization lacks the resources (time, budget, or skilled personnel) required for a complete rewrite, adopting the Strangler Pattern allows for incremental modernization without overwhelming the team.
4. Mitigating Risk: The Strangler Pattern is ideal when the organization wants to mitigate risks associated with large-scale modernization projects, as each step is carefully validated before proceeding further.

Comparison with Alternative Modernization Approaches

The Strangler Pattern stands in contrast to alternative modernization approaches, such as the “big bang”, where an organization attempts a complete overhaul of the legacy system in one go. A comparison between the two approaches reveals the strengths of the Strangler Pattern:

• Risk Management: The big bang rewrite carries a higher risk due to its all-or-nothing nature, while the Strangler Pattern reduces risk by allowing incremental, validated changes.
• Time to Market: The Strangler Pattern allows for continuous delivery of improvements, while a big bang rewrite may take significantly longer to deliver value to end-users.
• User Experience: With the Strangler Pattern, users can access updated functionalities progressively, ensuring a smoother transition compared to the potential disruption caused by a big bang rewrite.
• Resource Utilization: The Strangler Pattern optimizes resource utilization by focusing efforts on specific parts of the system, whereas a big bang rewrite requires significant upfront investment.

Lets Simulate a Real World Example

Imagine we are working with a monolithic application responsible for managing an entire ecommerce order system. Typically, such applications have APIs exposed for each internally implemented module:

Let’s consider the scenario where the aim is to extract the checkout and payment modules from this monolithic application and transform them into independent services.

We must not forget that our monolith is currently providing all these services to one or more consumers. This means that we need to find a way to make this migration seamless. And that’s where the API Gateway comes to the rescue!

Extremely short introduction to the API Gateway

An API Gateway is a centralized server that serves as a single entry point for clients to access multiple backend services or APIs, simplifying access, improving security, and enhancing performance.

I told you it would be short..be sure to follow since I’ll be making an article on this in the coming weeks for sure. (despicable plug)

Let’s illustrate how our system would look with the addition of an API Gateway to our current architecture:

In essence, the API Gateway will serve as a proxy, connecting our consumers to the internal APIs.

Now, the real legacy butchery begins! We form two teams, each tasked with creating a new microservice that replicates the functionality of the current modules. However, they will use the latest version of the programming language, state-of-the-art web frameworks, and optimized databases for each specific use case.

Lets take another look at the solution architecture:

Once the services are implemented — and it’s important to note that we can migrate each endpoint one at a time, without waiting for the entire module to be completed in the microservice — that’s when the API Gateway truly shines. Let me provide you with a simple example of how it works.

We can create a Sandbox user, let’s call it “Sandbox-User,” and configure our API Gateway to handle requests from this user agent. When the HTTP request’s user agent matches “Sandbox-User,” the API Gateway will forward the request to the Payment Service and Checkout Service, bypassing the legacy endpoints.

Now our system is completely testable. We can perform all the checkout and payment operations through the new architecture using the Sandbox user.

Lets start the rollout (strangulation)

After ensuring that the checkout and payment services are ready for the production environment, we can begin routing real users through the API Gateway. This rollout process, also known as strangulation, can be implemented using various strategies. For instance, in a tenant-based API, we can start migrating tenants with the lowest throughput to minimize the impact. In the case of a global ecommerce platform, we can roll out the services country-by-country, beginning with those with the lowest throughput. Different rollout strategies can be applied, but the key is to phase the rollout gradually, starting with lower throughput and gradually increasing it until the legacy endpoints are fully discontinued.

Finally, when all of your users are successfully utilizing the new services, you can confidently press that delete button, bidding farewell to those old, outdated and nasty modules implemented in Visual Basic and SOAP.

In conclusion

the Strangler Pattern offers a powerful and pragmatic approach to modernizing legacy systems. By gradually evolving the architecture, organizations can reduce risk, maintain business continuity, and optimize resource utilization. The introduction of an API Gateway further enhances the migration process, providing a seamless way to connect consumers with the new microservices while coexisting with the legacy system.

Embracing the Strangler Pattern empowers organizations to modernize their systems incrementally, avoiding the pitfalls of big-bang rewrites. As the new services take over, the legacy modules can be gracefully retired, marking the end of an era and the dawn of a more scalable, efficient, and future-proof architecture.

So, don’t hesitate to adopt the Strangler Pattern and bid farewell to those old and nasty modules, embracing a more agile and resilient system for the future!

Resources

• Microservices.io — Strangler application
• Matt Heusser at Tech Target—Detailed intro to the strangler pattern
• Experience working at Farfetch 😄

If you enjoyed this article, you can help me share this knowledge with others by:👏claps, 💬comment, and be sure to 👤+ follow.