This article is based on commentary originally published on computerweekly.com and expanded for a DevOps engineering audience.
The DevOps Honeymoon May Be Over
DevOps has dominated the software delivery conversation for the better part of a decade. By bridging the traditional gap between Development and Operations — encompassing sysadmins, DBAs, configuration specialists, testers, and other operational staff — it promised faster releases, greater reliability, and reduced friction across the software lifecycle. But as with any methodology that reaches mainstream adoption, the cracks are starting to show.
The question worth asking is not whether DevOps delivers value in theory, but whether the way it is being implemented in practice is sustainable — and whether the industry may be approaching a period of pushback.
DevOps Origins: A Tool-Driven Movement
The term “DevOps” is widely attributed to discussions that began around 2008, notably in the context of Agile conferences and early practitioner communities. Importantly, however, the movement did not emerge purely from a grassroots desire among developers to collaborate more closely with operations teams. In large part, it was driven by a tooling industry that recognised an addressable gap between the Dev and Ops functions — and set about filling it with a growing ecosystem of platforms, pipelines, and integrations.
This distinction matters. When a methodology is defined as much by commercial tooling as by cultural change, it becomes vulnerable to the same market forces that created it: commoditisation, tool sprawl, and eventual disillusionment.
Backlash Clouds Form: The Toolchain Problem
One of the most frequently cited frustrations among practitioners is the sheer number of tools required to operate a modern DevOps pipeline. To deliver on the Continuous Integration and Continuous Delivery (CI/CD) promise, a development team typically needs to maintain proficiency across:
- Core development environments and language-specific toolchains
- Version control systems (e.g., Git)
- CI/CD pipeline tools (e.g., Jenkins, GitHub Actions, GitLab CI)
- Containerisation and orchestration platforms (e.g., Docker, Kubernetes)
- Infrastructure-as-Code tools (e.g., Terraform, Ansible)
- Monitoring and observability stacks (e.g., Prometheus, Grafana, Datadog)
- Secrets management, artifact repositories, and more
Each context switch between tools adds cognitive overhead. Developers who signed up to build software increasingly find themselves configuring pipelines, debugging infrastructure, and learning operational concepts that were historically outside their remit. What practitioners often want is a more integrated, unified toolset — one that covers the full development lifecycle without requiring frequent tool changes at each stage.
The irony is stark: a methodology designed to reduce friction between teams has introduced significant friction within those teams through toolchain complexity.
Failed Digital Transformation Projects Add Pressure
DevOps became closely associated with the wave of “digital transformation” initiatives that dominated enterprise IT strategies through the mid-2010s. As those projects mature — or fail — the methodologies associated with them inevitably come under scrutiny.
Not every digital transformation project can succeed. Ambitious programmes with poorly defined outcomes, inadequate cultural change, or insufficient investment in skills will fail regardless of the tooling in place. When they do, DevOps risks becoming a convenient scapegoat — with critics arguing that even well-intentioned automation and collaboration practices could not rescue a fundamentally flawed programme.
This is less a failure of DevOps as a discipline and more a failure of how it has been sold and adopted — often as a silver bullet rather than a sustained cultural and operational shift. But perception matters, and failed projects leave lasting impressions.
The Rise of Full-Stack Engineering
A parallel trend is also worth considering. The growing prevalence of full-stack engineers — developers who are genuinely comfortable operating across front end, back end, and increasingly infrastructure layers — may reduce the need for a distinct DevOps function in some organisations.
If a developer can own the deployment pipeline, configure cloud infrastructure, and manage observability tooling without specialist intervention, the traditional justification for a dedicated DevOps team becomes less clear-cut. This does not eliminate DevOps thinking; it arguably embeds it. But it does challenge the idea of DevOps as a separate organisational layer or discipline.
DevOps Before DevOps: A Historical Footnote
It is worth remembering that the problems DevOps addresses are not new. The challenge of software being “thrown over the wall” from development to operations predates the term by decades. Enterprise tooling vendors — including IBM with its Rational suite — were tackling integration across the software lifecycle well before 2008. What changed was not the problem, but the industry’s willingness to address it at scale using open-source tooling, cloud infrastructure, and Agile-influenced culture.
That context is useful. DevOps did not invent the problem, and a backlash against the term does not mean the underlying challenges disappear. The need for fast, reliable, collaborative software delivery remains — regardless of what we call the practices that support it.
What Comes Next?
The pressures outlined above do not necessarily signal the death of DevOps. More likely, they signal a maturation. Methodologies that survive the backlash phase tend to do so by shedding hype, refining their core principles, and becoming embedded in standard practice rather than marketed as transformative programmes.
For DevOps, that may mean:
- Platform engineering emerging as a discipline that abstracts toolchain complexity away from developers, providing internal developer platforms (IDPs) that reduce cognitive load
- SRE (Site Reliability Engineering) continuing to grow as a more defined operational role within organisations that need rigorous reliability practices
- GitOps and declarative infrastructure reducing the operational burden on development teams by making infrastructure state version-controlled and auditable
- A broader acceptance that DevOps is a cultural mindset, not a job title or a tool purchase
The honeymoon period for DevOps as a buzzword may well be over. But the underlying need to deliver software faster, more reliably, and with less organisational friction is permanent. The practitioners who focus on that goal — rather than on any particular label — are the ones most likely to thrive.