Lessons from Running Developer Platforms & Communities
summary
Argues that internal developer platforms fail for human reasons not tech, recommends treating a platform as a product, starting with one pilot app (like an ATM or store locator), and building defaults for logging, monitoring and security so teams can get logs for the last six hours. Notes Kubernetes gives a “blinking cursor” and JPMorgan Chase runs 1500 applications on their platform. Emphasizes branding, platform advocates, and running developer toil audits; expects ~1–2 years to reach escape velocity.
AI-written summary · about
chapters (12)
- 0:00Introduction
- 2:02What is platform engineering
- 5:07The dream of software
- 10:46The role of Kubernetes
- 14:45Platform as a product
- 18:31Best practices overview
- 22:42Avoiding developer pitfalls
- 27:16Build vs buy and innovation
- 30:52Human and cultural change
- 35:28Community and marketing
- 42:00Getting started strategies
- 53:37Q&A and conclusion
related talks
26mLessons Learned from 7 years of Running Developer Platforms
32mLessons Learned from 7 Years of Running Developer Platforms
33mWhy You Should Treat Your Platform as a Product
33mLessons learned from 7 years of running developer platforms
54mDeveloper experience platforms
40mLessons Learned Building Developer Platforms
27mWhy Developer Platforms and a curated Dev Experience are a must have when scaling
40mInternal platforms in practice