This article is based on a discussion originally published by Federal News Radio, featuring Nathen Harvey (Vice President of Community Development, Chef Software), Brent Wodicka (Principal Solutions Architect, AIS), and David Bock (Principal Consultant – DevOps Services Lead, Excella Consulting).
Why DevOps Is Hard to Define
Few terms in the technology industry carry as much ambiguity as “DevOps.” Depending on who you ask, it describes a culture, a set of practices, a toolchain, or an organizational structure. Because the concept spans team boundaries, job roles, and technology stacks, practitioners often arrive at genuinely different — and equally valid — interpretations.
To cut through the noise, it helps to hear from people who apply DevOps principles daily across different organizations and technology ecosystems. The three perspectives below illustrate how DevOps looks from the angles of open-source tooling, enterprise Microsoft environments, and public-sector consulting.
The Problem DevOps Solves
To understand why DevOps emerged, consider the traditional IT workflow it replaced. In a conventional enterprise environment:
- Developers wrote code in isolation, optimizing for feature delivery.
- Operations staff managed physical infrastructure in data centers, optimizing for stability and uptime.
- Handoffs between teams were slow, manual, and contentious — developers needed test environments, operations teams had backlogs and risk-aversion, and neither group had full visibility into the other’s constraints.
The result was a familiar standoff: developers begging for environments, operations staff raising objections, and software releases taking weeks or months. Both sides were acting rationally given their incentives — but the organizational structure itself was the bottleneck.
Cloud infrastructure changed the equation. When physical servers are replaced by virtual machines and managed services, the mechanical skills that once defined operations work become less central. Coordination, automation, and shared ownership become more valuable. That shift created the conditions in which DevOps practices could take hold.
Perspective 1: Continuous Delivery Through Infrastructure as Code (Nathen Harvey, Chef Software)
Nathen Harvey’s perspective centers on how tooling can close the gap between development and operations. Chef, the configuration management platform, allows teams to codify infrastructure — treating server configuration the same way developers treat application code: version-controlled, tested, and deployed automatically.
In a DevOps environment using a tool like Chef, the workflow might look like this:
- Infrastructure is defined in code (“recipes” and “cookbooks” in Chef’s terminology).
- Changes to infrastructure go through the same pull-request and review process as application code.
- Automated tests verify that infrastructure behaves as expected before changes reach production.
- Continuous delivery pipelines deploy both application code and infrastructure changes together, reducing drift between environments.
This approach removes the manual handoff between developers and operations. Instead of submitting a ticket and waiting, a developer can propose an infrastructure change, have it reviewed by an operations engineer, and see it deployed automatically — all within a single workflow.
Perspective 2: DevOps in the Microsoft Ecosystem (Brent Wodicka, AIS)
Brent Wodicka’s perspective addresses how DevOps principles apply within Microsoft-centric environments — a relevant question for the large portion of enterprises running .NET applications, Azure infrastructure, and Windows Server.
Microsoft’s own transformation is instructive. The company shifted from a culture associated with closed, proprietary software to becoming — at the time of the original discussion — one of the largest contributors to open-source projects on GitHub. This change was not purely cosmetic: it reflected internal adoption of practices such as continuous integration, automated testing, and cross-functional team structures that DevOps advocates have long promoted.
For organizations running Microsoft stacks, this matters practically. Tools like Azure DevOps (formerly Visual Studio Team Services), GitHub Actions, and Azure Pipelines provide integrated CI/CD capabilities designed for teams that may not have a background in Linux-native tooling. DevOps is not the exclusive domain of open-source or cloud-native shops — the principles translate across technology ecosystems.
Perspective 3: DevOps in the Federal and Public Sector (David Bock, Excella Consulting)
David Bock’s perspective addresses one of the more challenging contexts for DevOps adoption: government and public-sector IT. Federal agencies face compliance requirements, procurement constraints, and organizational inertia that can make agile and DevOps transformations significantly harder than in commercial settings.
Excella Consulting’s approach to this challenge included community education — hosting free events for federal information professionals to build awareness and practical knowledge of DevOps practices. This reflects a broader truth about DevOps adoption: technology is rarely the primary obstacle. Culture, shared vocabulary, and organizational buy-in are typically the harder problems to solve.
Key principles that resonate in public-sector DevOps contexts include:
- Starting with shared understanding: Teams that don’t share a common definition of DevOps cannot effectively collaborate on implementing it.
- Incremental adoption: Full transformation is rarely achievable immediately; identifying a single pipeline or team as a pilot is a common starting point.
- Compliance as code: Security and audit requirements can be encoded into automated pipelines, making compliance continuous rather than a gate at the end of a release cycle.
What These Perspectives Have in Common
Despite their different contexts, Harvey, Wodicka, and Bock converge on several shared themes:
- DevOps is primarily cultural, not technical. Tools enable DevOps practices, but they do not create them. Organizational structure and incentives must change first.
- Automation is the mechanism, not the goal. Automating a broken process produces a broken process faster. Understanding the workflow comes before automating it.
- Collaboration across silos is non-negotiable. Whether the silo is dev vs. ops, IT vs. security, or agency vs. contractor, DevOps requires people to work across traditional boundaries.
- Continuous delivery is the outcome. The ability to release small, tested changes frequently — rather than large, risky releases infrequently — is what DevOps makes possible.
Takeaways for DevOps Practitioners
If your organization is early in its DevOps journey, the diversity of perspectives here is actually useful: it means there is no single prescribed path. Your starting point depends on your current constraints.
- If infrastructure provisioning is your bottleneck, explore infrastructure-as-code tools such as Chef, Ansible, Terraform, or Puppet.
- If you operate in a Microsoft environment, Azure DevOps and GitHub Actions provide a native on-ramp to CI/CD without requiring a full toolchain replacement.
- If culture and organizational resistance are your primary challenges, invest in education, community-building, and demonstrating value through a focused pilot before attempting a broad rollout.
DevOps is not a product you purchase or a certification you earn. It is an ongoing practice of improving how software is built, tested, and delivered — one that looks different in every organization that takes it seriously.