Skip to content

DevOps Patterns Distilled - Velocity London 2012

talks 2 min read

This was a joint presentation with Gene Kim, Damon Edwards, and John Willis at Velocity London. We set out to distill the DevOps patterns we’d been seeing across organizations into something teachable. The framework that emerged centered on the Three Ways: systems thinking (optimizing the whole value stream, not just local efficiencies), amplifying feedback loops (shortening and strengthening signals from production back to development), and continuous experimentation and learning (creating a culture that encourages risk-taking and learning from failure).

We mapped these principles onto four concrete areas of practice. First, extending the development flow into operations – deployment pipelines, infrastructure as code, automated provisioning. Second, extending feedback from operations back into development – monitoring visible to developers, shared on-call, production metrics in sprint reviews. Third, embedding development practices into operations – version control for configs, testing for infrastructure, code review for scripts. Fourth, embedding operations concerns into development – non-functional requirements as first-class citizens, capacity planning during design, operability as a feature.

The anti-patterns section hit close to home for many in the audience. “Configuration management equals DevOps” was the most common trap – teams adopting Chef or Puppet and declaring victory without changing how people worked together. The “lonely DevOps” anti-pattern described the poor soul hired as the single DevOps engineer expected to bridge an entire organizational divide. And the “separate DevOps group” pattern, where companies created yet another silo to solve a silo problem, drew knowing laughs.

Gene presented research suggesting the value stream inefficiencies in IT represented roughly three trillion dollars in lost value across the economy. That number got executives’ attention in a way that cultural arguments never could. The business case for DevOps wasn’t about making engineers happier – though it did that too – it was about removing the waste that accumulated when development and operations optimized in isolation.

Watch on YouTube โ€” available on the jedi4ever channel

This summary was generated using AI based on the auto-generated transcript.

Navigate with