A Short History of DevOps: The Checked Timeline

TL;DR: The history of DevOps runs two decades behind its own word: the ideas date to the late 1980s, Google ran SRE from 2003, and Patrick Debois gave the movement its name at DevOpsDays in Ghent in 2009.

• Winston Royce’s 1970 paper drew the sequential model as a warning, called late testing “risky and invite failure,” and proposed five extra steps; the industry kept the diagram and dropped the steps.
• Seventeen developers published the Agile Manifesto at the Lodge at Snowbird, Utah, in February 2001, with Scrum already six years old; feedback moved inside the project while the road to production stayed as it was.
• Google founded Site Reliability Engineering in 2003 with seven production engineers under Ben Treynor Sloss, and Netflix followed with Chaos Monkey in 2011, on either side of the 2009 coinage.
• Continuous Delivery (2010), The Phoenix Project (2013), and The DevOps Handbook (2016) made the movement teachable; DORA’s 2016 report gave it four measurable metrics.
• Deploying is not releasing: feature flags separate putting code into production from turning it on for users.

Ask when DevOps started and the usual answer is 2009, plus a story about a conference in Belgium. The history of DevOps is longer than that: proposals for tying development to deployment and operations date to the late 1980s, and the companies usually credited as early adopters were building the practices before the word existed. This article is the written half of the Whiteboard Architect lesson A Short History of DevOps: The Checked Timeline. Watch the full episode on YouTube for the boards drawn in real time, or read on: every date below links to the page it was checked against.

The opening board: two crossed-out claims, one correction, and the checked timeline that replaces them.

The 1970 diagram published as a warning

The model everyone now calls waterfall entered print in 1970, in a paper by Winston Royce that called its own sequence “risky and invite failure” for leaving testing to the end, and then proposed five additional steps meant to remove most of the development risks. Wikipedia’s waterfall model article carries the full sequence.

Feedback lands last, so a wrong turn taken early is discovered only after the whole system exists, when a change forces redesign and retesting at the highest cost. The same article ranks the sequential model among the least iterative and flexible ways to build software on record.

What did Royce propose, and what did the industry keep?

Five additional steps wrapped around the sequential core, and the article’s history section names “complete documentation at various stages of development” among them. The additions existed to strip most of that risk out of the unaltered sequence: with testing last, a defect found at the end costs the whole redesign. None of the five took hold, so the industry kept the picture and dropped the repair kit that came with it.

The name came later still. Royce’s paper says waterfall nowhere, and the earliest use of the term may trace to a 1976 paper by Bell and Thayer, an attribution Wikipedia itself marks as needing a better source.

Agile, 2001: feedback moves inside the project

February 2001: seventeen developers met at the Lodge at Snowbird, a Utah ski resort, and published the Agile Manifesto, four values they signed together: “individuals and interactions, working software, customer collaboration, and responding to change.” The manifesto’s own history page dates the meeting to February 11 through 13, 2001.

None of these methods began at Snowbird: Scrum had been formalized in 1995, and Extreme Programming already existed under its own name in the wider lightweight-method family; Kanban took shape years after the manifesto. What changed is where feedback landed. Under the sequential model it arrived after the build; under the agile methods it arrived during the project, delivered in small increments.

The manifesto itself said nothing about the life of code after it left the developer’s machine. Release engineering, environments, and production stayed somebody else’s department, and the speedup stopped at that boundary.

Which methods already had names when the manifesto landed?

Scrum, formalized in 1995, was six years older than the manifesto, and Extreme Programming was already in use among lightweight methods; Kanban was identified as a method years after the manifesto. The seventeen signatories did not invent iterative delivery; they wrote down the values the running methods already shared, which is why the manifesto reads as a values document rather than a process specification.

The gap that opened: building fast, running slow

The systems kept growing while the methods stood still. Distributed systems became the norm: cloud platforms, microservices, and many moving parts, all needing frequent updates at internet scale, with users wanting features quickly and rivals competing to deliver faster and more reliably. The pressure has a published shape today: AWS’s What is DevOps page names six demands.

Agile had answered how fast a team can build. How fast a change could safely run in production was the part none of its practices addressed.

Ghent, 2009: the word arrives

Board 5 of 14: Debois, Ghent, and the portmanteau. The crossed-out tale on the right is the part to stop repeating as fact.

The name arrived in 2009, in Ghent. Patrick Debois, a Belgian consultant, organized the first DevOpsDays there; the portmanteau of development and operations traveled with the conference, and credit for coining the term usually goes to Debois, as Wikipedia’s DevOps article records.

Two date checks keep the story honest. First, ideas for tying development to deployment and operations had been circulating since the late 1980s, so 2009 marks the moment the label stuck rather than the moment the thinking started. Second, the story that the spark was a Flickr talk on ten deploys per day is folklore; no authoritative source narrates it.

Where does the ten deploys a day story come from?

