Platform Obesity, not Complexity, is killing our platforms
summary
Claim: platforms fail from accumulated bloat not inherent complexity, causing cognitive overload, operational friction, and stalled ROI. Concrete evidence: clusters left unpatched for four to five years, and earlier platform work supported 20–25,000 VMs with a team of five. Practical fixes: consolidate multiple Kubernetes management layers, remove excess controllers and policies, and say no more often—roughly 50% unnecessary additions turn out not to be needed. Goal: subtract until the platform fits actual skills, time, budget and business outcomes.
AI-written summary · about
chapters (16)
- 0:00Introduction and background
- 1:09What is platform obesity
- 3:58Consequences of bloated platforms
- 8:57The vicious circle of platform engineering
- 13:10Admitting platform struggles
- 15:56Designing within constraints
- 20:33The discipline of subtraction
- 23:03Designing for your constraints
- 26:17Avoiding organizational silos
- 31:13Boring platforms are good platforms
- 32:55Key takeaways and summary
- 33:17Q&A: Getting executive sponsorship
- 34:41Q&A: First steps to simplify
- 35:24Q&A: CRD usage and bloat
- 35:45Q&A: What is a field CTO
- 36:05Q&A: Handling unneeded features
related talks
40mPlatform Wars: The Battle Between Golden Paths and Spaghetti Pipelines
15mBreak through the complexity limit with platform engineering
23mBeyond the Buzz Building Developer Platforms That Drive Business Success
26mLessons Learned from 7 years of Running Developer Platforms
33mWhy You Should Treat Your Platform as a Product
51mTeam Cognitive Load as a metric to measure Platform impact
40mLessons Learned Building Developer Platforms
29mYour platform is not an island: building a platform for your ecosystem