This article is based on an original piece published at cloudcomputing-news.net and reflects the state of DevOps adoption as of late 2019.
A Decade of DevOps
2019 marked ten years since the term “DevOps” was first coined—popularised during a now-legendary presentation at a Toronto tech conference. What started as a small, grassroots conversation among frustrated infrastructure and development professionals has grown into one of the most discussed—and most misunderstood—movements in IT history.
In those early days, the people pushing for closer collaboration between Dev and Ops teams were a minority operating largely outside mainstream enterprise thinking. A decade later, the idea is everywhere. Unfortunately, “everywhere” includes a lot of vendor marketing that has little to do with the original intent.
The Problem with the Hype Cycle
Like containerisation, microservices, and agile before it, DevOps attracted the full weight of the IT vendor marketing machine. Vendors plastered “DevOps” across landing pages and slapped the label on products that offered little more than a new UI for existing tooling. The result: a noisy market full of “DevOps-in-a-box” promises that missed the fundamental point.
The core truth about DevOps has not changed: it cannot be purchased and installed. Real DevOps is a cultural and organisational shift—one that requires changes to how teams communicate, how work is structured, and how success is measured. Tools support that shift; they do not create it.
SolarWinds’ 2018 IT Trends Report reinforced this. When IT professionals were asked to name the top barriers to optimal IT performance, they cited inadequate infrastructure and poor organisational strategy—not a lack of tools. That finding points directly at culture and process, not product gaps.
Why Hype Cycles Are Actually Useful
There is a silver lining to hype cycles: they end. When vendors and commentators shift their attention to the next buzzword, the underlying technology or practice is often left in a healthier state—adopted where it genuinely fits, iterated on by practitioners rather than positioned by marketers.
Virtualisation followed the same arc. Vendors pushed it aggressively before the tooling was mature enough, and many early enterprise deployments were painful. Experienced data centre engineers pushed back, waited for the technology to stabilise, and adopted it on their own terms. Today, virtualisation is unremarkable infrastructure—standard practice that no one debates. DevOps is following the same trajectory.
The Reality of DevOps Adoption at Year Ten
By 2019, DevOps adoption had moved well past early adopters. The annual DORA (DevOps Research and Assessment) State of DevOps report—published in collaboration with Google Cloud—found that the proportion of organisations self-classifying as “elite DevOps performers” had nearly tripled compared to prior years, reaching approximately 20% of surveyed organisations. These teams reported significantly shorter lead times, higher deployment frequencies, and faster recovery times from incidents.
Alongside that, a 2018 Cloud Native Computing Foundation survey of roughly 2,400 developers and IT professionals found that serverless technology adoption had grown 22% in a single year. Cloud-native and serverless environments have been fertile ground for DevOps practices because they reward automation, fast feedback loops, and cross-functional ownership—all pillars of the DevOps approach.
What Mature DevOps Actually Looks Like
For organisations still finding their footing, it is worth being clear about what DevOps adoption looks like in practice—rather than in vendor slide decks.
- Automated deployment pipelines: Code moves from commit to production through an automated pipeline that includes testing, security scanning, and environment provisioning. Manual handoffs between teams are eliminated or minimised.
- Shared ownership of reliability: Developers are involved in on-call rotations or at minimum have visibility into production metrics. Operations engineers contribute to architectural decisions. Both teams share accountability for the outcome.
- Incremental delivery: Features ship in small, verifiable increments rather than large, infrequent releases. This reduces risk and accelerates feedback.
- Infrastructure as Code (IaC): Infrastructure is defined, versioned, and deployed using code—the same discipline applied to application software. Tools like Terraform, Ansible, and Pulumi support this.
- Measurement and learning: Teams define meaningful metrics (deployment frequency, change failure rate, mean time to recovery) and use them to improve, not just report upward.
The growing adoption of tools like Git, Jenkins, and Gradle reflects engineering teams voting with their workflows. These tools succeed because they reduce friction in the collaboration and delivery process—not because a vendor mandated them.
The Human Side: Adjustments That Are Actually Hard
DevOps asks something uncomfortable of experienced IT professionals: let go of manual control. Automation of deployment, configuration, and monitoring can feel like a threat to engineers who have built careers around hands-on expertise. That reaction is understandable.
In practice, however, engineers who have adopted DevOps automation consistently report that it expands rather than shrinks their career options. Automating repetitive operational tasks frees time for higher-value work—architecture decisions, reliability engineering, toolchain improvement. The overnight maintenance window becomes a relic. Deployment becomes a non-event rather than a coordinated, stressful production.
The friction between development and operations teams is also real, especially in early-stage DevOps transformations. These teams have historically optimised for different things—developers for speed of change, operations for stability. Bridging that gap takes time and visible management support. Teams should expect disagreement in the early months and not interpret it as failure.
What Vendors Should Actually Do
The call to vendors is straightforward: stop using “DevOps” as a marketing modifier and start building products that genuinely support DevOps workflows. That means:
- First-class API and CLI support so teams can integrate tools into pipelines without manual UI steps
- Compatibility with standard pipeline tools (Jenkins, GitHub Actions, GitLab CI, Tekton) rather than proprietary lock-in
- Configuration-as-code support so tool settings can be version-controlled and audited
- Observability integrations so product telemetry fits naturally into existing monitoring stacks
Elite DevOps teams identify strongly with their toolchain. Vendors that build genuinely DevOps-compatible products earn adoption on merit rather than marketing budget.
What Comes Next
As the hype recedes, DevOps will do what virtualisation did: become standard practice rather than a strategic initiative. Traditional operations teams that have resisted will find themselves adopting at least some DevOps practices simply because the tooling will assume it—cloud platforms, container orchestrators, and modern observability tools are all built with DevOps workflows as the default.
The more interesting question for the next decade is what DevOps evolves into as organisations deepen their adoption. Platform engineering—where internal developer platforms abstract away infrastructure complexity while preserving DevOps principles—is already emerging as the next iteration. The underlying goal remains unchanged: reduce the time between an idea and its value reaching users, while maintaining the reliability and security the business depends on.
DevOps was always a practitioner movement. The practitioners are still here, still iterating. The hype is fading. That is exactly how it should go.