The DevOps Revolution: Tearing Down the Wall Between Development and Operations

Two Tribes with Incompatible Goals

In the organizational structure of most technology companies through the 1990s and 2000s, software development and IT operations were separate departments with separate reporting chains, separate budgets, separate tools, and separate performance metrics.

The separation was logical on its surface. Development required creative work — building new things, experimenting with different approaches, accepting that some attempts would fail. Operations required disciplined work — maintaining running systems, preventing failures, ensuring that services stayed available. These seemed like different skills requiring different people with different temperaments.

What the organizational separation missed was that the goals of the two departments were structurally in conflict.

Development teams were measured on feature delivery — how many new capabilities they shipped, how quickly they responded to product requirements, how much new functionality users received. Shipping required change: new code, new dependencies, new database schemas, new configuration. Every deployment was an opportunity to deliver value — and also an opportunity to introduce a bug that would crash the production system at 2 AM.

Operations teams were measured on stability — uptime percentages, mean time between failures, mean time to recovery. Stability required the absence of change: a system that ran without modification yesterday would, absent hardware failures, run the same way today. Every deployment was a risk. From the operations perspective, the best deployment was no deployment.

These were not merely different priorities. They were mathematically opposed. Maximizing feature velocity and maximizing system stability, using the tools available in the 2000s, required making trade-offs that benefited one group at the expense of the other. Development wanted to deploy fast; operations wanted to deploy rarely. Development wanted to move quickly; operations wanted to move carefully. Development was punished for slow releases; operations was punished for outages caused by releases.

The standard resolution was a bureaucratic apparatus designed to manage the conflict: change review boards, deployment windows, rollback procedures, approval checklists. These slowed down development enough to give operations a chance to validate changes. They did not resolve the underlying tension — they just made the friction visible as process overhead.

Patrick Debois and the Accident of Origin

Patrick Debois was a Belgian IT consultant who had the unusual professional experience of having worked on both sides of the wall. He had been a developer. He had done operations. He had managed projects. In 2007, he was working on a large Belgian government data center migration project and was doing the work of both worlds simultaneously — developing systems and managing their deployment — and finding the experience maddening.

The technical issues were solvable. The organizational issues were not. Teams that should have been collaborating were structured as customers and vendors of each other’s work. The information that operations needed to safely deploy what development had built lived inside development’s heads and was never systematically transferred. The feedback that development needed to understand how their software behaved in production lived inside operations’ incident logs and was never systematically shared.

Debois began reading about Agile methodology — the movement that had similarly tried to close the gap between software developers and their business stakeholders. He saw the same problem in a different location: Agile had brought developers and product managers together, but had left the wall between developers and operators intact. The software delivered at the end of an Agile sprint still had to be thrown over that wall.

In 2008, at the O’Reilly Velocity web performance conference, Andrew Clay Shafer proposed a Birds of a Feather session titled “Agile Infrastructure.” The session was listed in the program. When Shafer arrived at the meeting room, Debois was the only person there. Nobody else in the Agile community had yet connected the dots between Agile development and infrastructure management.

Shafer almost left. Debois persuaded him to stay. They talked for an hour. The conversation would eventually have consequences neither could have anticipated.

Flickr’s Ten Deploys a Day (Velocity 2009)

The event that crystallized the DevOps movement into a movement was a forty-minute talk at O’Reilly Velocity 2009 in San Jose.

John Allspaw, Flickr’s VP of Technical Operations, and Paul Hammond, Flickr’s Director of Engineering, presented “10+ Deploys Per Day: Dev and Ops Cooperation at Flickr.” The title was the provocation. In 2009, deploying software to production ten times in a single day was not a normal operational posture. Most organizations deployed software in large batches, weeks or months apart, preceded by elaborate change freeze periods and rollback rehearsals. The idea that a production system could be safely modified ten times a day was, to much of the industry, a sign of recklessness rather than competence.

