What DevOps Actually Is

Ask five people what DevOps means and you'll get five answers: "it's Docker and Kubernetes," "it's a job title," "it's a team that manages our pipelines," "it's Agile for infrastructure." All of these are symptoms of DevOps. None of them are the thing itself. Before we go anywhere else, we need to fix that, because if the target concept is fuzzy, everything you learn afterward will be fuzzy too.

Here is the actual definition we'll build on for the rest of this course: DevOps is the elimination of the organizational wall between the people who write software and the people who run it in production, so that the feedback from running it reaches the people who wrote it fast enough to act on it.

That's it. Everything else — CI/CD pipelines, containers, infrastructure as code, on-call rotations, blameless postmortems — is a *technique* people invented to make that removal of the wall practical at scale. The techniques are not the point. The point is the wall, and why it was such a problem in the first place.

The wall, and why it existed

For decades, most software organizations split into two departments with opposite incentives. Development was measured on shipping features — new code, on time, to spec. Operations was measured on stability — uptime, no incidents, nothing breaking at 3 AM. Those two goals are in direct tension: the fastest way to break production is to ship new code, and the safest way to guarantee uptime is to ship nothing at all.

Put two teams with opposite incentives next to each other and you get exactly what you'd expect: Dev throws a build "over the wall" to Ops, Ops is the one who gets paged when it breaks, and neither team feels responsible for the whole outcome. Dev didn't feel the pain of running their code badly, so they had no reason to write code that was easy to run. Ops didn't understand the code they were running, so they had no way to fix it properly when it broke — they could only restart it, roll it back, or escalate and wait.

This isn't a hypothetical problem. It's the default outcome of organizing people by specialty instead of by outcome, and it shows up in every organization that hasn't deliberately fought against it — we'll see exactly why in the module on Conway's Law.

Where the name came from

The term "DevOps" traces to a specific moment: a talk called "10+ Deploys Per Day: Dev and Ops Cooperation at Flickr," given by John Allspaw and Paul Hammond at the Velocity conference in June 2009. At the time, most organizations treated frequent deployment as reckless — the assumption was that fewer, bigger releases were safer because they gave Ops more time to prepare and test. Allspaw and Hammond showed the opposite: Flickr shipped to production more than ten times a day, and it was *more* stable than organizations that shipped quarterly, because each individual change was small, well-understood, and easy to reverse if something went wrong.

That talk didn't hand anyone a tool or a process. It handed the industry a mindset: frequent, small, low-drama changes — made possible by developers and operations people working as one group with shared tools and shared responsibility — beat rare, big, high-drama changes. A grassroots movement calling itself "DevOps" grew out of that idea over the following years.

What DevOps is not

• It is not a job title. "DevOps Engineer" usually means someone who runs CI/CD pipelines and cloud infrastructure — a real and useful job, but hiring one person and calling it done is the opposite of the idea (more on this in the Anti-Patterns module).
• It is not a specific tool or tool category. Docker, Kubernetes, Jenkins, Terraform — all popular in DevOps-practicing organizations, none of them required, none of them sufficient on their own.
• It is not "Ops renamed." It's not about turning developers into sysadmins or automating operations staff out of a job. It's about both groups sharing ownership of the outcome.
• It is not a department you can put on an org chart, at least not without recreating the exact silo problem it was invented to solve.

What DevOps is, restated

DevOps is a mindset and a set of cultural practices built on one premise: software is not "done" when it's written, it's done when it's running correctly for real users, and the people best positioned to make it run correctly are the people who understand how it was built. So give them the access, the responsibility, and the tools to do that — and make sure the feedback from production flows back to them quickly, instead of disappearing into a different department's ticket queue.

Throughout this course, every module is really an answer to the same question from a different angle: given that premise, what does it change about how a team thinks, organizes, and reacts to failure? By the end, tool names will make sense as *implementations* of ideas you already understand — not the other way around.