Strangler Patterns: The Design Thinking Approach to Modernizing Outdated Software
If your engineering team is struggling to make new releases once per year, if it feels like more bugs than features are produced when code is published, or if it takes new engineers a long time to come up to speed on the legacy application, it’s time to modernize the…
If your engineering team is struggling to make new releases once per year, if it feels like more bugs than features are produced when code is published, or if it takes new engineers a long time to come up to speed on the legacy application, it’s time to modernize the existing application to become a cloud-native event-driven architecture. Strangler Patterns are an effective tool to achieve this modernization.
What is a Strangler Pattern?
The Strangler Pattern is named after the way that fig trees grow, which is very sneaky and powerful. A fig tree begins as a sprout that grows and wraps itself around a separate adult tree, and as they get larger they slowly start to strangle out the host tree. Eventually the host tree no longer exists and only a strong fig tree remains in its place. Strangler Patterns work in a very similar way, where the host tree is monolithic legacy software code.
The idea that legacy code can be replaced in one fell swoop is an idea that usually leads to disaster. A more meaningful (and less risky) approach would be to identify where small pieces of functionality can be added or upgraded and integrated into the legacy application.
Why Would You Use a Strangler Pattern?
Updating legacy code is typically a huge undertaking. In most cases, whatever application the legacy code is supporting is being actively accessed by users on a regular basis. Attempting to completely rewrite legacy code without implementing a modernization tool like a Strangler Pattern makes the task of modernization never-ending. Should you (miraculously) succeed at an all-in-one-go modernization of existing code, the resulting upgrade would be a jarring experience for users.
One common approach to implementing a Stranger Pattern is to conduct a complete survey of all the existing functionality and map out the entire journey of strangling the legacy system. While some architects like to map an entire strangle out from beginning to end, we find that that approach is typically neither effective nor efficient. A preferable approach would be to start with the end in mind while focusing on the most important thing to do now. When that work is finished and in production and the value of the update has been realized on the user end, the engineering team will loop back around to find a new now.
How Can Event-Driven Architecture Support a Strangler Pattern?
The main purpose of Event-Driven Architecture is to decouple microservices within an application so that they can communicate and operate independently of each other. If one component of an EDA stops working, the other components are unaffected. Strangler Patterns align with the same philosophy: Only break one thing at a time (kidding! Kind of).
The use of Event-Driven Architecture allows a service bus to connect to the legacy database of an application and use eventual consistency to integrate new features with the legacy system. In this case, the event bus can be thought of as that first fig tree vine to wrap around the legacy application.
How to Get Started with a Strangler:
Using eventual consistency, we can easily create a read-only copy of all production data. This eventually consistent pattern presents a number of easy, quick wins when starting a Strangler Pattern: Reporting and Search as a Dashboard (SaaD) patterns.
A reporting subsystem that is implemented using a Strangler Pattern and eventual consistency will provide near-real-time data for reporting. Rather than plugging directly into the main database, which can severely slow down the application, the reporting subsystem isolates the performance impacts of data analysis.
Another common first step is implementing Search as a Dashboard (SaaD). Rather than plugging directly into the main database, which can (again) severely slow down the application, the search subsystem isolates the performance impacts of search.
Essentially, as components of an application are strangled separately and one at a time, they collect an eventually consistent copy of data from the service bus without impacting the rest of the application.
Strangler Patterns are an excellent modernization tool for an engineering team that is struggling managing a monolithic legacy application. In some cases, starting from scratch is the best way to go. In many other cases, a well-mapped and well-integrated strangle can protect an application from an array of weaknesses including security breaches, loss of critical data, and loss of user participation while providing a predictable pace of innovation.
If Event-Driven Architecture is Worthwhile’s first choice for building highly performant systems (and it is), Strangler Patterns are our choice for supporting that architecture as it evolves.