The Problem DevOps Was Solving
In most organisations around 2013–2015, there was an invisible wall between two teams: Development and Operations.
Developers wrote code and threw it "over the wall" to ops. Ops deployed it, watched it break, and blamed the developers. Developers blamed ops for the broken environment. Releases happened quarterly — sometimes annually — because every deployment was a high-stakes, all-hands, nerve-wracking event.
The business wanted faster releases. Both teams wanted less stress. Nobody wanted to be on call at 2am fixing a botched deployment.
DevOps was the answer the industry came up with. But it was widely misunderstood.
What Companies Got Wrong
Most organisations heard "DevOps" and immediately asked: "Which tool do we buy?"
- Jenkins for CI/CD? ✓
- Docker for containers? ✓
- Ansible for configuration management? ✓
They bought the tools. They renamed their ops team "DevOps team." They declared success.
And then nothing changed. The wall between dev and ops remained. Releases were still painful. Incidents still triggered blame games.
The tools were never the point. The point was culture — shared ownership, shared responsibility, and shared on-call rotations. You can't buy that from a vendor.
What the Real Shift Looked Like
Organisations that got DevOps right did a few things differently:
1. Developers went on call. When the person who writes the code is also responsible for it running at 3am, code quality improves dramatically.
2. Infrastructure became code. Terraform, CloudFormation, Pulumi — the idea that infrastructure should be versioned, reviewed, and deployed just like application code was radical in 2015. It's table stakes today.
3. Deployments became boring. The goal of a good DevOps practice is to make releases so routine, so automated, so thoroughly tested, that nobody notices them. A hundred deployments a day. Zero drama.
4. Feedback loops shrank. From code commit to production in minutes, not months. Which meant faster learning, faster fixing, faster shipping.
The Career Explosion
By 2017–2019, "DevOps Engineer" had become one of the most in-demand — and best-compensated — roles in the industry. The combination of skills required was unusual: Linux, cloud, scripting, CI/CD, monitoring, containers, and the soft skills to bridge two historically siloed teams.
Tools like Kubernetes took container orchestration to a new level. Prometheus and Grafana became the standard observability stack. GitOps — managing everything through Git — became the operating model for mature teams.
What DevOps Left Behind
Not everyone adapted. Operations engineers who had built careers on manually managing servers found their roles changing faster than they could upskill. The demand for "click-and-configure" ops work declined sharply.
But those who embraced automation, who learned to code even a little, who understood that ops was now a software engineering problem — they found themselves in extraordinary demand.
The wall between dev and ops didn't disappear. But the best teams learned to build doors in it.