So you’ve decided to do something about that piece of legacy code that is taking too much of your team’s time. Then you should be aware of the strangler pattern.
Your Options
When dealing with a piece of legacy code, you basically have three options:
- do nothing
- refactor
- rewrite
I’ve written about the first option, when it’s OK not to touch the legacy software.
I’ve also written a lot about refactoring and specifically about the choice between refactoring or rewriting. If you’ve been following this blog, you know I prefer a refactor.
But sometimes, a rewrite is necesary. Like when you’re stuck with an application full of technical debt, running on a platform that is no longer supported and for which you can’t find any new developers anymore.
One option for rewriting the application is the strangler pattern.
The Strangler Pattern
The idea is simple, the execution not so.
But let’s start with the idea. You start by putting a facade in front of your legacy application. This could be an API for example. Ideally, an API that matches the future direction you wish to take.
This is what it looks like:
Your facade just relays the calls through to the legacy application and returns any results. You can now point your client applications to the new API.
The facade will contain some logic because certain “new” API calls won’t match the “old” API as exposed by the legacy application. But it should only contain such “coordination” logic, no business logic. Because in the end, we aim to remove the facade.
Now, we gradually start moving features from the legacy application to new components:
As you can see, it’s OK if the new applications still need some communication with the legacy application. Rome wasn’t built in a day!
After a while, you should end up with a situation where you can decomission the legacy application:
You should now be able to remove the facade.
Advantages
One great advantage of the strangler pattern is that it allows you to rewrite your legacy application, but not with a big-bang approach. Instead of having developers work for months or years on an application that is never run in production, you can release rewritten parts to production regularly.
This ensures your team isn’t working in a void and that you can track progress. Real progress, because new pieces of code are already being used in production. As opposed to progress in a project management system for a new application that nobody knows for sure works.
Dangers
The end goal should be for the facade to disappear. If you don’t remove it, you end up with a sort of API gateway that you need to maintain. There are existing API gateway technologies out there that you can purchase so that you can focus on your core business.
If it seems impossible to remove the facade, because it contains important logic, then maybe the API of the facade wasn’t well designed. Or maybe it was designed to the best of your knowledge, but things changed and now your stuck with it. Then it seems you have a new piece of technical debt at hand!
Another thing to consider is that this is often a long-term effort where everyone must be on board. Having one team work on the facade and the new applications, while another keeps adding technical debt to the legacy application is a recipe for failure.
In such a case, you should coordinate teams and let everyone work on the rewrite. Also, try to keep additions and changes to the legacy application to a minimum.