3 ms·
So... keep modules separate, use queues and databases to communicate between modules, make sure the queues and databases are a separate process from the monolit
by iameli 8y ago
So... keep modules separate, use queues and databases to communicate between modules, make sure the queues and databases are a separate process from the monolith.
This sounds a bit less like a monolith and a bit more like a bunch of microservices that you've welded together in one container. Which is great! If you're disciplined about maintaining that, it will be very easy to spin off these individual modules as their own microservices when the time comes.
But I'm not sure that this constitutes an argument for monoliths > microservices.
- rossdavidh 8y agoWhat is presented here as a monolith is, however, what the word "monolith" means in current design conversations that I hear in workplaces. Also, I don't think the article was trying to advocate monoliths > microservices, but rather more like "it's ok to use a monolith if that works, and at first it probably will". Because true microservices introduces a lot of infrastructure work at the very beginning, when you desperately need to be working on code for your basic product.