Allspaw and Hammond’s argument was that the conventional view had the causality backwards. Large, infrequent deployments were not safer than small, frequent ones. They were more dangerous. A deployment that bundled three months of changes was harder to test, harder to roll back, and harder to diagnose when something went wrong. The scope of potential failure was enormous. When the deployment succeeded, nobody learned anything. When it failed, debugging meant searching through months of changes for the one that caused the problem.

Small, frequent deployments inverted this risk profile. Each deployment contained a small, bounded change. If something went wrong, the scope of the problem was limited and the root cause was obvious: it was the thing just deployed. Rollback was straightforward because only one change needed to be reversed. Over time, the accumulated confidence of many successful small deployments built the organizational reflexes needed to handle the rare failure gracefully.

The prerequisite for frequent deployment, Allspaw and Hammond argued, was not recklessness about stability — it was deep investment in the automation and monitoring infrastructure that made frequent deployment safe. Automated testing that could verify a change’s effects in minutes. Deployment pipelines that could push code to production with a single command. Monitoring that could detect when a new deployment was behaving badly and trigger automatic rollback. Feature flags that could enable new features for a small percentage of users before exposing them to everyone.

The talk was recorded and posted online. Patrick Debois watched it. He had been building toward the same ideas from a different direction. The Flickr talk showed what the end state looked like. He now wanted to create a community that could figure out how to get there.

The First DevOpsDays (Ghent, October 2009)

Debois organized a conference.

He called it DevOpsDays, combining “development” and “operations” into a portmanteau that neither word’s practitioners would have thought to put together. The event was held in Ghent, Belgium, in October 2009. About seventy people attended — a mix of developers, system administrators, and operations engineers who had all been thinking about the same problem from different angles.

The conference format was a mix of prepared talks and open spaces — unstructured sessions where attendees proposed and facilitated their own discussions. The open space format turned out to be well-suited to a movement that was still discovering what it believed: participants were not there to receive expert instruction, they were there to pool experience and figure out what was actually working.

The Twitter hashtag for the event was #devops — too long for the character limits of the day, with “Days” dropped. The shortened hashtag, adopted by conference participants to discuss the event online, became the name of the movement. “DevOps” was not coined by a thought leader naming a framework. It was a Twitter hashtag truncated to fit a character limit.

Debois held DevOpsDays events in subsequent years, and others began organizing their own DevOpsDays conferences in different cities. By 2011, DevOpsDays events were running in the United States, Australia, and across Europe. The format — half talks, half open spaces, heavy emphasis on practitioner experience over vendor presentations — spread with the events.

The community that formed around DevOpsDays was different from the Agile community that had formed around the Manifesto eight years earlier. Agile had originated with a document that codified values; DevOps originated with conversations between practitioners sharing specific problems and specific solutions. There was no DevOps Manifesto. There was no founding document. The movement was defined by its community before it was defined by its principles.

The Phoenix Project (2013)

If DevOpsDays created a community, Gene Kim’s 2013 novel The Phoenix Project gave it a cultural artifact.

Kim, co-author of The Visible Ops Handbook and a veteran of IT management consulting, wrote The Phoenix Project with Kevin Behr and George Spafford as a business novel — a genre popularized by Eli Goldratt’s The Goal, which had used a fictional factory to illustrate the Theory of Constraints. Kim’s novel followed Bill Palmer, a newly appointed VP of IT Operations at a fictional manufacturing company called Parts Unlimited, as he tried to rescue a catastrophically late and over-budget IT project called Phoenix while preventing the systems he was responsible for from catching fire.

The novel’s narrative worked because it was recognizable. The Phoenix project — perpetually behind schedule, perpetually over budget, managed by a senior VP who bypassed IT governance processes, dependent on a single brilliant-but-impossible employee named Brent who was the only person who understood how any of the critical systems worked — was not a satire. It was a description. Readers who had worked in corporate IT recognized Parts Unlimited’s dysfunction with uncomfortable specificity.

