This article is based on a commentary originally written by Eric Knorr and published on InfoWorld. The analysis draws on ideas from The DevOps Handbook by Gene Kim, Jez Humble, Patrick Debois, and John Willis, as well as an interview with Armon Dadgar, co-founder of HashiCorp.
What DevOps Actually Means
If you are still uncertain about what DevOps means in practice, The DevOps Handbook by Gene Kim, Jez Humble, Patrick Debois, and John Willis is one of the most thorough resources available. It is a practical, case-study-driven book aimed at helping engineering organizations dramatically improve their delivery throughput, reliability, and team culture.
Notably, the book is not structured around continuous delivery alone. Only one section covers what the authors call “the technical practices of flow” — the pipeline from development to operations. The remaining sections address feedback loops from application monitoring, building a culture of continual learning and experimentation, and integrating security and compliance into the delivery process from the start.
This scope is intentional and revealing. As the authors argue, DevOps is transformational to technology work in the same way that Lean manufacturing transformed factory floors in the 1980s. It is not purely a technology initiative — it is an organizational one. In this framing, DevOps becomes the operating model that underpins broader digital transformation efforts.
DevOps in Practice: The Seven Essential Elements
Most engineers want concrete details, not philosophy. Armon Dadgar, co-founder of HashiCorp, breaks DevOps down into seven core elements that must be addressed in any mature delivery workflow:
- Build — Compile and assemble application artifacts from source code.
- Test — Validate correctness, performance, and security through automated test suites.
- Package — Bundle artifacts into deployable units such as container images or binaries.
- Provision — Create and configure the infrastructure and environments where software will run.
- Secure — Harden environments, manage secrets, and enforce access controls.
- Deploy — Release packaged software to target environments in a controlled manner.
- Monitor — Observe running systems to detect issues and gather feedback for future iterations.
You might notice these same steps exist in a traditional waterfall process. The difference, according to Dadgar, is in execution: “The goal of DevOps is to parallelize as much of this as possible. These seven steps are necessary and sufficient, but they don’t have to be done sequentially.”
In a well-functioning DevOps organization, responsibilities are decoupled rather than handed off sequentially. Operations teams handle provisioning and deployment. Security engineers lock down runtime environments. Developers build, test, and package applications — and critically, they remain responsible for those applications in production. This last point is a key DevOps principle: developers should not simply throw code over the wall for operations to manage.
Why Infrastructure Provisioning Has Become the Hard Problem
Dadgar identifies provisioning as one of the most significant pain points driving DevOps adoption today. In earlier, simpler infrastructure landscapes — where everything ran on bare metal or a single vSphere cluster — provisioning was relatively straightforward: open a UI, click through a wizard, done.
Modern infrastructure is fundamentally different. A typical production environment might span multiple cloud providers, SaaS platforms, PaaS services, and on-premises hardware simultaneously. Dadgar describes the challenge this way:
How do you provision and manage that complexity, especially as these things interact with each other? It’s not that my web server is totally divorced from my cache and my database and my frontend load balancer. They’re all tightly related in a complex way. As you get more and more outsourced, it’s like, great, I’m going to run my web server and I’m going to use Amazon’s database and I’m going to use DynDNS and CloudFlare in front of that. Now I’m managing lifecycle across resources of totally different vendors.
The answer to this complexity is not more Jira tickets — it is code. Dadgar’s principle is to “disintermediate all of our work with software.” Tools like HashiCorp’s Terraform express infrastructure as declarative configuration that can be versioned, reviewed, and applied automatically, regardless of which cloud or vendor is involved. Critically, such tools are designed to integrate with existing toolchains rather than replace them wholesale.
DevOps Is More Process Than Tools
Despite co-founding a company that sells DevOps tooling, Dadgar is clear-eyed about where the real challenge lies: “DevOps is more process than it is tools. I think that’s what gets missed in the way it’s represented. There’s a fixation on tools because tools are easy. It’s hard to change organizational process.”
This observation aligns directly with The DevOps Handbook‘s emphasis on culture and learning. Tools can automate a deployment pipeline in weeks. Changing the way teams communicate, share responsibility, and respond to failure takes far longer and requires sustained leadership commitment.
A Realistic View: What DevOps Can and Cannot Guarantee
Any sufficiently popular IT trend eventually attracts criticism, and DevOps is no exception. Critics have argued that it places an unrealistic burden on developers, raises naive expectations about developers and operations teams suddenly collaborating harmoniously, and glosses over real organizational constraints.
There is truth in some of those critiques. DevOps is ultimately more philosophy than prescriptive methodology. Its success depends on organizational culture and the specific people involved at least as much as it depends on tooling or documented processes. The DevOps Handbook is candid about this reality:
We have a dirty secret to reveal. In many of our case studies, following the achievement of the breakthrough results presented, many of the change agents were promoted — but, in some cases, there was a later change in leadership which resulted in many of the people involved leaving, accompanied by a rollback of the organizational changes they had created.
This is the fundamental fragility of culture-dependent change. DevOps transformations that are tied to individual champions rather than embedded in organizational systems can — and do — reverse when those champions move on. Lasting change requires leadership that reinforces DevOps principles continuously, not just during an initial rollout.
The Scale of the Opportunity
Gene Kim, one of the authors of The DevOps Handbook, has observed that even with significant industry interest, the proportion of software engineers and operations professionals actively applying DevOps principles remains small. The implication is that the majority of organizations are still leaving substantial productivity gains, reliability improvements, and competitive advantage on the table.
Whether framed in terms of dollars, developer hours, or system reliability, the gap between current practice and the potential of well-implemented DevOps is large. The barrier is rarely technical — it is organizational will, sustained leadership, and a genuine tolerance for the disruption that meaningful process change requires.
Key Takeaways
- DevOps is not just CI/CD. Continuous delivery is one component. Monitoring, feedback loops, security integration, and cultural practices are equally important.
- Parallelism, not sequence. The seven core DevOps elements — build, test, package, provision, secure, deploy, monitor — gain their power when decoupled and parallelized, not run as a linear waterfall.
- Provisioning complexity is a real driver. The explosion of hybrid and multi-cloud infrastructure has made automated, code-driven provisioning a practical necessity, not a luxury.
- Tools are the easy part. Organizational culture, shared responsibility, and sustained leadership commitment are what determine whether a DevOps initiative succeeds long-term.
- Gains can be reversed. Without embedding DevOps principles into organizational DNA, improvements tied to individual change agents are vulnerable to regression when leadership changes.
Further reading: The DevOps Handbook by Gene Kim, Jez Humble, Patrick Debois, and John Willis is the primary source referenced throughout this article.