Here's my take on microservices: It's a form of modularization. Like all modularization it can be useful to uncouple larger parts of a system - to enforce an ar

Here's my take on microservices: It's a form of modularization. Like all modularization it can be useful to uncouple larger parts of a system - to enforce an architecture, avoid unintended cross-dependencies, make explicit the dependencies that are intended, to allow teams to work more independently, and to allow the different parts of the system to be be developed, compiled, built, deployed (and sometimes scaled) independently. But all this comes at a cost - you have to know where the module boundaries are, because moving these is much harder. The flexibility that you've gained within each module comes at the cost of making it harder to move the border between modules. It's very easy to put down a module border in the right spot, and you make a refactor (needed for cleanup or performance improvement) go from tricky to impossible. E.g. that piece of info needed in this module now canonically lives in the other one. Or we accidentally add a couple N's to the time complexity of an algorithm that works on data in multiple modules. But getting the borders right on the first try is hard, unlikely even. Where those borders should be depends on a lot of things - the user domain, the performance characteristics, the development team(s) (Conway's law and all that) and the ways in which the business requirements change. For that reason, I think most successful modularizations are either done by breaking down an existing monolith (providing these insights) or by basing it on a known running system that is "close enough" in its needs and environment.