In my experience, microservices are an emergent property of Conway's law [1], essentially that a system's architecture will tend to ship it's team(s)' communica

In my experience, microservices are an emergent property of Conway's law [1], essentially that a system's architecture will tend to ship it's team(s)' communication structure. The biggest bottleneck to software engineering is communication between engineers, especially as teams grow beyond 3+ people working a single system. It becomes difficult to keep everyone on the same page about every design decision and change, which becomes obvious if your team does code reviews (imagine if every code change required 3+ approvals). Communication unfortunately scales O(n^2). As a result, What makes a "team" is it's leadership structure, I.e it's determined by the number of engineers who want to be leaders (which includes accountability and ownership). If you have a team with multiple leader-types who want more ownership, and a natural seam in the solution space emerges to spin-off, they will tend to become the communication hubs for other engineers, and eventually spin out into their own subteam with their own microservice. They'll want their own abity to release when necessary, and choose dependencies without needing to convince everyone beyond their immediate subteam. In short, if you're 1 person, microservices make little to no sense given the addition work and complexity involved. If you're more than 1 engineer, it depends on individual engineers willingness to be a lead and own a whole part of the system and become a communication hub. Companies like Google and Amazon will have lots of microservices because so many engineers want to be tech leads (either for promotion or self-fulfillment). [1] https://en.m.wikipedia.org/wiki/Conway%27s_law https://en.m.wikipedia.org/wiki/Conway%27s_law