Kim structured the novel’s argument around The Three Ways of DevOps:

The First Way was Systems Thinking — understanding the whole system of work from development through operations to the customer, rather than optimizing individual departments at the expense of the whole. The classic IT dysfunction was a development team that optimized its own performance (velocity of feature delivery) in a way that degraded the system’s performance (stability of delivered services). Systems thinking meant measuring what mattered to the business, which was the performance of the whole.

The Second Way was Amplify Feedback Loops — creating fast, visible feedback from operations back to development, so that problems encountered in production were rapidly communicated to the people who could fix them. In the siloed organization, feedback was slow: an operations incident was filed in a ticket system, triaged by an operations team, eventually escalated to development if the root cause was in the code, assigned to a developer who no longer remembered why they had made the decision that caused the problem, and resolved weeks after the fact. The DevOps approach built feedback mechanisms into the deployment pipeline: automated tests, monitoring alerts, and operational dashboards visible to both development and operations teams.

The Third Way was Culture of Continual Experimentation and Learning — treating failures as sources of information rather than events to be prevented at all costs. The conventional IT risk model treated failure as unacceptable, which led organizations to avoid the changes and experiments that could lead to failure, which led to the ossification that prevented improvement. The DevOps model treated failure as inevitable and built the reflexes (monitoring, rollback, incident review) to handle it cheaply, then used each failure as data about how to prevent the next one.

The Phoenix Project was not a technical manual. It was a conversion narrative — a story about a protagonist who understood the old way being shown the new way by a wise mentor figure. Its power was emotional rather than analytical: it gave DevOps practitioners a shared story and gave executives who hadn’t lived the dysfunction a way to recognize it in their own organizations.

Continuous Integration: The Technical Foundation

The organizational changes DevOps required were impossible without the right technical infrastructure. That infrastructure had been under development for a decade before the movement named it.

Continuous Integration (CI) was the practice of merging all developers’ working copies to a shared main branch frequently — multiple times per day — and automatically verifying each merge with an automated test suite. Martin Fowler and Kent Beck had formalized CI as an Extreme Programming practice in the late 1990s, arguing that the longer developers worked in isolation before merging, the more expensive integration became. The solution was to integrate constantly and make the cost of each integration small.

CI required three things: a version control system that could support frequent merges, an automated test suite comprehensive enough to verify that a merge hadn’t broken anything, and a build server that could run the tests automatically whenever a merge occurred.

The first widely adopted build server was CruiseControl, an open-source Java project released around 2001. It watched a version control repository and triggered an automated build whenever a change was committed. If the build or tests failed, it notified the team. CruiseControl was configurable but complex — setting it up required XML configuration and Java knowledge.

The dominant build server of the 2000s was Hudson, created by Kohsuke Kawaguchi at Sun Microsystems in 2004. Kawaguchi built Hudson because he was tired of discovering that his commits had broken the build hours after the fact. He wanted something that would tell him immediately. Hudson’s web interface was approachable enough that non-Java-experts could configure it, and its plugin architecture allowed the community to extend it for nearly any use case. By the late 2000s, Hudson was running in thousands of organizations worldwide.

When Oracle acquired Sun in 2010, the Hudson community forked the project over governance concerns, renaming the fork Jenkins. Jenkins became the most widely deployed CI server in history, with an ecosystem of over 1,500 plugins covering every conceivable build tool, version control system, notification mechanism, and deployment target.

CI as a service — removing the need to operate your own build server — arrived with Travis CI in 2011. Travis CI integrated directly with GitHub, automatically running tests for any pull request against any repository. For open-source projects, it was free. The friction of setting up CI dropped from “configure a server” to “add a YAML file.” Within a few years, a green build badge in a GitHub README was a standard signal of project health.

