Part 0 · Foundations — Why DevOps Exists

There is a gap at the centre of every software company. On one side, someone writes code. On the other side, that code runs on real machines, serving real users, holding real money and real data. The gap between those two sides — how does a change in someone’s editor become a feature in production without breaking everything — is the entire subject of this book.

That gap used to be crossed by hand. A developer would finish a feature and hand it off. Someone else would copy files onto a server, edit a config, restart a process, and hope. When it broke at 2 a.m., a third person got paged and tried to figure out what had changed. Every step was manual, every step was a place to make a mistake, and every mistake landed in production where users felt it.

DevOps is the discipline of removing those manual, error-prone steps — replacing “someone remembers to do it” with “a machine does it the same way every time.” That is the whole game.

The one question to keep asking

Throughout this book, every tool and practice gets held up to a single test:

The recurring thread

What manual, error-prone step does this remove — and how does it make production safer?

This is not a throwaway slogan. It is the lens that tells you why a thing exists. A container, a pipeline, an alert, a Terraform file — each one is an answer to that question. If you can name the manual step it kills and the failure it prevents, you understand it. If you can’t, you’re just memorising commands.

Notice that the thread has two halves, and they pull in the same direction. Removing the manual step makes you faster (you don’t wait for a human to do it). Doing it the same way every time makes you safer (the human doesn’t fumble it). DevOps’ central, almost unintuitive claim is that speed and safety are not enemies — automation buys you both at once. We’ll prove that with data in Speed vs Stability.

What “Dev” and “Ops” even mean

Two halves of the same job, historically done by two different teams:

   DEV (Development)              OPS (Operations)
   writes the change             runs the change in production
   wants: ship features          wants: keep the system up
   measured by: velocity         measured by: stability

Set up like this, the two sides want opposite things. Dev is rewarded for change; Ops is rewarded for the absence of change. That conflict — and the wall it built between the teams — is where our story starts. We unpack it in The Wall Between Dev and Ops.

The word “DevOps” is the two halves jammed together on purpose. It says: these are not two jobs in tension, they are one responsibility — getting a change safely into production and keeping it healthy there — and the people who build a thing should share in running it.

Why a whole “Part 0” before any tools

It would be faster to jump straight to Docker. We’re not going to, for the same reason you learn why before how everywhere in engineering: tools change, principles don’t. Kubernetes will be replaced one day. The reason it exists — keep the running system matching the desired state, automatically — is permanent. If you learn the principle first, every tool becomes “oh, that’s how this one solves the problem I already understand.” If you learn the tool first, you collect commands you can’t reason about.

So Part 0 has no kubectl, no YAML to apply, nothing to install. It builds the mental model that makes the rest of the book click. Five ideas, in dependency order — each one uses only what came before.

Roadmap: the five ideas

   why-devops ──> feedback-loops ──> dora-metrics ──> calms ──> speed-vs-stability
   (the wall)     (shorten the      (measure         (it's    (the payoff:
                   loop)             speed+safety)    culture)  both, not either)

Page	The idea	The question it answers
The Wall Between Dev and Ops	The historical dev-vs-ops silo and why it failed	Why did we need DevOps in the first place?
Feedback Loops & Why Speed Matters	Shorten the loop from change to feedback; small batches beat big ones	Why is fast actually safe?
The Four Key Metrics (DORA)	Four numbers that capture speed and stability	How do we know if we’re any good?
CALMS: DevOps Is Culture First	Culture, Automation, Lean, Measurement, Sharing	What is DevOps, if not a tool or a title?
Speed vs Stability: The False Tradeoff	The data showing you don’t trade one for the other	Why does any of this work?

By the end, you’ll have a frame for everything that follows: Linux, networking, containers, orchestration, CI/CD, infrastructure as code, observability, security, and the cloud. Each of those later parts is, at heart, one more set of manual steps being automated away to make production safer. Part 0 is where that sentence starts to mean something.

Note

This is a first-principles book. Read the parts in order — each builds on the last — and after every page, answer the Check your understanding questions in your own words before moving on. If you can’t explain it simply, you haven’t got it yet. Depth over speed.

Check your understanding

1. In one sentence, what “gap” is DevOps fundamentally about closing?
2. State the recurring thread of this book. Why does it have two halves, and why do they point the same way?
3. Historically, what did “Dev” want and what did “Ops” want? Why does that setup create conflict?
4. Why does this book spend a whole “Part 0” on principles before introducing a single tool?
5. Pick any tool you’ve already heard of (Docker, GitHub Actions, Terraform). Take a guess: what manual step might it remove, and what failure might that prevent? You’ll check your guess later.

Show answers

1. The gap between writing code and running it safely in production — turning a change in someone’s editor into a live feature without breaking everything.
2. The thread is “what manual, error-prone step does this remove — and how does it make production safer?” It has two halves because removing a manual step makes you faster (no waiting on a human) and doing it the same way every time makes you safer (no human fumble) — the same automation buys both, so they point the same way.
3. Dev wanted to ship features (rewarded for velocity/change); Ops wanted to keep the system up (rewarded for stability/the absence of change). They conflict because, looking at the same deploy, Dev sees progress and Ops sees risk — change is the job for one and the threat for the other.
4. Because tools change, principles don’t. Kubernetes will be replaced one day, but the reason it exists — keep the running system matching desired state, automatically — is permanent. Learn the principle first and every tool becomes “oh, that’s how this one solves a problem I already understand.”
5. Open-ended — e.g. Docker removes “configure each server’s environment by hand,” preventing the “works on my machine, breaks in prod” failure; Terraform removes “click through a cloud console to provision servers,” preventing drift and unrepeatable infra. The point is to name a manual step and a failure, then check it as you read.