Originally published in Linux Journal. The following is an edited and expanded version of a conversation between Linux Journal Deputy Editor Bryan Lunduke and several DevOps practitioners. Their individual responses have been synthesised into a single composite voice—referred to as “Ted”—to make the dialogue easier to follow.
Why DevOps Is So Hard to Define
Few terms in the software industry generate as much nodding agreement and genuine confusion as DevOps. Ask ten practitioners to define it and you will get ten different answers, all of which are technically correct and collectively incomplete. The Wikipedia definition—widely quoted—doesn’t help much:
DevOps is a set of software development practices that combine software development (Dev) and information technology operations (Ops) to shorten the systems development life cycle while delivering features, fixes, and updates frequently in close alignment with business objectives.
That definition is accurate. It is also almost entirely useless if you are trying to understand what DevOps looks like day-to-day. To get a more grounded explanation, veteran software developer and Linux Journal Deputy Editor Bryan Lunduke put the question directly to four practitioners with real-world DevOps experience. What follows is a condensed, edited version of those conversations.
A Brief Note on the Author’s Background
Context matters when evaluating a definition, so it is worth knowing where Lunduke is coming from. His career in software spans roles across the full engineering hierarchy:
- Software Test Engineer – finds bugs before software ships and reports them to developers.
- Automation Engineer – writes code that automates the testing process.
- Software Development Engineer in Test (SDET) – builds tools that testers use.
- Software Development Engineer – writes production code.
- Dev Lead – manages a small group of engineers while still writing code.
- Dev Manager – manages engineers with less hands-on coding.
- Director of Engineering – manages engineering managers.
- Vice President of Technology/Engineering – accountable for technical strategy and delivery timelines.
Along the way he also managed SysOps engineers, System Administrators and Project Managers. In short, he has touched every part of the software delivery pipeline that DevOps is supposed to integrate. Which makes his confusion all the more illuminating.
The Conversation: Asking “Ted” to Explain DevOps Without Buzzwords
Lunduke posed a simple challenge to his practitioner contacts: “Explain to me what DevOps means. Bonus points for not using any buzzwords.” Their combined answer is represented below by the composite expert “Ted”.
The Core Idea
Lunduke: Okay, Ted. What actually is DevOps?
Ted: At its simplest: take the developers and the operations people—the sysadmins, the infrastructure team—and integrate them together. That is the core idea.
Lunduke: When you say “operations”, you don’t mean the Chief Operating Officer and supply-chain management?
Ted: No—System Operations. SysAdmin work. The people who keep servers running, manage deployments, configure networks and handle the IT infrastructure a software product depends on. Add QA and testers into that group as well. Everyone involved in the software delivery lifecycle working together, rather than in isolated silos.
How DevOps Differs from Agile
Lunduke: That sounds exactly like Agile.
For reference, the Wikipedia definition of Agile Software Development is:
Agile software development is an approach to software development under which requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and their customer(s)/end user(s). It advocates adaptive planning, evolutionary development, early delivery, and continual improvement, and it encourages rapid and flexible response to change.
Ted: There are real similarities, but the focus is different. Agile is primarily about improving collaboration between engineering teams, project managers and customers. DevOps is specifically about integrating the engineering team with the people who own the IT infrastructure—sysadmins, platform engineers, cloud operations staff. The overlap exists, but so does a meaningful distinction in emphasis.
Lunduke: So is DevOps just “sysadmins and engineers should talk to each other”? That idea is older than the personal computer.
Ted: That really is the foundational idea, yes. What DevOps adds on top is a body of best practices—tools, workflows, cultural norms and automated pipelines—that make that collaboration work reliably at scale. Sometimes the integration goes so far that Dev and Ops roles merge completely, with engineers owning both code and the infrastructure it runs on.
DevOps vs. Waterfall
Ted: One concrete best practice is releasing small, incremental changes frequently rather than large, infrequent releases. This is in direct contrast to the Waterfall model:
The waterfall model is a breakdown of project activities into linear sequential phases, where each phase depends on the deliverables of the previous one and corresponds to a specialisation of tasks. Progress flows in largely one direction through the phases of conception, initiation, analysis, design, construction, testing, deployment and maintenance.
In a Waterfall process, a team might work for months before anything reaches production. A DevOps-oriented team aims to deploy continuously—sometimes multiple times per day—keeping each individual change small and therefore less risky.
Key DevOps Concepts Defined
Several terms came up repeatedly in the conversations. Here is what they mean in plain language:
Continuous Integration (CI)
Developers merge their code changes into a shared repository frequently—often multiple times a day. Automated builds and tests run immediately after each merge to catch integration problems early, before they compound.
Continuous Delivery / Continuous Deployment (CD)
Every change that passes automated tests is automatically prepared for release (Continuous Delivery) or automatically released to production (Continuous Deployment). The distinction matters: Continuous Delivery still involves a human approval step; Continuous Deployment does not.
Agile Sprint
A sprint is the basic unit of work in the Scrum framework, commonly associated with Agile development. Sprints are time-boxed—typically one to four weeks—during which the team commits to delivering a defined set of features or fixes. DevOps teams often operate at cadences much shorter than a traditional sprint, releasing to production continuously rather than at sprint boundaries.
Infrastructure as Code (IaC)
Server configuration, network rules and deployment environments are defined in version-controlled code files rather than configured manually. This makes infrastructure reproducible, auditable and testable—treating servers the same way developers treat application source code.
So What Is DevOps, Really?
After all the conversation, a practical working definition emerges:
DevOps is a cultural and technical movement that breaks down the wall between software development and IT operations teams. It is supported by automation tools and shared practices—continuous integration, continuous delivery, infrastructure as code, automated testing—that together allow organisations to ship software faster, more reliably and with less manual overhead.
The core idea is genuinely old. Small shops and solo developers have always worn both the developer and sysadmin hat. What DevOps contributes is a shared vocabulary, a set of proven practices and a growing ecosystem of tooling—pipelines, container orchestration, configuration management, observability platforms—that make the integration of Dev and Ops tractable at enterprise scale.
DevOps and Linux
The DevOps toolchain has strong roots in the Linux ecosystem. Container runtimes, CI/CD servers, configuration management tools, scripting environments and cloud infrastructure APIs are predominantly Linux-native or Linux-first. The majority of production workloads running under a DevOps model run on Linux servers. That is not a coincidence: the open-source culture that produced Linux also produced much of the tooling—Git, Docker, Kubernetes, Ansible, Terraform, Jenkins, Prometheus—that makes modern DevOps practice possible.
The Honest Takeaway
DevOps resists a single clean definition because it is simultaneously a philosophy, a set of practices and a job title—and different organisations emphasise different aspects. If you encounter the term and feel confused, you are in good company. The useful question is not “what is DevOps?” in the abstract, but rather: what specific practices is this team or tool trying to enable? Focus on those concrete answers and the buzzword becomes much less mysterious.
Original reporting by Bryan Lunduke for Linux Journal.