Microservices, Where Did It All Go Wrong
summary
Argues microservices often devolve into costly distributed monoliths because teams misread “micro” and split by convenience, not domain; cites 30–40 developers as the rough threshold where independent services start to make sense and warns of estates that require 34 network calls to render a UI. Points to concrete tech causes (Docker, Kubernetes, AWS Lambda/Step Functions, messaging, sagas) and proposes a pragmatic middle path using macroservice boundaries, 12‑Factor app patterns and proper domain decomposition to reduce operational overhead.
AI-written summary · about
chapters (11)
- 0:00Microservices introduction
- 2:35Software components fundamentals
- 8:52Microservices benefits
- 18:18Over-granularity issues
- 23:32Service boundary missteps
- 27:47Ownership cost and bottlenecks
- 30:57Pragmatic microservice advice
- 41:04Monoliths and subdomains
- 43:51Macro services solution
- 49:26Deployment and process models
- 54:43Summary
related talks
44mMicroservices, Where Did It All Go Wrong
01h 00mMicroservices, Where Did It All Go Wrong?
43mPanel: Microservices, Where Did It All Go Wrong
42mMicroservices are Not Worth the Trouble!!??
43mHow to Avoid Doing Microservices Completely Wrong
57mEmbracing Microservices
01h 02mDesigning Microservices
01h 08mWhy you should never build Microservices - and why we do it anyway