"Monoliths are Simpler" and other lies we tell ourselves
summary
Industry advice to start monolith-first holds but often breaks: real projects at SoundCloud, DigitalOcean, WeWork and SeatGeek show the hidden costs. SeatGeek runs two monoliths (Python and .NET) with ~100 engineers, spends 12 people just on tooling, and struggles with >100 open merge requests and a six‑month accelerated project to migrate MySQL to Postgres. A later Python 2 → 3 upgrade needs a staff‑level engineer and causes performance surprises; weekend traffic and an AWS Graviton instance change reveal single‑failure blast radius. Preconditions (provisioning, monitoring, RPC standards) and a 15–20‑engineer inflection are crucial.
AI-written summary · about
chapters (6)
- 0:00Start
- 14:34codebase hygiene is hard
- 16:08major changes are hard
- 17:42minor changes are also hard
- 19:39capacity planning is hard
- 20:55upgrades are hard
related talks
48mMicroMonolith
32mQuietly Strangling the Monolith - a real-world migration of a high traffic monolith
36mDo Proper Monoliths before You Do Microservices!
43mMicroMonolith - Top anti-patterns of distributed systems
44mDemonolith the Monolith Think Again!
41mThe monolith must die! - How to convince managers
06mDo proper monoliths before you do microservices!
39mWays out of a monolith