DevOps emerged in the late 2000s as a response to a fundamental dysfunction in software delivery: development teams wrote code fast, operations teams prioritised stability, and the two rarely collaborated. The result was slow, painful releases, frequent outages, and mutual blame. DevOps is the culture, movement, and set of practices designed to fix that.
The Core Idea
DevOps unifies Dev (development, QA, product) and Ops (infrastructure, networking, security) around a shared goal: deliver value to users reliably and frequently. It is not a team you create or a tool you buy — it is an organisational approach that changes how people work together.
A useful working definition: DevOps is the practice of operations and development engineers working together throughout the entire service lifecycle, from design through development to production support.
The CALMS Framework
CALMS (popularised by Damon Edwards and John Willis) provides a structured model for assessing and building DevOps culture:
| Pillar | Meaning |
|---|---|
| C — Culture | Shared ownership, psychological safety, blameless postmortems, empathy between Dev and Ops |
| A — Automation | Automate repetitive manual work: builds, tests, deployments, provisioning, compliance checks |
| L — Lean | Eliminate waste, reduce batch sizes, limit work in progress, visualise flow |
| M — Measurement | Instrument everything, make performance visible, use data to drive decisions |
| S — Sharing | Shared tools, shared knowledge, open communication across teams and time zones |
The Three Ways
Gene Kim (co-author of The Phoenix Project and The DevOps Handbook) describes DevOps through "The Three Ways":
- Flow: Optimise the flow of work from Dev to Ops to the customer. Limit work in progress, reduce handoffs, make work visible.
- Feedback: Amplify feedback loops so problems are detected and fixed quickly. Fast automated tests, monitoring, and alerts.
- Continual Experimentation and Learning: Build a culture of experimentation, resilience through failure, and organisational learning.
DORA Metrics
The DevOps Research and Assessment (DORA) program identifies four key metrics that distinguish elite-performing software organisations:
| Metric | What It Measures | Elite Benchmark |
|---|---|---|
| Deployment Frequency | How often code is deployed to production | Multiple times per day |
| Lead Time for Changes | Time from code commit to production deployment | Less than 1 hour |
| Change Failure Rate | % of deployments that cause a production failure | 0–15% |
| Mean Time to Restore (MTTR) | How fast you recover from a production failure | Less than 1 hour |
DORA research consistently shows that high deployment frequency and low lead time do not come at the cost of stability. Elite teams deploy more often and have fewer failures — because automation and fast feedback loops make change safer.
DevOps vs Agile vs SRE
- Agile is a software development methodology focused on iterative delivery and responding to change.
- DevOps extends Agile principles to include operations, infrastructure, and the full delivery pipeline.
- SRE (Site Reliability Engineering) is a specific implementation of DevOps principles originated at Google — it applies software engineering to operations problems. We cover SRE in depth in the final module.