Ways out of a monolith
summary
Argues that a monolith becomes harmful when it’s simply too big for scale, ownership and fast builds, causing costly full-stack scaling, slower CI/CD and bigger, riskier deploys. Presents four DORA metrics tied to business value: deployment frequency, lead time for change (goal <1 hour), change failure rate and time to restore. Recommends the strangler pattern with a two‑week spike then iterative extraction; cites a retail shop example that first moves product frontend then backend and proves the approach works.
AI-written summary · about
chapters (18)
- 0:00Intro
- 1:00Agenda
- 2:32What is a monolith
- 3:15What is the alternative
- 3:45Monolith
- 6:10Scalability
- 11:00Build deployment frequency
- 17:45The bottleneck
- 19:30Independence of change
- 21:40The extremes
- 22:55Why should business managers care
- 25:15Dora metrics
- 28:40Strangler pattern
- 31:00Mr Specs example
- 31:55First step
- 32:30Second step
- 33:02Why did we do it
- 34:25Summary
related talks
40mThe monolith must die! - How to convince managers
41mThe monolith must die! - How to convince managers
44mDemonolith the Monolith Think Again!
32mQuietly Strangling the Monolith - a real-world migration of a high traffic monolith
55mArchitectural Patterns for Rapid, Reliable, Frequent and Sustainable Development
43mModular Monoliths: The Architecture That Scales w Your Domain
01h 02mTools for simplified large scale systems
46mLove Your Monolith