What DevOps is and the problem it solves

The wall between two teams

For many years, companies split software work into two teams. Developers (Dev) wrote new features. Operations (Ops) ran the servers and kept the website or app alive. Developers were rewarded for change: more features, faster. Operations were rewarded for stability: no outages. Change and stability pulled in opposite directions, so the two teams often did not trust each other.

The result was a "wall of confusion". Developers finished code and threw it over the wall: "it works on my machine, now you deploy it". Operations received a big bundle of changes, a long manual install document and a weekend deadline. When something broke, each side blamed the other.

Why big, rare releases are risky

When releases are slow, changes pile up. A quarterly release may contain 300 changes. If it fails, nobody knows which of the 300 broke it, so fixing it takes days. Because releases are painful, teams release even less often, so the next one is even bigger and riskier. It is a vicious circle.

DevOps breaks the circle by making releases small, frequent and automated. A release with 3 changes is easy to test, easy to understand and easy to undo. This sounds backwards at first, but it is the core insight: releasing more often makes each release safer.

A working definition

DevOps is a culture and a set of practices that bring development and operations together, supported by automation, so that teams can deliver software changes to users quickly, safely and repeatedly. The word was popularised around 2009, when Patrick Debois organised the first DevOpsDays conference in Ghent, Belgium.

• Culture: shared goals, shared responsibility for production, and no blame when things fail.
• Practices: version control, continuous integration, automated testing, continuous delivery, infrastructure as code, monitoring.
• Tools: Git, Jenkins, GitHub Actions, Docker, Kubernetes, Terraform, Prometheus and many more. Tools support the practices; they are not the goal.

CALMS: five things to look for

CALMS is a quick health check. If a team scores well on Automation but badly on Culture, it will still have blame and slow approvals. The weakest letter is usually the place to start.

The infinity loop

DevOps is often drawn as an infinity sign (a figure of eight lying on its side). The left half is the development side and the right half is the operations side. Work flows around it and never stops: plan, code, build, test, release, deploy, operate, monitor, and then back to plan. What you learn while monitoring feeds the next plan.

plan -> code -> build -> test -> release -> deploy -> operate -> monitor
  ^                                                                |
  +----------------------------------------------------------------+

The Three Ways

The book The DevOps Handbook describes three principles, called the Three Ways:

1. Flow: make work move smoothly from idea to production. Small batches, fewer handovers, automated steps.
2. Feedback: find problems fast. Automated tests, monitoring and alerts tell you within minutes, not weeks.
3. Continual learning: experiment, learn from failures without blame, and keep improving the system.