Chaos Engineering: Why Breaking Things Should be Practiced
summary
Shows automated chaos with AWS Fault Injection Simulator by terminating one EC2 instance in an Auto Scaling group and triggering an Aurora RDS failover. The Auto Scaling group launches a replacement instance and the load balancer keeps the site serving traffic; the RDS reader is promoted to writer in under a minute. Uses templates, CloudWatch logging and IAM-scoped roles; experiments run against two AZs and complete with logs and timestamps for postmortem.
AI-written summary · about
chapters (15)
- 0:00Start
- 0:58Can you guess what will happen?
- 1:59Dystributed Systems are hard
- 2:39Even simple applications are complex
- 3:48Traditional testing is enough?
- 4:36Chaos engineering is not new
- 7:40Chaos engineering A scientific method
- 12:03Why is chaos engineering difficult?
- 14:57Chaos in practice... How to?
- 16:45Tools for chaos engineering
- 17:42AWS Fault Injection Simulator
- 20:21Our architecture for this DEMO
- 22:37Component failure experiments
- 39:22Component failure: Amazon EC2
- 39:53Resources
related talks
35mImprove resilience with automated chaos engineering
33mImprove resilience with automated chaos engineering
57mChaos Engineering Primer
20mResilient and well-architected apps with chaos
29mImprove Resilience with automated chaos engineering
34mChaos engineering for serverless
26mImprove application resilience with chaos engineering
34mChaos in the cloud