Toward continuous resilience
summary
Practical steps for making systems recover faster: use ML code review (Amazon reports applying it to 30,000 apps in 2017–2018 and seeing 325% CPU efficiency and 39% lower cost), adopt immutable servers and canary deploys, set timeouts/retry-with-jitter and bounded queues, shard services into cells, and add observability (AWS Distro for OpenTelemetry, ServiceLens) plus ML anomaly detection (DevOps Guru). Also use automated chaos testing—AWS Fault Injection Simulator—to validate recovery plans and reduce time to repair.
AI-written summary · about
chapters (25)
- 0:00Intro
- 1:35The cost of downtime
- 5:06Maximize robustness
- 7:53Four essential capabilities in a resilient system
- 9:34Code review and profilers at Prime Day 2018
- 11:08Code review and profiling with Amazon CodeGuru
- 11:54Resilient application patterns
- 13:59Timeouts, retries, and backoff with jitter
- 14:19Simple designs and constant work
- 16:52Reliability, constant work, and a good cup of coffee
- 17:14Limiting impact of failures with cells
- 18:06Typical service application
- 19:28In-place server update
- 20:31Immutable deployments
- 21:28Safe deployment with canaries
- 23:24Monitoring more than failures
- 24:14Monitor the health of your applications
- 24:55AWS observability tools
- 27:14Event-driven patterns
- 28:14Security considerations
- 29:48Correction of errors (COE)
- 30:16Anatomy of a COE
- 31:04Chaos engineering
- 32:24AWS Fault Injection Simulator
- 33:06Additional resources
related talks
22mResilience Is Not Enough
17mContinuous resilience: Managing your application risks
16mResilient by Design: Architectures for Crisis Response & Recovery
10mDesigning for Failure using AWS: Resilient Systems
16mEngineering Failure-Resilient Systems
26mA proactive approach to resilience in modern apps
52mPerformance & Stability Anti patterns
45m⚡A Resilient Application in a Partially Degraded World ⚡