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 v... [Read Full]
 

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?

 

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 :)

 

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.

 

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 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.

 
 

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

 
code of conduct - report abuse