The monolith must die! - How to convince managers
summary
Argues that Google DORA metrics (deployment frequency, lead time, change failure rate, time to restore) provide business-grade reasons to break parts out of a monolith: long build times (examples of 4‑hour builds) force deployment frequency down (companies here deploy every half year versus high performers every half hour) and inflate lead time for change, increasing bundled risky releases. Recommends a Strangler Fig approach: cut out product‑browsing frontend, replace internal search with an external service, measure page‑speed and deployment improvements before continuing.
AI-written summary · about
chapters (12)
- 0:00Introduction and agenda
- 1:15Defining the monolith
- 3:46Problems with monoliths
- 7:45Risks of microservices
- 9:30Finding the sweet spot
- 10:15Business case for change
- 12:03DORA metrics explained
- 15:43Linking metrics to problems
- 25:57Strangler Fig pattern
- 28:26Real-world example
- 31:58Conclusion and final thoughts
- 33:26Q&A session
related talks
41mThe monolith must die! - How to convince managers
39mWays out of a monolith
44mDemonolith the Monolith Think Again!
36mIt's Simple...
43m"Monoliths are Simpler" and other lies we tell ourselves
01h 02mTools for simplified large scale systems
47mMicroservices? Monoliths? An Annoying Discussion!
32mQuietly Strangling the Monolith - a real-world migration of a high traffic monolith