DEV Community

Cover image for How to Breakthrough the Old Monolith Using the Strangler Pattern

How to Breakthrough the Old Monolith Using the Strangler Pattern

Kyle Galbraith on January 29, 2019

Admittedly, the term "Strangler Pattern" doesn't sound all that great. But it is actually a pattern that can prove to be very useful for a wide var...
Collapse
 
walkhard13 profile image
Phillip Smith

I enjoyed this read! Thank you for your clear, concise writing and excellent use of diagrams. 😁

Collapse
 
kylegalbraith profile image
Kyle Galbraith

Thank you for the very kind comment Phillip.

Collapse
 
thermatix profile image
Martin Becker

This is super useful, recently I've been thinking about how one might break a monolith into microservices and this answers it perfectly!

I do have two questions:

  1. Once you've moved all bits of the monolith into microservices, would you remove the bouncer and instead modify nginx/apache/etc to direct requests to relevant microservices instead?

  2. Or could you instead change the bouncer into a microservice that receives requests from nginx/apache/etc and instead of redirecting, send a message onto a message bus service like Kafka or RabbitMQ and instead communicate that way?

Collapse
 
daanwilmer profile image
Daan Wilmer

I don't have much experience using microservices per se, but a more general software engineering background, so here's my two cents (also I prefer the term "facade" instead of "bouncer"):

  1. The job of the facade is to present a single interface to the outside world (in this case for compatibility), regardless of the inner workings. If you were to remove the facade and instead use your server config to glue everything together, wouldn't your server config become the facade? Now the question is: how would you like to manage your facade or interface? In the server config, or in the code next to (but largely independent from) the code of the other components? I'd say the latter.
  2. I'm not familiar enough with Kafka or RabbitMQ and what they do, but I can say this: if you're using it as a way to communicate between the facade and the individual components, then go ahead. If you want the individual components to communicate with each other as well, then beware of coupling. You might end up with individual components which communicate so much with each other over the bus, instead of through the facade, that they become/remain tightly coupled, and it's still hard to change one component. Remember: the aim of refactoring is that each component has a single responsibility with a single interface (although that might not be feasible within the constraints that you have)

I think this is roughly what Kyle also replied, but written a bit more verbose. I hope this helps :)

Collapse
 
thermatix profile image
Martin Becker

How would we send messages to other Micro services through the facade? I realise this isn't an implementation blog post but It's not really mentioned.

Collapse
 
kylegalbraith profile image
Kyle Galbraith

I would keep the bouncer as it allows you to keep that level of decoupling for any future enhancements you want to make.

Collapse
 
xtofl profile image
xtofl

This is a clear explanation! Thanks!

I've seen the Big Bang fail before (... I initiated it :(, but only once, luckily). And I've seen this Strangler pattern work... for some time.

If you don't aim to finish Strangling your monolith into the New Style, after a few years you'll end up with a half-migrated system.

And then comes a new insight, a better technology, ... you want to reshape your Half-Monolith into. You could apply the same technique again, but you'll have two generations of software to migrate piecemeal.

I would conclude that "The Strangler pattern works for systems up to a certain magnitude".

mikehadlow.blogspot.com/2014/12/th...

Collapse
 
kylegalbraith profile image
Kyle Galbraith

Excellent point! Often times a monolith if far better than a totally fragmented system where half the pieces are one way and the other half another.

Collapse
 
bacchusplateau profile image
Bret Williams

Nice writeup. We implemented something similar 5 years ago and called it the Bridges Pattern, which did a redirect to the new system if the config data had the feature marked as "ported". We need more articles written on how to safely refactor legacy code. Most developers won't get to work on greenfield but it is much more sexy and fun to write and read about.

Collapse
 
kylegalbraith profile image
Kyle Galbraith

Thank you for the very kind comments. I agree that more articles on how to update/refactor legacy systems would be awesome!

Collapse
 
cscarlson profile image
cScarlson • Edited

Not that I didn't enjoy this read -- I totally did. I just wanted to point a few things out because we tend to rename things in our industry and then say it's something radical and new -- especially if it's the exact same pattern as something else, but just applied to a different scale. And, we do this a LOT. So, here's what you described with "The Strangler Pattern:

The Strangler Pattern is a Refactor Pattern known as Branch By Abstraction (BBA, Martin Fowler et al). We use an API Gateway -- which is, more or less, The Mediator Pattern (GoF) applied to a higher scale across an HTTP Web API -- to facilitate stability across time and implementation-space. One can think of the "Bouncer" or "Facade" (Gateway) as the Director from The Mediator Pattern, because, a Director inherently implements The Facade Pattern. That is, it unionizes multiple interfaces (Facade) while also implementing triggers & routing across those submodules which it encapsulates.

So in a nutshell, the TL;DR of it is: when migrating an app, use a Gateway for your BBA pivot.

Having said all that, I know we're still going to pretend that this is some new, radical, hip, unheard of pattern... Ya know, because, "components" are not modules, and "thinking in components" is not SOLID. That is, we'll just relabel it and pretend we're inventors.

Anyway, I still like the article.

Collapse
 
bwolkerstorfer profile image
Bernhard Wolkerstorfer

Thanks for sharing this, we are doing that right now and I didn't know that it actually had a name.

Collapse
 
thinkdigitalsoftware profile image
ThinkDigitalSoftware

Same