Platform Team Structures and Concerns
summary
Argues platforms are a layered, evolving stack (not one monolith) and gives concrete practices: use AWS as stable base, split internal vs external platforms, version-aware traffic routing, client libraries as the real interface, and garbage-collection of old versions. Shows large-scale evidence: a customer with 118 million customers and ~24,500 deploys in a month (~1,000/day) running Datomic, DynamoDB, Kubernetes/EKS, Lambda, Redis, VictoriaMetrics and Grafana, and demonstrates Wardley Mapping plus tooling like Soopra.ai and GitHub/adrianco/meGPT.
AI-written summary · about
chapters (10)
- 0:00Introduction
- 2:33What is platform engineering
- 6:45Layered platform stack design
- 11:15Platforms as evolving products
- 11:36Platform evolution with Wardley mapping
- 18:16New Bank’s platform strategy
- 25:43Balancing stability and change
- 36:41Versioning and dependencies
- 41:38AI-driven content management
- 42:03Q&A
related talks
41mPlatform Engineering for Developers, Architects & the Rest of Us
39mPlatform Engineering as a (Community) Service
33mPlatform engineering: Build your own PaaS
42mPlatform Engineering in practice — Why and How to start
45mThe Future of Platform Engineering
31mPlatform Health: A team model of platform evolution
38mPlatform Engineering in the Age of AI Teammates
31mThe 20 Year Platform – bringing together Kubernetes, 12-Factor and Functions