Strangler pattern and how does it work?
- TechTutor
- Oct 17, 2023
- 3 min read
When compared to monolithic architecture, microservices architecture provides numerous advantages. As a result, many organisations are beginning to design new systems with microservices or converting old monoliths to microservices.
However, converting a large-scale monolithic application to microservices from the ground up is a difficult undertaking. It necessitates extensive architectural and development work and increases the organization's risk. Nonetheless, some well-established patterns and practises may aid in mitigating these dangers.
Let's look at how the Strangler pattern may be used to convert a monolith into microservices.
Migration from a legacy application system often requires heavy code rewrite processes. But rather than do a complete overhaul and take the system offline, it might be possible to implement a pattern that slowly deprecates a legacy system over time while incrementally adding new functionality.
This approach, coined by Martin Fowler as the strangler pattern, gradually updates monolithic application systems -- colloquially known as the "big ball of mud" -- while still keeping them running in production. Today, we'll explore what the strangler pattern is and how to implement it, along with use case examples.
What is the strangler pattern?
Picture a motorcycle that works, but could stand to undergo extensive overhauls that will make it run better. One option would be to completely take the motorcycle apart and spend months rebuilding until it works. However, how sure are you that it will run after you've finished replacing every part? And what if you want to use the motorcycle in the next few weeks, but can't while it's in the garage?
The solution there is to replace parts one at a time, ensure it works as expected, and move on to the next once it's done. This provides two major benefits. The first is that you can likely still run the motorcycle as parts are incrementally replaced, rather than having to wait for the rebuild. The second is that if a fix or replacement doesn't work, you'll have a much easier time identifying the problem since you do not have to examine everything at once. Eventually, you will end up with an updated motorcycle that never really stopped running.
The strangler pattern works in a very similar way. Rather than completely disassemble an application system and rewrite its code, this pattern offers development teams a way to incrementally update sections of code and functionality without the need to completely shut the system down. Eventually, all the services and components will be refactored to integrate with a new application system, and the legacy system can retire.
This means that the migration process can proceed as an iterative process rather than a complex rip-and-replace scramble. Development teams do not have to worry so much about implementing a second code base, but rather can focus on refactoring one service or function at a time. It also eliminates the need to create two separate teams -- one that manages the old code and another that manages the new code.
The strangler pattern in practice
The strangler pattern, as previously stated, is a software development and migration strategy used to gradually replace or modernise legacy systems with newer, more efficient, or feature-rich ones. It enables you to migrate from an older system to a new one without disturbing existing functionality or compromising the overall success of the project. The strangler pattern involves the following stages in practise:
Identify the Legacy System: Begin by identifying the legacy system that needs to be replaced or modernized. Document its functionality, dependencies, and any pain points or limitations.
Define the Replacement System: Design and develop the replacement system, which could be a new application, service, or architecture that provides the same or improved functionality. Ensure that it is modular and can be integrated incrementally.
Identify Strangling Points: Identify specific areas within the legacy system where you can introduce the replacement system incrementally. These are known as "strangling points." They can be functions, features, or modules that can be replaced without disrupting the entire system.
Gradual Replacement: Start replacing the identified strangling points one by one with their counterparts in the replacement system. This process may involve creating bridges, adapters, or APIs to enable communication between the old and new components.
Verify and Test: Ensure that each replaced component works correctly and doesn't introduce new bugs or issues. Comprehensive testing is essential at each stage to maintain system stability.
Monitor and Iterate: Continuously monitor the system's performance, both in terms of functionality and performance. Collect user feedback and make any necessary improvements to the replacement system.
Repeat the Process: Continue replacing other components and functionalities in the legacy system until the entire system has been strangled by the replacement. This may take place over several iterations and can extend over a long period.
Decommission the Legacy System: Once the entire system has been replaced, and the legacy system is no longer in use, it can be decommissioned. However, it's important to have a well-defined exit strategy for the legacy system, including data migration and archiving.
Comments