The History of DevOps and SRE: Two Separate Movements That Converged
How Google's Site Reliability Engineering team (2003) and the DevOps movement (2009) emerged independently, from different motivations, and became closely linked practices.
“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.
Sources: History of SRE: Why Google Invented the SRE Role — Rootly, The Incredible True Story of How DevOps Got Its Name — New Relic, Site Reliability Engineering — O’Reilly