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...
For further actions, you may consider blocking this person and/or reporting abuse
I enjoyed this read! Thank you for your clear, concise writing and excellent use of diagrams. 😁
Thank you for the very kind comment Phillip.
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:
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?
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?
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"):
I think this is roughly what Kyle also replied, but written a bit more verbose. I hope this helps :)
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.
I would keep the bouncer as it allows you to keep that level of decoupling for any future enhancements you want to make.
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...
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.
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.
Thank you for the very kind comments. I agree that more articles on how to update/refactor legacy systems would be awesome!
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.
Thanks for sharing this, we are doing that right now and I didn't know that it actually had a name.
Same