Use a Strangler to Kill your Monolith
The strangler pattern can help your company move forward
Implement a strangler application with these steps:
- Stop all new development on the monolith
- Adopt a heavily abstracted code by interface policy
- Build New functionality monolith adjacent using interfaces and abstractions to their fullest degree
- Find a cluster of functionality that should not have been in the application and pull it out
- Rinse and repeat
You live under a monolith
Your company has a software system that was built in house that is in the businesses mind “Our application is only 11 or 12 years old, we cannot possibly rewrite it for the next 3 years.” You know the horrible truth, under the covers there are mountains of code that is by and large untestable, a database that has been hacked and kludged to the point of being not much more than a file system full of spreadsheets, and most troubling there are magic triggers and nightly batch jobs that keep the whole system running through restarts, cache dumps, and brute force.
To be clear, when your system was built, is was state of the art. The database was normalized to the appropriate level. The business layer held all of the business rules. There was a discrete service layer providing data to the UI. Then life happened and your system, like all things started to return to chaos.
Enter the strangler pattern
The Strangler Pattern is so named because of a group of plants known as strangler vine. These vines weave their way up whatever tree they happen to find in their search for sunlight. Once they find a host that can give them access to sunlight, they multiply. Vines will continue to exploit the height and compete with the host tree for valuable resources until the point where they in fact kill the host tree, becoming only a collection of vines.
While this metaphor is a bit extreme, it is a very good analog for what the strangler applications can do over time, replace the original monolithic application with a set of smaller applications that are more modern and can more easily meet that business needs.
Stop all new development on the monolith
While work cannot stop entirely monolith, you can be much more selective about what work is done and what features are good candidates for new development.
Here are a list of things to consider:
- Bugs, security, and UI changes — Can, and should, still be done in your original application
- Creation and Modification of reports — Because of the unknown magic that might be baked into reporting, this work should remain in the monolith
- New functionality — If you are adding new functionality from scratch, you should strongly consider building it outside of the monolith.
- Use a separate database
- Build a data service that is specific to the data not the UI
- If the UI is not conducive to mixing pages from disparate sources, at a minimum, separate the data into a separate service that can be leveraged by your client.
Abstract, abstract, abstract
Abstraction is one of those things that monoliths abandon over time, it is usually deemed to hard or to time consuming to keep a good layer of abstraction within your application. As you build a strangler application keep these things in mind:
- Code your services to be restful or at least rest-like if possible
- Never connect 2 different 3rd party systems directly
- Build a service between your code and for example SalesForce
- Build interfaces in external libraries that both sides of communication can use
- Do not use “Special Knowledge” of either system within the other system
Build new functionality monolith adjacent
Find the functionality that doesn’t match and pull it out
All applications have at least one thing that should have put somewhere else but because of existing constraints ended up in your application. Usually that will make a good candidate for extraction and building into a monolith adjacent service. Here are a few things to think about in your search:
- Try and describe exactly what the application does in a single sentence or two. If you had anything that you said “oh yeah, it does this other thing too” — that might be a good candidate for extraction.
- If you look at your database diagram and see a solo table or two seemingly floating on their own in space –that might be a good candidate for extraction.
- If your UI has a page with a special area for admin, and another for super users, and finally a third for the “Real Users” — you should look closely at if you could move the admin into its own application.
Retrospect and iterate
After you have moved one application, assess the pros, cons, and what could be different, then do it again.
Microservices ?
I have worked very hard to not mention microservices in this post because the term brings with it a lot of baggage. The tips listed above could certainly be addressed with a microservice architecture but you could just have aseries of “small” services providing data and web pages without being a single purpose microservice.
In summary
Many companies have software systems in the 10-12 year old range. Most of these applications were built when giant monolithic architectures were the style. Using the Strangler application pattern will allow you a path to move forward to get out from under the weight of your monolith.
The only way out from under the weight of your monolithic applications is to apply a strangler application architecture.~Tal McMahon