Cloud-Native Architecture
summary
Cloud native is not a tool it’s an architecture choice: microservices can give independent deployability and polyglot freedom but often become a distributed big ball of mud unless teams enforce contracts automation and observability. Start with a modular monolith, split where seams exist, and only extract services with clear SLOs (three nines ≈ 9 hours/year, four nines ≈ 4.3 minutes/month). Use pipeline automation blue green and canary deploys, health checks circuit breakers chaos engineering and checklists to make scale and resiliency real.
AI-written summary · about
chapters (14)
- 0:00Welcome to cloud-native
- 3:14Distributed system challenges
- 8:25Monoliths vs microservices trade-offs
- 14:24Microservices not silver bullet
- 19:01Cloud-native without microservices
- 22:08Service level objectives explained
- 26:40Building production-ready services
- 31:57Deployment strategies for reliability
- 37:27Canary releases and A/B testing
- 40:16Automation to production
- 42:44Managing dependencies and faults
- 45:08No single points of failure
- 47:13Chaos engineering tests
- 49:37Q&A
related talks
35mCloud Native Architecture: Monoliths or Microservices?
05mCloud native or cloud agnostic? The questions you need to ask
14mCloud Native vs. Platform Native vs...
51mWhat Is This Cloud Native Thing Anyway?
55mArchitectural Patterns for Rapid, Reliable, Frequent and Sustainable Development
01h 00mEvolving to Cloud Native
39mA Decentralized Reference Architecture for Cloud-native Applications
27mArchitecting for Change Debate