Demonolith the Monolith Think Again!
summary
Argues that incrementally extracting microservices usually fails, wastes years and creates more technical debt; uses the Palace of Westminster flooding and 46–76 year repair estimate to show inertia, cites a 10-year rewrite case where incremental work became a full rewrite, and notes JDK modularization took 12+ years to land. Shows specific blockers: monolithic single databases, hidden jobs, custom frameworks, on‑prem customers, and explains when hybrid or full rebuild yields lower long‑term cost.
AI-written summary · about
chapters (14)
- 0:00🚀 Introduction: Why the "Demonolith" Concept is More Complex Than You Think
- 3:15The Monolith – A Real-World Example of the Palace of Westminster
- 5:00The Monolith: Is It Really Just a Mess?
- 8:45The Pitfalls of Trying to Incrementally Extract Microservices
- 11:30The Real Cost of Demonoliting: A 10-Year Rewrite Case Study
- 14:00Why Most Organizations Don't Have the Luxury of 10+ Years for Refactoring
- 17:00The Common Characteristics of Monolithic Applications
- 22:00Technical Debt and Its Role in the Demolition of Legacy Systems
- 25:00How Domain Changes and Lack of Proper Design Complicate the Process
- 28:00The Dangers of Attempting to Extract Microservices from a Monolith
- 32:00The Data and Security Issues When Breaking a Monolith into Pieces
- 36:00Leadership and Organizational Challenges: Can Your Team Manage the Change?
- 40:00Rebuilding vs. Demolishing: Why Starting Over Might Be the Better Choice
- 42:30Conclusion: Hybrid Approaches, Incremental Change, and the Importance of Leadership
related talks
46mLove Your Monolith
39mWays out of a monolith
55mArchitectural Patterns for Rapid, Reliable, Frequent and Sustainable Development
55mIs it Time to Abandon Microservices? Modular Monoliths Rescue Your Wallet!
43mMonolith? Microservices? Who cares?
59mMajestic Modular Monoliths
43m"Monoliths are Simpler" and other lies we tell ourselves
40mThe monolith must die! - How to convince managers