Build Systems that Drive Business
Sep 30–Oct 1, 2018: Training
Oct 1–3, 2018: Tutorials & Conference
New York, NY

Deprecating simplicity

Casey Rosenthal (Verica.io)
4:45pm–5:25pm Wednesday, October 3, 2018
Systems Engineering and Architecture
 Location: Murray Hill Level: Intermediate

Prerequisite knowledge

  • A basic understanding of distributed systems and what the deployment story of an app might look like in the cloud
  • Familiarity with continuous integration, continuous delivery, and DevOps

What you'll learn

  • Learn how to use chaos engineering to embrace complexity and navigate it rather than reject complexity and try to erase it

Description

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, distinguishing 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 out of this conflict between feature velocity and increasing complexity. Casey Rosenthal explains why, 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.

Topics include:

  • Why we need complex systems.
  • Two real-world examples of complex systems wherein despite great software engineering, the overall system found itself in a bad state
  • The bullwhip effect in systems thinking as it pertains to software operations
  • The engineering property prioritization model (performance versus availability versus fault tolerance versus feature velocity) as it pertains to software engineering goals
  • The economic pillars of the complexity model (state, relationships, environment, and irreversibility) as they pertain to software architectural goals
  • How chaos engineering was born from necessity in a complex distributed system
  • Rasmussen’s boundaries (economics, workload, safety) as a justification for the necessity of chaos engineering
  • The current pinnacle of chaos engineering: An automation platform running in production at the largest scale
  • How to get started and where to go to learn more
Photo of Casey Rosenthal

Casey Rosenthal

Verica.io

Casey Rosenthal is cofounder and CEO at Verica.io. Previously, he was CTO at Backplane and an executive manager and senior architect, where he managed teams tackling big data, architected solutions to difficult problems, and trained others to do the same. He seeks opportunities to leverage his experience with distributed systems, artificial intelligence, translating novel algorithms and academia into working models, and selling a vision of the possible to clients and colleagues alike. For fun, Casey models human behavior using personality profiles in Ruby, Erlang, Elixir, Prolog, and Scala.