Why Your Platform Monolith Is Probably a Bad Idea
summary
Claim: platform monoliths become bottlenecks — they push cognitive load onto a single platform team, create a large blast radius and slow delivery. Examples: seven DevOps people trying to run infra for 25 teams; 40+ teams needing subplatforms; platforms scale usefully from ~100+ engineers. Tools and patterns that work: GitOps with Flux/Argo, Kubernetes + Cluster API and CRDs, operators to provision per-team clusters, Kafka (MSK) as managed service, and SRE/enablement via site reliability engineers. Outcome: monoliths often fail; opinionated abstractions and a golden path that shifts responsibility back to teams reduce bottlenecks, but increase management complexity and cost.
AI-written summary · about
chapters (9)
- 0:00Introduction
- 3:21Autonomy and systems
- 10:33Platform topology and teams
- 17:34The platform monolith challenge
- 21:26Resilience and evolution
- 26:52Platform as a product
- 30:36Technical implementation
- 36:54Summary of key lessons
- 39:02Q&A and conclusion
related talks
28mConvergence on Platforms
47mPlatform Team Structures and Concerns
11mDo you really need a platform team?
43m3 Ways You’re Screwing up Platform Engineering – And How to Fix It
46mBeyond DevOps: How and Why Companies Converge on Platform Models
26mThe common fallacies on platform building
39mPlatform Engineering as a (Community) Service
32mPlatform Engineering Is Not About Tech