Microservices, Where Did It All Go Wrong?
summary
Argues that microservices often become distributed monoliths when teams split code by convenience not domain, cites Twitter’s timeline requiring 64 calls and “death star diagrams” showing 500–2,000 tiny services as evidence, and describes rebuilding patterns from step‑functions and lambdas into a single process at Prime Video as a failure mode when orchestration is misapplied. Recommends domain storytelling, bounded contexts, 12‑factor process types, and using larger macro service boundaries or a modular monolith when ownership, ACID needs, or team size make many small services fragile.
AI-written summary · about
chapters (33)
- 0:00Introduction
- 1:53Who am I
- 2:03Brighter
- 2:37Agenda
- 3:18Fundamental Theory
- 4:51Manageably Small
- 5:43Whats a module
- 6:36Whats a component
- 7:52Service vs component
- 9:06Componentization via services
- 11:39Benefits of microservices
- 14:55Microservices Service Premium
- 16:45Why have things gone wrong
- 16:57The word micro
- 18:37The death star diagram
- 23:02The problem
- 25:13What do we get
- 27:30Cost of ownership
- 28:21Services
- 29:55Prime Video
- 32:01Advice
- 34:09Scenarios
- 36:27Logical Architecture
- 40:10Domain Storytelling
- 41:31Domain Boundaries
- 43:22Development Architecture
- 47:22Monolith
- 48:52Classic microservices
- 49:54Complex domains
- 51:21Multiple small domains
- 53:06Macroservices
- 57:03Multiple processes
- 58:58Microservices
related talks
55mMicroservices, Where Did It All Go Wrong
44mMicroservices, Where Did It All Go Wrong
43mPanel: Microservices, Where Did It All Go Wrong
57mEmbracing Microservices
43mHow to Avoid Doing Microservices Completely Wrong
38mMicroservices, a bittersweet symphony
47mEmbracing Microservices
47mMicroservices? Monoliths? An Annoying Discussion!