Cloudy With a Chance Of Chaos: Verifying the Resiliency Of Cloud-Native Applications
summary
A case study verifies resilience of a cloud-native service running on ECS Fargate by stopping tasks via AWS CLI, observing a 20% error rate for 3–10 minutes as the network load balancer keeps routing to dead tasks until health checks remove them. Tests use managed-service techniques — API-driven cluster resizes, malicious heavy queries against Elasticsearch, Redis soft-dependency failures, OPA entitlement outages, and synthetic load via a load tester — and find the need to decouple monitoring from service.
AI-written summary · about
chapters (11)
- 0:00Chaos engineering intro
- 4:17Success criteria for chaos tests
- 8:51Chaos-ready teams and envs
- 12:41Why chaos is easy and hard
- 15:06Goldman Sachs chaos case
- 22:53Chaos engineering takeaways
- 23:42Q&A: Serverless & data chaos
- 26:31Q&A: Load testing & sims
- 28:15Q&A: Post-test analysis & teams
- 30:57Q&A: Prod chaos approvals
- 32:23Q&A: Tools & automation
related talks
05mCloud-Native Reliability Strategies: Practices Ensuring Uptime
39mResilience & Chaos Engineering in the Cloud
22mAll Clouds Need a Sprinkle of Chaos
53mResiliency and Availability Design Patterns for the Cloud
34mChaos in the cloud
20mResilient and well-architected apps with chaos
33mBeyond the Monkeys Chaos Engineering on the Cloud
39mPracticing Cloud-Native Resliency Is a Challenge: Decoding It with Chaos...