Menu
Just recently I came over an idea called the Application Strangler Pattern. As I understand it it is a solution to the problem with large legacy systems. The idea is to create a new application around the old application. The cost and risk of this will be much less than a complete rewrite of the system. Slowly, over time, the new application will do more and more of the work and eventually strangle the old legacy application. In the mean time developers get to work in a clean, new system with higher efficiency and hopefully producing much better code.
Where I work now we have come to the point were new functionality, even seemingly trivial things, takes a long time to develop, with a high risk of breaking something. We sit on about a million lines of code, with unit test coverage of perhaps 1-2%. The system is a SOA system using web services (neither is really necessary) and is more procedural in style than object oriented. The system is both web & win, all written in .net programming languages.
Finally the question: In considering this new idea/pattern, I want to know if anyone has had any experience with using this pattern they would like to share. For example, what would be a good way of implementing it (hooking up to events from the old application, for example)? Also, if anyone has any thoughts on the subject, why it would be a good or bad idea, that would be appreciated as well.
References:
892
Understanding the Strangler pattern The Strangler pattern is one in which an “old” system is put behind an intermediary facade. Then, over time external replacement services for the old system are added behind the facade. The facade represents the functional entry points to the existing system.
The strangler application consists of two types of services. First, there are services that implement functionality that previously resided in the monolith. Second, there are services that implement new features. The latter are particularly useful since they demonstrate to the business the value of using microservices.
The strangler fig pattern was introduced by Martin Fowler as a way to manage risk when modernizing or rewriting large, monolithic systems. The pattern is an analogy for a type of plant that begins life as a vine growing alongside an older, established tree.
To implement the Strangler Pattern, you can follow three steps: Transform, Coexist, and Eliminate. You can develop a new component, let both the new and the old component exist for a period of time, and finally terminate the old component.
The biggest problem to overcome is lack of will to actually finish the strangling (usually political will from non-technical stakeholders, manifested as lack of budget). If you don't completely kill off the old system, you'll end up in a worse mess because your system now has two ways of doing everything with an awkward interface between the two. Later, another wave of developers will probably decide to strangle what's there, writing yet another strangler application, and again a lack of will might leave the system in an even worse state, with three ways of doing things.
If the project is large, run from multiple regions, then you HAVE to get global consensus on what the final state should look like and how everyone is going to cooperate to get there. While the old app is being strangled, it's vital for remote teams to communicate every day, cooperate on the work if possible by doing remote pair programming, and resolve any misunderstandings or disagreements as soon as they arise. Otherwise there's the danger that each regional team will decide to write their own strangler application and they will meet somewhere in the middle and battle it out, leaving the system even worse.
Whatever you do, do not do the refactoring/strangling in a different branch from the main stream of development. The merge difficulties will become insurmountable.
I've seen critical systems that have suffered both of these fates, and ended up with about four or five "strategic architectural directions" and "future state architectures". One large multi-site project ended up with eight different new persistence mechanisms in its new architecture. Another ended up with two different database schemas, one for the old way of doing things and another for the new way, neither schema was ever removed from the system and there were also multiple class hierarchies that mapped to one or even both of these schemas.
Finally, if you're introducing technologies that are new to the team or to support/maintenance staff (e.g. adding reliable async messaging to what is currently a synchronous three-tier client/server architecture) then you have to ensure that there are experienced technical leads on the project who know how to build systems with that technology, and support those systems. And those tech leads have to stick with the project for some time after the old app has been fully strangled. Otherwise, the architecture will degrade as inexperienced developers modify it in ways they know but not in ways that fit with the new architecture.
51
The big risk of this pattern is that you end up bodging both the old code AND the new code to get the behaviour you need, especially if the old code was never designed to be strangled (i.e. does not present clean consistent interfaces).
My experience with this has been that debugging becomes harder over time as it's unclear whether problematic functionality has arisen in the new code or the old code (or a shared problem between the two).
I know Martin Fowler talks about writing code that is designed to be strangled, but in my opinion that is simply another way of saying that modular design is good, mmmkay; it's non-controversial and fairly obvious.
33
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