GitHub Actions, launched in 2018, completed the integration: CI was no longer a separate service integrated with version control, but a first-class feature of the version control platform itself. Workflows were defined in YAML files in the repository, triggered by repository events (push, pull request, release), and executed on GitHub’s infrastructure or developer-supplied runners. The entire CI/CD pipeline — build, test, lint, deploy — could be defined in the same repository as the code it processed.

Infrastructure as Code: Making Infrastructure Programmable

Parallel to the CI/CD evolution, a different set of tools was solving a related problem: the gap between the development environment and the production environment.

The traditional approach to server configuration was manual and tribal. Administrators logged into servers and made changes — installing packages, editing configuration files, tuning kernel parameters — that were documented nowhere except in the administrators’ memories. Two servers that were supposed to be identical were often subtly different because they had been configured by different people at different times. When a developer said “it works on my machine” and the operations engineer said “it doesn’t work in production,” the root cause was often not the code but the environment: different library versions, different configurations, different system tunings that were invisible to anyone who hadn’t physically touched the server.

Infrastructure as Code (IaC) was the principle that server configuration should be defined in code — text files that could be version-controlled, reviewed, tested, and applied automatically — rather than manually applied commands that left no trace. If infrastructure was code, it could be treated with the same rigor as application code: changes reviewed via pull request, tested in staging before production, rolled back if something went wrong.

Puppet, created by Luke Kanies in 2005, was the first widely adopted IaC tool. Puppet described server configuration in a declarative domain-specific language: instead of specifying the commands to run to achieve a configuration, you specified the desired state, and Puppet figured out what commands were needed to reach that state. A Puppet manifest might declare that the Apache package should be installed, that a particular configuration file should contain specific content, and that the Apache service should be running. Puppet would inspect the current state of the server, determine what changes were needed, and apply them.

Chef, founded by Adam Jacob in 2008, took a more procedural approach: instead of a declarative manifest, Chef used “recipes” written in Ruby that described the sequence of steps to configure a system. Chef appealed to developers comfortable with programming in a way that Puppet’s DSL did not.

Ansible, created by Michael DeHaan in 2012, simplified both. Ansible was agentless — unlike Puppet and Chef, which required a daemon running on every managed server, Ansible connected over SSH and applied configuration directly. Ansible playbooks were YAML files that were readable by humans who had never touched the tool. The low barrier to entry made Ansible the most widely adopted configuration management tool in environments that valued operational simplicity over the advanced features of Puppet and Chef.

Terraform, built by HashiCorp and first released by Mitchell Hashimoto in 2014, extended IaC beyond server configuration to infrastructure provisioning. Terraform could create cloud resources — virtual machines, databases, load balancers, DNS records, networking components — by declaring their desired state in HashiCorp Configuration Language (HCL). A Terraform configuration described the complete infrastructure of an application; applying it against a cloud provider’s API would create, modify, or destroy resources to match the declaration. For the first time, the infrastructure of an application could be version-controlled alongside the application’s code, reviewed alongside code changes, and reproduced identically in different environments.

IaC transformed the relationship between development and operations by making environments reproducible. A developer could now spin up a local environment that matched production exactly, not approximately. The “works on my machine” problem didn’t disappear, but it became easier to diagnose: if the local and production environments were both defined by the same IaC code, discrepancies were visible and traceable.

Site Reliability Engineering: The Google Model

While the DevOps community was building its movement from the ground up, Google was independently solving the same problem from the top down — and arrived at a model that complemented and eventually merged with DevOps thinking.

In 2003, Ben Treynor Sloss was a software engineer at Google tasked with running a production team. He later described the resulting approach with characteristic directness: “SRE is what happens when you ask a software engineer to design an operations function.”

The insight behind Site Reliability Engineering (SRE) was that the tension between development velocity and operational stability could be quantified and managed, rather than negotiated politically. The tool was the error budget.

