DevOps is a cultural movement that proposed developers and operations engineers should work together instead of throwing artifacts over a wall at each other, which was such an obviously good idea that the industry immediately responded by creating a new silo called “the DevOps team” and throwing artifacts over two walls instead of one.
The term was coined by Patrick Debois in 2009, inspired by a talk at Velocity Conference about Flickr deploying ten times a day. The original insight was simple: the people who write the code and the people who run the code should be the same people, or at least should talk to each other, or at the absolute minimum should not actively sabotage each other’s work through competing ticket queues.
This insight lasted approximately eighteen months before it was captured, domesticated, and sold back to enterprises as a toolchain.
“Gene Kim’s DevOps handbook was gathering dust on six different shelves.”
— The Unicorn Project
The Three Ways (That Became Three Hundred Tools)
The DevOps movement was built on three principles, articulated in The Phoenix Project and its sequel The Unicorn Project:
- Flow — work should move from development to operations to the customer without waiting in queues
- Feedback — information should flow back from production to development quickly
- Continuous Learning — the organization should experiment, learn, and improve
These are cultural principles. They require no specific technology. They could be implemented with shell scripts, sticky notes, and a willingness to let developers ssh into production.
Instead, the industry implemented them with: Jenkins, GitLab CI, GitHub Actions, CircleCI, Travis CI, Bamboo, TeamCity, Docker, Kubernetes, Terraform, Ansible, Chef, Puppet, Salt, Prometheus, Grafana, Datadog, New Relic, PagerDuty, OpsGenie, Splunk, ELK Stack, Helm, ArgoCD, Flux, Istio, Linkerd, Consul, Vault, and approximately three hundred other tools, each solving one piece of a problem that did not exist before the previous tool was adopted.
The Job Title Problem
The most reliable indicator that a revolution has failed is when it becomes a job title.
“DevOps Engineer” appeared on LinkedIn approximately two years after devopsdays Ghent. The job description typically requires expertise in Docker, Kubernetes, Terraform, and CI/CD pipelines, but notably does not require the ability to write application code or understand the business logic of the systems being deployed.
This is precisely the silo that DevOps was created to eliminate — an operations team that manages infrastructure without understanding applications — except now it is called “DevOps” and the salary is 40% higher.
The next evolution was inevitable: the DevOps team was renamed “Platform Engineering,” the responsibilities remained identical, and a new conference circuit was born.
The Solo Developer Exception
There exists one context in which DevOps is practiced perfectly, consistently, and without any tooling debate: the Solo Developer.
The solo developer writes the code. The solo developer deploys the code. The solo developer monitors the code. The solo developer is woken at 3 AM when the code fails. There is no wall to throw artifacts over because there is no wall. There is no ticket queue because there is no queue. There are no competing priorities because there is one person and that person has already decided.
The solo developer practices DevOps the way Monsieur Jourdain spoke prose — without knowing it, without naming it, and without attending a conference about it.
“No Docker. No container orchestration. No Kubernetes. One binary. Copy it. Run it. Done.”
— riclib, The Databases We Didn’t Build
The YAML Ceiling
Every DevOps transformation eventually hits what practitioners call the YAML Ceiling — the point at which the configuration required to deploy the application exceeds the complexity of the application itself.
A Go binary that serves HTTP on port 8080 requires: a Dockerfile (12 lines), a Kubernetes deployment manifest (47 lines), a service manifest (18 lines), an ingress manifest (23 lines), a Helm chart (94 lines across 6 files), a Terraform configuration (67 lines), a CI/CD pipeline definition (128 lines), and a monitoring configuration (43 lines).
Total lines of YAML and configuration: 432.
Total lines of application code: 200.
The deployment infrastructure is 2.16 times larger than the thing being deployed. This ratio only increases with time, because configuration accretes and nobody deletes YAML.
Measured Characteristics
- Original principles: 3 (flow, feedback, learning)
- Tools created to implement them: ~300
- Job titles created: DevOps Engineer, SRE, Platform Engineer, Infrastructure Engineer, Cloud Engineer, Release Engineer
- Walls removed between dev and ops: 0 (renamed, not removed)
- Conferences per year: 47+
- Ratio of YAML to application code (typical): 2:1
- Solo developers practicing perfect DevOps: all of them
- Solo developers who call it DevOps: none of them
