The monolith must die! - How to convince managers
summary
Argues that using Google Cloud’s DORA metrics (deployment frequency, lead time, change failure rate, time to restore) makes a business case for splitting a too-large system, not rewriting it. Recommends the Strangler pattern, cutting front end first (example: Mr Specs moved one product page out, lifted deployment frequency from twice a week to many), then replacing search via a bought SaaS; a two-week spike by three devs proved the search migration viable and delivered measurable customer-facing improvement.
AI-written summary · about
chapters (14)
- 0:00Intro
- 0:35What is monolith
- 1:22What is a monolith
- 5:08The problems
- 10:16The goal
- 11:36The book
- 13:50Metrics
- 16:40Deployment frequency
- 19:25Lead time for changes
- 26:19Putting the arguments together
- 26:54The approach to choose
- 29:14Mr Specs example
- 32:12Mr Search example
- 34:54Never satisfied
related talks
40mThe monolith must die! - How to convince managers
39mWays out of a monolith
32mQuietly Strangling the Monolith - a real-world migration of a high traffic monolith
01h 02mTools for simplified large scale systems
43m"Monoliths are Simpler" and other lies we tell ourselves
40mWhy your best engineers should look after the worst systems
36mIt's Simple...
01h 29mMonolithic Delivery