An SRE team would work with a service’s stakeholders to define a Service Level Objective (SLO): a target for service reliability, expressed as a percentage of requests that should succeed, a latency threshold that should be met, or some combination. An SLO of 99.9% availability meant the service could be unavailable for about 43 minutes per month. The difference between 100% and the SLO — the permitted unreliability — was the error budget.

The error budget made the development-operations trade-off explicit and quantitative. If the error budget was healthy — the service was performing well within its SLO — development teams were free to deploy aggressively, accepting more risk in exchange for velocity. If the error budget was nearly exhausted — the service had used almost all of its permitted unreliability — development deployments stopped until the budget recovered. Reliability was not a fight between departments. It was an accounting problem with a shared ledger.

SRE teams at Google were software engineers first and operations engineers second. They wrote code to automate operational tasks, maintained a rule that manual operational work (called “toil”) should consume no more than 50% of an SRE’s time, and were empowered to push back against development teams whose services required excessive manual intervention to operate. If a service required too much toil to run, the SRE team could return it to the development team to fix until it was operable.

Google published the Site Reliability Engineering book in 2016, co-authored by a large team of Google engineers, making the internal SRE model available to the broader industry. The book was comprehensive and often dense — Google’s production environment was more complex than almost anything outside of a handful of large internet companies — but its principles were broadly applicable. The SRE model, adapted to smaller organizations with less Google-scale infrastructure, became one of the two dominant DevOps organizational patterns alongside the “you build it, you run it” model pioneered by Amazon, in which development teams owned the production operation of their own services.

Dead End: ITIL and the Change Advisory Board

The IT Infrastructure Library (ITIL) was not wrong. It was right for a world that no longer fully existed.

ITIL originated in the late 1980s as a set of best practices developed by the Central Computer and Telecommunications Agency (CCTA) of the United Kingdom government. Its goal was to bring discipline and consistency to IT service management across government departments that each operated their own IT functions with their own (often incompatible) approaches. ITIL described processes for service strategy, service design, service transition, service operation, and continual service improvement — a comprehensive framework for managing IT as a service-delivery function.

At the center of ITIL’s change management process was the Change Advisory Board (CAB): a committee of stakeholders — service owners, technical experts, business representatives — that reviewed proposed changes to IT systems, assessed their risk, approved or rejected them, and scheduled approved changes for implementation. The CAB met regularly, often weekly, and considered formal Requests for Change (RFCs) that documented the change, its purpose, its risk assessment, its implementation plan, its rollback plan, and its testing evidence.

For the IT landscape of the 1990s and early 2000s, this was appropriate. Systems were large, tightly integrated, and difficult to test comprehensively. A change to a core banking system or an ERP implementation carried real risk of cascading failures. The CAB’s deliberation slowed the change process, but the deliberation was genuinely useful: experienced operations engineers could identify failure modes that developers hadn’t considered, and the formal documentation requirements forced teams to think through their changes carefully before implementing them.

The problem was pace. ITIL’s CAB process was designed for an environment where software was deployed quarterly or annually. In the DevOps world — where Amazon was deploying to production once every 11.6 seconds as of 2011, where Netflix was running hundreds of deployment events per day — the CAB process was structurally incompatible with the deployment cadence. You cannot convene a weekly review committee for a deployment that happens every few minutes.

The deeper issue was that the CAB process was based on a premise that DevOps practices had invalidated: that individual deployments were risky enough to require human review of each one. If every deployment was a large, bundled change to a complex, manually configured system with no automated rollback capability, then yes — each deployment was a significant event requiring careful human judgment. But if each deployment was a small, bounded change to an automatically tested, automatically deployed, continuously monitored system with one-click rollback, the risk profile was entirely different. The appropriate review was automated testing, not committee deliberation.

