The History of DevOps and SRE: Two Separate Movements That Converged

“DevOps” and “SRE” are often used almost interchangeably today, but they have genuinely separate origin stories, born roughly six years apart, solving a similar underlying problem from two different directions — one from inside a single company’s operations team, the other from a grassroots community of practitioners frustrated with the industry status quo.

SRE: Google, 2003

Site Reliability Engineering began at Google in 2003, when Ben Treynor (now Ben Treynor Sloss) was asked to lead a team of seven engineers running a production service. Rather than staffing that team the traditional way — with operations staff following manual runbooks — Treynor, himself a software engineer, staffed and organized the team the way a software engineering team would be run. His own summary of the idea has become the standard one-line definition of the discipline: “SRE is what happens when you ask a software engineer to design an operations function.”

Concretely, that meant SRE teams split their time between traditional operational work and writing software to reduce, automate, or eliminate that same operational work — capped, deliberately, so that operational toil could never permanently consume more than half of an SRE’s time. By March 2016, Google had grown this practice to more than 1,000 site reliability engineers.

Google’s approach reached a much wider audience with the publication of Site Reliability Engineering: How Google Runs Production Systems by O’Reilly on May 10, 2016, written by Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy — the book that turned an internal Google practice into a widely-adopted industry framework, complete with the SLI/SLO/error-budget vocabulary covered elsewhere on this blog.

DevOps: a grassroots frustration, 2008–2009

The DevOps movement emerged independently, and later, from a very different starting point: individual practitioners’ frustration with the wall between development and operations teams. Patrick Debois, working on a data center migration project in 2007, grew frustrated switching between developer and operations contexts on the same project and began advocating for what he called “Agile Infrastructure.”

At the Agile 2008 conference in Toronto, Debois organized a “birds of a feather” discussion session titled “Agile Infrastructure” — exactly one person attended. The idea gained real traction a year later: in June 2009, Debois watched a remote stream of John Allspaw and Paul Hammond’s talk “10 Deploys a Day: Dev and Ops Cooperation at Flickr” at O’Reilly’s Velocity conference, describing how Flickr’s developers and operations staff worked together to deploy rapidly and reliably. The talk resonated strongly enough that Debois decided to organize an in-person event around the same idea.

That event, held during the last week of October 2009 in Ghent, Belgium, needed a name. Debois has since said the choice was almost incidental — he wanted to promote it on Twitter and needed something shorter than “Agile System Administration.” He shortened “Development and Operations” to a hashtag: DevOpsDays, later shortened again in common usage to DevOps.

Two paths to a similar destination

SRE and DevOps solve overlapping problems — breaking down the traditional wall between building software and operating it reliably — but they arrived at that goal differently. SRE began as one company’s specific staffing and engineering philosophy, formalized and centrally documented; DevOps began as a decentralized cultural movement, defined more by shared practices and community events (DevOpsDays chapters now run in cities worldwide) than by a single company’s playbook. In practice, most organizations today draw from both: SRE’s concrete measurement framework (SLOs, error budgets) combined with DevOps’ cultural emphasis on shared ownership, automation, and continuous delivery across the development/operations boundary.

Why the combination matters today

Nearly everything covered under this blog’s “SRE & DevOps” category — container orchestration, infrastructure as code, observability, incident response practices — exists downstream of this same underlying shift: treating operations as an engineering discipline with its own measurable practices, rather than a separate, informally-run function bolted onto software development after the fact. Both SRE and DevOps, independently, arrived at that same conclusion — which is a large part of why they’re so often discussed together today, even though neither one started as the other.

What the primary records actually support

Google’s published SRE book has Treynor Sloss describe joining Google in 2003 and being asked to run a production team of seven engineers. It also states the software-engineering model and the operational-work ceiling that protects time for engineering. Those are first-party statements about Google’s practice; they should not be generalized into a claim that every organization calling a team “SRE” follows the same staffing or toil policy.

The archived DevOpsDays record confirms the first event in Ghent in 2009. Allspaw and Hammond’s original Velocity presentation documents the technical and organizational cooperation at Flickr that influenced the community. These artifacts establish events and ideas more reliably than later retellings that assign one universal definition to DevOps.

Convergence did not erase the distinction

DevOps remains a broad movement about flow, feedback, automation, and shared responsibility across delivery and operations. SRE offers a more prescriptive implementation vocabulary around service indicators, objectives, error budgets, toil, on-call, incident response, and engineering work. Google explicitly describes SRE as a concrete implementation of ideas that align with DevOps, not as a synonym for a job title or toolchain.

Organizations can therefore adopt DevOps practices without a team named SRE, and can create an SRE function while still failing at cross-team ownership. The useful audit question is not which label appears on an org chart. It is whether teams share production outcomes, measure user-facing reliability, automate repeatable work, learn from incidents, and control change with evidence.

Related:

Sources: