If there are 50 commits in every release, and a 2% chance of a given commit breaking something, then in expectation every monolith deploy gets rolled back. As release engineering gets harder, time between deploys grows, so number of commits per deploy grows, so release engineering gets harder still.

Microservices are one way out of that cycle. But then you need teams to run a distributed scheduler, service discovery and load balancing, RPC standards and libraries, IDL registry, central build system, time series metrics collection and reporting, distributed tracing, a standard framework per language, etc, etc. My employer has at least one person working full time on each of those list items. Some have more than 50. And I wouldn’t dream of doing microservices without them.

At least whatever’s in Martin Fowler’s article [0], and more.

A word of caution: any microservices you do before you’ve actually productionized and standardized all that stuff become very painful tech debt.

https://martinfowler.com/bliki/MicroservicePrerequisites.htm...