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"):
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.
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 :)
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 would keep the bouncer as it allows you to keep that level of decoupling for any future enhancements you want to make.
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.