Architecture isn't Kubernetes
summary
Argues that architecture is designing relationships not tool choice, showing how a legacy monolith becomes microservices after three tries because teams’ mental models stay coupled; contrasts concrete tech — Kubernetes, Kafka, GraphQL and federated GraphQL — with sociotechnical fixes like systems thinking, culture change, systemic reasoning and building for emergent capabilities; uses a Mago case study where “create once publish everywhere” fails until teams map events, data ownership and interactions and then measure impact — promises five essential qualities that drive those changes.
AI-written summary · about
chapters (12)
- 0:00Introduction
- 3:35Talk origin
- 9:02Mago's system example
- 18:59Replacing software isn't solution
- 21:50Systems thinking skill
- 27:56Designing system relationships
- 32:35Culture change needed
- 37:59Architecture isn't opinions or tech
- 41:30Systemic reasoning decisions
- 46:11Balancing technical soft skills
- 49:35Old wisdom modern systems
- 54:37Q&A
related talks
41mArchitecture Isn’t Kubernetes
49mArchitecture is Designing Knowledge Flow
44mWhen your boss decides to have an architecture team…
45mArchitecture: The Stuff That's Hard to Change
43mSoftware Architecture, Design Thinking & Knowledge Flow
46mArchitecture Transformation Challenges
48mArchitecture: The Stuff That's Hard to Change
46mTHE too MANY FACES OF ARCHITECTURE