Looking Back to Look Forward - Deprecating Simplicity - Building a New Test Culture
You need to be signed in to add a collection
**12:10pm - 12:30pm** **ADRIAN HORNSBY: Looking back to look forward** Chaos engineering has emerged as the best method for uncovering hidden issues, monitoring blind spots, and performance bottlenecks that can be challenging to find in modern, distributed systems. Chaos engineering has come a long way recently and is no longer just for people with deep expertise. In this talk, I will share lessons learned from years of helping customers with chaos engineering and show you how they have influenced the development of the new chaos engineering service AWS Fault Injection Simulator. **12:30pm - 12:50pm** **CASEY ROSENTHAL: Deprecating Simplicity - Building a New Test Culture** When engineering teams take on a new project, they often optimize for performance, availability, or fault tolerance. More experienced teams can optimize for these properties simultaneously. Now add an additional property: feature velocity. Organizations often try to optimize for feature velocity through process improvements and engineering hierarchy, but some optimize for feature velocity through explicit architectural decisions. These decisions increase the complexity of the system. This sounds like a trade-off: you get feature velocity, but for the price of increased complexity. Mental models of architecture can help us understand the tension between these engineering properties. For example, understanding the distinction between accidental complexity and essential complexity can help you decide whether to invest engineering effort into simplifying your stack or expanding the surface area of functional output. Spoiler alert: most businesses prioritize feature velocity over simplification. Chaos Engineering was born within this conflict between feature velocity and increasing complexity. Rather than simplify, Chaos Engineering provides a mechanism for us to embrace the complexity and ride it like a familiar wave, maintaining our business priorities while dialing up feature velocity.
Transcript
12:10pm - 12:30pm
ADRIAN HORNSBY: Looking back to look forward
Chaos engineering has emerged as the best method for uncovering hidden issues, monitoring blind spots, and performance bottlenecks that can be challenging to find in modern, distributed systems. Chaos engineering has come a long way recently and is no longer just for people with deep expertise. In this talk, I will share lessons learned from years of helping customers with chaos engineering and show you how they have influenced the development of the new chaos engineering service AWS Fault Injection Simulator.
12:30pm - 12:50pm
CASEY ROSENTHAL: Deprecating Simplicity - Building a New Test Culture
When engineering teams take on a new project, they often optimize for performance, availability, or fault tolerance. More experienced teams can optimize for these properties simultaneously. Now add an additional property: feature velocity. Organizations often try to optimize for feature velocity through process improvements and engineering hierarchy, but some optimize for feature velocity through explicit architectural decisions. These decisions increase the complexity of the system. This sounds like a trade-off: you get feature velocity, but for the price of increased complexity.
Mental models of architecture can help us understand the tension between these engineering properties. For example, understanding the distinction between accidental complexity and essential complexity can help you decide whether to invest engineering effort into simplifying your stack or expanding the surface area of functional output. Spoiler alert: most businesses prioritize feature velocity over simplification.
Chaos Engineering was born within this conflict between feature velocity and increasing complexity. Rather than simplify, Chaos Engineering provides a mechanism for us to embrace the complexity and ride it like a familiar wave, maintaining our business priorities while dialing up feature velocity.