Platforms: Build abstractions, not illusions
summary
Argues that a real platform shows up when users build things on top that surprise the platform team; warns that defaulting cloud settings is not an abstraction but an illusion that breaks performance, cost or behaviour. Recommends designing interfaces by purpose (like renaming “gas pedal” to accelerator) and owning only what the cloud cannot (customer‑data semantics), organizing platform teams to enable fast developer feedback loops instead of doing ops work. Prefers fruit salad over fruit baskets and calls the adoption test the surprise test.
AI-written summary · about
chapters (20)
- 0:00The complexity challenge
- 1:36Shift left pitfalls
- 2:10Platforms as speed engines
- 13:25Testing for platforms
- 14:04The meta-truth of platforms
- 15:02Avoiding badge engineering
- 15:43Harmonizing for innovation
- 18:45Removing constraints
- 22:52The role of standards
- 27:28Standardization metaphors
- 28:38Platform teams and structure
- 29:22Dynamic vs static models
- 32:39Abstraction interfaces
- 33:16The jigsaw puzzle analogy
- 34:57Naming and purpose
- 36:33Human judgment in design
- 37:46Domain-specific platforms
- 40:59Metaphors for strategy
- 41:22Floating vs sinking
- 44:30Closing advice
related talks
46mPlatforms: Build Abstractions, not Illusions
58mPlatforms: Build abstractions, not illusions
34mPlatforms: Defying the laws of IT physics
51mThe Magic of Platforms
12mLightning Talk: Developer Advocate Plays Devil's Advocate: Platform Engineering Editi...
23mPlatform Engineering for Architects - Crafting Platforms as a Product
18mClosing keynote
29mPlatforms, Architecture and Sustainability