All Clouds Need a Sprinkle of Chaos
summary
Cloud-native systems break in specific ways and chaos engineering uses controlled experiments to reveal them. The talk shows concrete experiments and tooling: run a cpu spike on 50% of nodes (60% CPU for 300s via Gremlin API or curl) to validate monitoring, inject 500ms latency into Redis to test dependency fallbacks, or perform a shutdown 50–70% of hosts attack to exercise cross-region failover. It also outlines CI/CD automation, game days and fire drills, abort conditions, blast radius sizing and iterative retesting until resilience is proven.
AI-written summary · about
chapters (11)
- 0:00Introduction
- 0:52The Challenge
- 4:58Chaos Engineering
- 8:51Chaos Engineering Steps
- 16:06Game Days
- 16:59Fire Drill
- 18:16Learning from Failure
- 19:25Running Experiments
- 20:06Stickers
- 20:30Chaos Community
- 21:01Outro
related talks
23mChaos Engineering for Cloud Native
57mChaos Engineering Primer
39mResilience & Chaos Engineering in the Cloud
45mDeveloping a Chaos Architecture Mindset
23mHow to tame chaos effectively?
18mChaos Engineering: Break It On Purpose
46mDesigning a System for Chaos
39mChaos: Breaking your Systems to Make them Unbreakable