Embracing Microservices
summary
Argues that microservices often hurt when adopted prematurely: a six‑person team produced 68 services for a single customer and still ships rarely; Netflix grows to ~20,000 services only after years and ~2,000 engineers. Recommends start with a modular monolith, prefer one service per repo, favor async/eventual consistency with idempotent consumers, and use the transactional outbox pattern or CDC to avoid ghost events. Warns about dependency hell from a shared “common” module and labels the evolving center‑heavy architecture the majestic monolith.
AI-written summary · about
chapters (13)
- 0:00Introduction and speaker intro
- 3:40Microservices vs SOA history
- 10:01Core idea behind microservices
- 17:25When to split into microservices
- 21:20Distributed systems pitfalls
- 27:22Testing in microservices
- 28:03Monorepo vs repo per service
- 31:36Synchronous vs asynchronous communication
- 39:21Technology Zoo downsides
- 41:30Shared libraries and common modules
- 46:09DTOs and contract sharing
- 49:22Summary and key takeaways
- 51:05Q&A session
related talks
50mEmbracing Microservices
47mEmbracing Microservices
57mEmbracing Microservices
01h 00mMicroservices, Where Did It All Go Wrong?
55mMicroservices, Where Did It All Go Wrong
13mYou're not Netflix (Microservices, Monolith architecture)
49mChallenges in Implementing Microservices
47mMicroservices? Monoliths? An Annoying Discussion!