From conference folklore. The telling credits a 2009 Velocity talk by two Flickr engineers, about ten deploys per day at Flickr, as the push that made Debois organize DevOpsDays. Wikipedia’s DevOps article cites Debois’s 2008 blog post among its references but does not narrate the talk in its body, so there is no authoritative page behind the story. Retell it as color if you like, with that label attached, and keep it out of any timeline that claims to be checked.

Two definitions, one question

Past the vendor wording, the whole field comes down to how fast a good change reaches production. Two definitions anchor it, and they agree on that much.

The first definition measures a distance, commit to production. The second names the levers, culture, practices, and tools. Only the Bass wording carries a quality requirement: the full sentence continues past the excerpt above with “while ensuring high quality”, and the AWS wording stops at velocity, which is what separates the field from shipping quickly by cutting corners.

Why does one definition measure and the other prescribe?

The Bass, Weber and Zhu wording defines DevOps by its outcome, the time from commit to normal production, which is why the field could later be measured: DORA’s lead time for changes measures exactly that distance. The AWS wording defines it by its inputs, the philosophies, practices, and tools a team adopts, which is why it reads like a checklist for a transformation. An outcome definition can be scored against a clock; an input definition can only be audited for completeness. Both are describing the same work from opposite ends.

The practices came before the name

The correction at the center of this history: Google, Netflix and Amazon were not early adopters of DevOps. DevOps lore came out of them. At Google, Site Reliability Engineering began in 2003, when the movement’s word was still six years away. Ben Treynor Sloss built the first team out of seven production engineers; by 2016 it had passed a thousand, the year the SRE book appeared, per Wikipedia’s SRE article.

Amazon’s part was a business change: instead of a few giant releases a year, small updates went out continuously, absorbing the demand and getting features to users faster. AWS publishes its own version of the advice, and it is worth copying: ship to production often, keep each change small and validated, and let the pipeline trigger itself automatically, because large bundled batches are harder to test and validate, per the Well-Architected DevOps guidance DL.CD.1.

At Netflix, failure became a scheduled event. While migrating to the AWS cloud, the company invented Chaos Monkey, a tool that takes production servers offline at random in normal working hours to see how much of the system survives; Netflix open sourced it in 2012 under an Apache 2.0 license, as part of the Simian Army, per its Wikipedia article.

What does each member of the Simian Army take out?

Chaos Monkey is the smallest one: it switches off production instances at random, in usual activity hours. Above it sit two larger simians: Chaos Gorilla takes out an entire availability zone, and Chaos Kong takes out a whole AWS region. Netflix open sourced the tooling in 2012, which is why chaos engineering exists as a practice outside Netflix too.

The books that named the practice, then the data

Board 10 of 14: three books, six years, one discipline. Forsgren’s name arrives with the 2021 second edition.

Three books, published across six years, took the movement from conference talks to something you could teach.

The measuring stick arrived in 2012, when Alanna Brown published the first State of DevOps report at Puppet Labs. Late in 2015, Nicole Forsgren joined Jez Humble and Gene Kim to found DORA, DevOps Research and Assessment, and led the organization. Its 2016 report published the four key metrics. Google bought DORA in 2018; that year also saw Accelerate, by Forsgren, Humble and Kim, per Wikipedia’s article on Forsgren.

What are DORA’s four key metrics?

The 2016 report published four: deployment frequency, how often a team ships to production; lead time for changes, how long a commit takes to run there; mean time to restore, how fast service comes back after a failure; and change failure rate, the share of deployments that cause one. Two measure speed, two measure stability, and the research finding behind all four is that the pairs move together rather than trading off. Four numbers turn “we are getting better at DevOps” into a claim you can check.

The history of DevOps in one checked table

The full span in one view.

What does the complete checked timeline look like?

Three spans are worth reading off the rows: 31 years from Royce’s warning to the manifesto, 8 from the manifesto to Ghent, and 3 from Ghent to the first State of DevOps report.

Four gotchas before you retell this history

Four corrections cover most of what introductions get wrong.

The history of DevOps, checked: Royce published his diagram as a warning in 1970 and the industry adopted it anyway; the Agile Manifesto moved feedback inside the project in 2001; Ghent supplied the word in 2009, two decades into the ideas; Google from 2003, Amazon, and Netflix from 2011 supplied the practices the word later named. The books made the practices teachable, DORA’s four metrics made them measurable, and deploying remains a separate act from releasing.

Board 14 of 14, the recap. The sticky note carries the distinction the whole history ends on.

Continue learning

• Why DevOps? Where the Traditional SDLC Breaks: the previous lesson of this series, on the lifecycle this history set out to change.
• AI History: Booms, Winters, and Revivals: another checked timeline, this one covering the cycles behind today’s AI.
• DevOps Interview Questions and Answers: Topic Guide: test yourself on the vocabulary this history produced.

Disclosure: this article was drafted with AI from the script of my video lesson, then checked against its sources before publishing.

This lesson first appeared on iqraa.tech.

More whiteboard lessons on the Whiteboard Architect YouTube channel.