ITIL organizations attempting to adopt DevOps practices ran into this contradiction directly. DevOps teams deploying dozens of times per day could not submit a formal RFC for each deployment. The CAB’s weekly meeting schedule created a deployment bottleneck that immediately negated the velocity gains of CI/CD pipelines. Some organizations attempted to designate certain types of changes as “standard changes” not requiring CAB review, creating an exemption category that, as DevOps adoption spread, eventually swallowed most of their deployment traffic.

ITIL is not dead. In regulated industries — banking, healthcare, government — formal change management processes remain legally required or practically necessary. ITIL v4, released in 2019, made explicit accommodations for DevOps practices, introducing concepts like “organize for speed” and acknowledging that change management needed to work with high-velocity deployment pipelines rather than against them. But the CAB as a deployment gateway — the CAB as the mechanism by which stability was protected — became a relic in organizations that had adopted the automated safety nets that made frequent, small deployments safe.

The lesson was not that change management was wrong. It was that the appropriate mechanism for managing change risk depends on the nature of the changes and the maturity of the automation around them. ITIL’s mistake was not its principles but its assumption that the principles required a specific bureaucratic form that could not adapt to orders-of-magnitude changes in deployment frequency.

The Cultural Transformation

The technical tools of DevOps — CI/CD pipelines, Infrastructure as Code, monitoring and observability platforms — were necessary but not sufficient. The transformation they enabled was organizational.

The DevOps movement’s most enduring insight was that the wall between development and operations was not a technical wall but a cultural and organizational one. Developers and operators were not separated by technical incompatibility. They were separated by different incentive structures, different measurement frameworks, different definitions of success, and the organizational distance that prevented them from understanding each other’s constraints.

The solutions the movement proposed were primarily cultural: shared responsibility for production systems, combined on-call rotations that put developers in the pager rotation so they felt the operational consequences of their own code, blameless post-mortems that treated incidents as system failures rather than individual failures, and the gradual erosion of the organizational boundary through co-location, shared tooling, and shared metrics.

“You build it, you run it” — the Amazon principle articulated by Werner Vogels — was not a technical statement. It was a statement about accountability and feedback. If the team that built a service was also responsible for operating it in production, they would make different design decisions. They would instrument their code more carefully, because they were the ones who would be woken up at 3 AM when the instrumentation was missing. They would design for graceful degradation, because they had experienced what happened when it wasn’t there. They would write runbooks and operational documentation, because they were the ones who would need them.

The organizational form that emerged — the autonomous, cross-functional team that owned a service from development through production — was the structural implementation of the DevOps insight. Not a development team and an operations team collaborating on a service, but a single team with the skills and authority to do both.

For the Agile practices that preceded and shaped the DevOps movement, see The Agile Revolution. For the version control infrastructure that CI/CD pipelines depend on, see The Rise of Version Control.

---

📚 Sources

• Allspaw, John & Hammond, Paul: “10+ Deploys Per Day: Dev and Ops Cooperation at Flickr” — Velocity 2009, O’Reilly (June 2009)
• Kim, Gene; Behr, Kevin & Spafford, George: The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win (2013), IT Revolution Press
• Kim, Gene; Humble, Jez; Debois, Patrick & Willis, John: The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations (2016), IT Revolution Press
• Beyer, Betsy; Jones, Chris; Petoff, Jennifer & Murphy, Niall Richard (eds.): Site Reliability Engineering: How Google Runs Production Systems (2016), O’Reilly Media
• Fowler, Martin: “Continuous Integration” — martinfowler.com (2006, updated 2024)
• Humble, Jez & Farley, David: Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation (2010), Addison-Wesley
• Morris, Kief: Infrastructure as Code: Managing Servers in the Cloud (2016), O’Reilly Media
• Debois, Patrick: “DevOps: A Software Revolution in the Making” — Cutter IT Journal 24, no. 8 (2011)
• Vogels, Werner: “A Conversation with Werner Vogels” — ACM Queue 4, no. 4 (2006)
• AXELOS: ITIL 4 Foundation (2019), The Stationery Office