What is DevOps?
DevOps is not a job title, a tool, or a reorg — it is a set of practices for closing the gap between the people who write software and the people who keep it running. This page traces where the term came from, names the structural conflict it was invented to solve, and introduces CALMS, the five-part framework this entire course is organized around. By the end you should be able to explain DevOps precisely enough to correct someone who is using it wrong.
Picture two relay teams that never practice together. The first runner sprints hard and is graded purely on speed, so instead of handing off the baton she lobs it over a hedge into the next lane. The second runner is graded only on never dropping a baton, so he keeps yelling at her to throw more carefully and less often. Nobody ever lets both runners train on the same track with the same stopwatch. DevOps is redesigning the race so there is one team, one handoff zone, and one finish-line clock both runners are trying to beat together.
Origins: from Agile silos to "10 deploys a day"
The 2001 Agile Manifesto fixed how software got written — iterative cycles, cross-functional teams, tight feedback from customers — but it stopped at the release boundary. A sprint could ship working code every two weeks, and that code would still land in Operations' lap as a discrete, high-ceremony event: a change ticket, a deployment window, a person who did not write the code being asked to run it. Agile made Dev faster without touching how software actually reached production, and the gap between the two widened.
The turning point most historians point to is a single conference talk. In June 2009, Flickr engineers John Allspaw and Paul Hammond presented "10+ Deploys Per Day: Dev and Ops Cooperation at Flickr" at the O'Reilly Velocity conference, showing that shared tooling, shared metrics, and mutual respect between Dev and Ops made ten-plus daily production deploys routine rather than reckless. Patrick Debois, who could not attend, was struck enough by the idea that a few months later he organized DevOpsDays in Ghent, Belgium (30–31 October 2009) and coined "DevOps" as a contraction of the event's name. See the DevOps lifecycle for how those practices chain together end to end.
The wall of confusion
The conflict Allspaw and Hammond named has a structural root: Dev and Ops are typically rewarded for opposite things. Developers are measured and promoted on shipped features and release velocity. Operations teams are measured and promoted on uptime, mean time to recovery, and change-failure rate — metrics that go down when releases go up. Give two teams opposing incentives and no shared accountability, and you get exactly what you'd predict: Dev finishes a build, files a ticket, and moves on; Ops, unfamiliar with the change and holding all the blast radius if it breaks, treats every release as a threat and adds friction — change advisory boards, freeze windows, manual sign-off gates. The community named this pattern the wall of confusion: work gets thrown over it in one direction, and risk gets thrown back in the other.
Amazon's engineering culture summarized the fix in four words: "you build it, you run it." The team that writes a service also deploys it, monitors it, and carries the pager for it — so release risk and operational risk are borne by the same people, at the same time, which is what actually aligns the incentives that caused the wall in the first place.
CALMS: the framework this course keeps coming back to
Patrick Debois and Andrew Clay Shafer's early community discussions were distilled into an acronym — CAMS: Culture, Automation, Measurement, Sharing — which consultants Jez Humble and Damon Edwards extended to CALMS around 2010 by adding Lean. It is the closest thing DevOps has to a formal definition, and this course uses it as a throughline:
- Culture — shared ownership and blameless postmortems instead of blame-seeking after an incident; see culture & collaboration.
- Automation — replacing manual, error-prone handoffs with pipelines and code, covered starting with CI/CD pipelines and infrastructure as code.
- Lean — small batch sizes and limited work-in-progress, borrowed directly from the Toyota Production System, so a failed change is small and cheap to diagnose instead of large and catastrophic.
- Measurement — instrumenting the pipeline and the system in production so decisions are made on data, not opinion; see measuring success: the DORA metrics.
- Sharing — knowledge, tooling, and incident learnings crossing team boundaries by default rather than staying locked in one group's head.
None of the five works alone. Automation without Culture just makes a dysfunctional handoff faster; Measurement without Sharing produces dashboards nobody outside one team ever looks at. Every later page in this course maps back to one or more of these five letters.
Three myths worth killing before you go further
Because "DevOps" spread faster than its definition did, three misreadings show up constantly in real organizations. It is worth debunking each explicitly, because each one leads to a specific, predictable failure.
Myth 1: DevOps is a job title. Posting a req for a "DevOps Engineer" and hiring one person, or worse, standing up a "DevOps team" that sits between Dev and Ops, does not dissolve the wall — it builds a third silo directly on top of it, now with its own backlog and its own handoff queue. CALMS describes how every engineer works, not a role one engineer is hired to perform on everyone else's behalf.
Myth 2: DevOps is just tools. Jenkins, GitHub Actions, and Terraform are real and useful — see the DevOps toolchain — but they are one implementation of one CALMS pillar, Automation. Buying a fast pipeline without changing incentives, batch size, or blameless-postmortem culture just gets you fast, broken deploys instead of slow, broken ones.
Myth 3: DevOps means "NoOps." Managed cloud and serverless platforms remove undifferentiated toil, not operational responsibility. Someone still owns monitoring and observability and incident response when a managed service degrades at 2 a.m. — that work moves onto Dev's plate or onto a platform team's, it does not vanish.
The most common real-world failure mode is Myth 1 in disguise: a well-meaning reorg creates a "Platform" or "DevOps" team, and within a year every other team routes deploys and infrastructure requests through it — recreating the exact ticket-and-wait handoff DevOps was invented to remove, just with a friendlier team name on the door.
Why the distinction matters from here
Every later page in this course assumes the definition established here: DevOps as a set of cross-functional practices held together by shared incentives, not a role, a product, or the absence of operations work. That framing changes how you should read what follows — culture & collaboration goes deeper on the "Culture" pillar and the specific mechanics of blameless postmortems, and the DevOps lifecycle walks the full plan-through-operate loop shown in the diagram above, stage by stage. Keep CALMS in mind as you go — nearly every tool and practice covered later earns its place in this course because it serves one of those five letters, and naming which one is usually the fastest way to tell a genuine DevOps improvement from a rebrand.
1. What incentive misalignment between Dev and Ops produced the "wall of confusion," and what is the "you build it, you run it" fix? 2. Name the five letters of CALMS and what each one means. 3. Pick one of the three myths debunked on this page and explain, in your own words, why it's wrong. 4. Which 2009 conference talk is most often cited as DevOps' founding moment, who gave it, and who coined the term "DevOps" itself a few months later?
Check your answers
- Dev is rewarded for shipping change; Ops is rewarded for avoiding change-caused incidents — opposite incentives with no shared accountability. "You build it, you run it" fixes this by making the same team own both the code and the pager for it, so release risk and operational risk land on the same people.
- Culture (shared ownership, blameless postmortems), Automation (pipelines and code instead of manual handoffs), Lean (small batch sizes, limited work-in-progress), Measurement (instrumenting the pipeline and production), Sharing (knowledge and tooling crossing team boundaries).
- Any of: a job title just creates a third silo instead of removing the first two; tools alone only cover the Automation pillar and can't fix incentives or culture; NoOps doesn't eliminate operational work, it relocates it onto Dev or a platform team.
- John Allspaw and Paul Hammond's "10+ Deploys Per Day: Dev and Ops Cooperation at Flickr" at O'Reilly Velocity, June 2009. Patrick Debois coined "DevOps" a few months later at DevOpsDays Ghent, October 2009.