Flickr & the Origin of DevOps

This is a real, named company's story, and it sticks to what's actually documented: John Allspaw and Paul Hammond's own conference slides and blog posts, Flickr's own engineering blog, and the historical record of the DevOps movement's earliest months. What is DevOps? already told you the headline — a 2009 Velocity talk, ten-plus deploys a day, Patrick Debois coining a name a few months later. This page goes underneath that headline: what the talk actually argued, what "shared tooling" and "shared on-call" concretely meant inside one Yahoo-owned photo-sharing site, and why historians reach for this specific 47-minute talk instead of any of the other people who were saying similar things around the same time.

Before the talk: a Yahoo-owned photo giant with the usual wall

☺ Like you're 10: Flickr wasn't a scrappy little side project when this happened — it was one of the biggest photo sites on the internet, owned by Yahoo, which made "just deploy more often" a genuinely risky thing to say out loud.

Yahoo acquired Flickr in 2005, and by the time this story takes place Flickr was one of the highest-traffic, most heavily used photo-sharing services on the web — built, as Flickr's own engineers (including Cal Henderson, author of the widely read Building Scalable Web Sites) had written and spoken about publicly, on a PHP and MySQL stack that had already been scaled hard. That matters for the case study, because it rules out the easiest objection to this whole story: this wasn't a five-person startup with nothing to lose. It was a large, established, revenue-relevant property inside one of the biggest internet companies of the era, which is exactly the kind of organization conventional wisdom said should deploy less often, more carefully, through more approval gates — not more.

The conflict this talk is famous for naming wasn't unique to Flickr. Every organization splitting "the people who write the code" from "the people who keep it running" tends to arrive at the same standoff described on What is DevOps?: Dev is rewarded for shipping change, Ops is rewarded for nothing breaking, and since change is what breaks things, Ops's rational response to an unfamiliar deploy is to slow it down. What made Flickr's version of that standoff worth a conference talk wasn't the conflict — everyone in the room already knew that conflict personally. It was the claim that they'd actually dissolved it, at production scale, and could show exactly how.

The talk: naming the conflict at Velocity 2009

☺ Like you're 10: Two Flickr managers stood on stage and said the quiet part out loud: Ops's real job was never "say no to change," it was "help the business change safely" — and then they proved it with their own dashboards.

In June 2009, John Allspaw — who ran Flickr's Operations engineering group — and Paul Hammond — who led Flickr's Engineering (development) side — gave a talk titled "10+ Deploys Per Day: Dev and Ops Cooperation at Flickr" at the O'Reilly Velocity Conference in San Jose, the industry's dedicated web-performance-and-operations event that year. Velocity itself is part of the context: this wasn't a talk buried in a general software conference, it was delivered to a room of the exact operations and infrastructure engineers most likely to be skeptical of "just deploy more."

The talk's framing, as later write-ups and Allspaw's own subsequent writing describe it, laid the conflict out almost as a syllogism: Dev's job, as usually defined, is adding features. Ops's job, as usually defined, is keeping the site stable and fast. Since most outages trace back to some change, the two definitions point in opposite directions by construction — and an organization is left with essentially two choices. Discourage change, and slow deploys down to protect stability. Or build the tools and the culture that let change happen as often as the business needs it to, while actively engineering down the risk each individual change carries. Flickr's talk was, in effect, a demonstration of the second path, argued from the position that Ops's actual job was never "prevent change" — it was "enable the business," and a website that can't ship anything is not a stable business outcome either, whatever the uptime dashboard says.

What shared tooling actually looked like at Flickr

☺ Like you're 10: "Dev and Ops share tools" wasn't a slogan — it meant one shared history of changes, one button to ship, and a screen full of numbers that both teams looked at, not two separate screens each side kept to itself.

Strip the talk down to its mechanics and a handful of concrete, specific practices carried nearly all the weight. None of them individually looks radical fifteen-plus years later — that's the point; this talk is a large part of why they now look ordinary instead of radical.

Read that list against the CALMS framework from What is DevOps? and the pattern is obvious in hindsight: nearly every row is the Automation and Sharing letters made concrete, years before CALMS had that name. See CI/CD pipelines for how one-step build-and-deploy generalizes into a modern pipeline, and monitoring & observability for where shared metrics dashboards go from here.

Feature flags and dark launches: decoupling deploy from release

☺ Like you're 10: Flickr didn't wait for a new feature to be perfect before shipping the code — they shipped it turned off, tested it quietly in production, and only flipped the switch once they trusted it.

The single most influential technical idea in the talk was feature flags. Flickr reportedly ran on the order of a couple hundred of them at once, and they solved two problems simultaneously. First, a branching problem: instead of long-lived feature branches that drift from the main codebase and become painful to merge, incomplete work could be committed straight to the trunk, hidden behind a flag that kept it invisible until it was ready — an early, concrete instance of the trunk-based development pattern this course covers in full on version control & branching. Second, and more consequentially, a risk problem: a flag lets you separate the act of deploying code (getting it onto production servers) from the act of releasing it (turning it on for real users). Flickr used this to run what the industry now calls dark launches — shipping a new feature's data path live in production, silently, so its real load and behavior could be observed under genuine production traffic, before a single pixel of UI was ever shown to a user.

// Illustrative only — not a literal excerpt from Flickr's 2009 codebase,
// but the shape of the pattern the talk described: ship the code dark,
// verify it under real production load, then flip it on for real users.

if ($feature->isEnabled('new_photo_uploader', $user)) {
    // new code path — live in production, dark-launched to
    // internal staff and a small traffic percentage first
    $result = NewUploader::handle($request);
} else {
    // existing, trusted code path — everyone else
    $result = LegacyUploader::handle($request);
}

The payoff was that a bad feature stopped being an emergency and became a configuration change. If a dark-launched path caused trouble, someone flipped the flag off — no rollback, no redeploy, no waiting for a build pipeline to run again. That's the direct ancestor of the canary releases, percentage rollouts, and kill switches covered in full on deployment strategies and, in much greater depth, on Feature Flags & Progressive Delivery.

Shared on-call, shared incentives: the cultural principles

☺ Like you're 10: The tools only worked because both teams also agreed on the people rules — nobody hides information, nobody gets blamed for an honest mistake, and the person who writes the code also gets the pager when it breaks.

Tooling was roughly half the talk. The other half was a set of cultural commitments the two presenters argued were just as load-bearing — and arguably harder to copy than any dashboard, because they require both sides to actually change behavior, not just install something. Summarized from how the talk and its many contemporaneous write-ups describe it:

• Respect — retiring the stereotypes each side carried about the other (Dev as reckless, Ops as obstructive) in favor of recognizing both sides were optimizing for something genuinely valuable, just not the same thing.
• Trust — Ops giving developers real, often read-level, access to production systems and data instead of guarding it as leverage; operational transparency as a default, not a favor.
• A no-blame stance on honest mistakes — treating an incident as a system-and-process problem to fix, not a person to find and punish. This is the same lineage this course's incident management page and the DevOps world's later "blameless postmortem" vocabulary both grew out of.
• Understanding the need behind a request before saying no — Ops engaging with what a developer was actually trying to accomplish, rather than reflexively blocking anything unfamiliar.
• Developers carrying the pager for what they shipped — putting engineers on-call for their own code, which does two things at once: it gives a developer direct, personal motivation to write safer, more observable code, and it puts Dev and Ops through the same 2 a.m. experience instead of only one side ever living it.
• Honest, specific feedback in both directions — Ops naming concretely what operational behavior was causing pain, instead of a vague "be more careful," and Dev doing the same about what tooling or process was slowing them down.
• A healthy, planned-for relationship with failure — expecting things to break, rehearsing the response ahead of time, and treating a well-handled incident as evidence the system was designed sensibly, not as evidence someone screwed up.

Notice how much of this list is the same ground covered later, in far more depth, on culture & collaboration — and it should. That page and this one are describing the same underlying discipline; this one just shows where a large piece of the vocabulary for it first got demonstrated in public. Shared on-call specifically is covered further on On-Call Culture & Sustainable Operations.

Why historians point to this exact talk

☺ Like you're 10: Lots of people had already had the idea. This talk is famous because it's the moment the idea got a name-worthy, at-scale, "here's exactly how" example everyone could point to.

The Agile-2008 hallway conversation between Debois and Shafer is the earlier claim on "who thought of it first," and it's worth taking seriously rather than erasing in favor of a cleaner story. But an idea traded in a hallway between two people doesn't spread on its own. What made Allspaw and Hammond's talk the moment that actually caught fire was a specific combination that's easy to name and hard to fully replicate: a recognizable, high-traffic company (not a hypothetical), two credible engineering managers presenting jointly from opposite sides of the wall they were describing, a headline number concrete enough to be quoted out of context ("10+ deploys per day"), delivered at the conference most likely to reach exactly the skeptical operations audience who needed convincing, with slides detailed enough to be shared, restudied, and cited for years afterward. Patrick Debois has said publicly that he wasn't even able to attend Velocity 2009 in person — he heard about the talk secondhand and was struck enough by it that a few months later, in October 2009, he organized DevOpsDays Ghent and coined "DevOps" as a contraction of the event's own name. The proximate trigger for the name is this talk. The underlying philosophy predates it by roughly a year. Both things are true, and a precise case study should say so rather than pick the tidier of the two.

Ten years later: Allspaw and Hammond's own retrospective

☺ Like you're 10: The two people who started this whole thing got back on a stage in 2021 and admitted they weren't thrilled with what "DevOps" turned into in the years after.

In 2021, John Allspaw and Paul Hammond appeared together again — at USENIX's SREcon21 conference, alongside Thomas Depierre — for a session pointedly titled "DevOps Ten Years After: Review of a Failure", with the tagline "old men yelling at clouds." The title alone is worth sitting with: the two people most closely associated with kicking off a movement chose, a decade later, to frame their own retrospective around the word failure. Full session detail is behind USENIX's own conference archive rather than freely reproducible here, but the framing lines up directly with something this course already names on What is DevOps? — that "DevOps" got widely misread as a job title to hire for, or a product to buy, rather than the shared-incentives practice Allspaw and Hammond actually described in 2009. A self-critical retrospective from the original presenters is strong, direct evidence that this drift is real and that they noticed it happening to their own talk.

What to steal for your own org

☺ Like you're 10: You don't need Flickr's traffic to copy the habits — start with one flag, one shared channel, and one engineer who carries the pager for their own code.

• Decouple deploy from release before you decouple anything else. A feature flag is the single cheapest risk-reduction tool on this whole page — it turns "ship a bad feature" from an incident into a toggle, and it's the one practice from 2009 every team can adopt this week regardless of scale. See Feature Flags & Progressive Delivery.
• Give the other team your dashboards before you ask them to trust your judgment. Flickr's shared Ganglia/Nagios metrics turned "trust me, it's fine" into "look at the same graph I'm looking at." Shared visibility is cheaper to build than shared trust, and it's usually the fastest path to earning the second one.
• Announce every deploy somewhere everyone can see it. An IRC bot in 2009 is a Slack webhook today — the specific tool matters less than the principle that nobody on either team should have to ask "did something just change?"
• Put the person who wrote it on the hook for running it. Developer on-call for shipped code is the single practice most responsible for making the rest of this list actually stick — it's the same "you build it, you run it" logic What is DevOps? already credits to Amazon, demonstrated independently and around the same era at Flickr.
• Separate the idea from the proof when you tell this story internally. If you're trying to get a skeptical Ops team or leadership to buy into more frequent deploys, a concrete number from a real, comparable company beats an abstract argument about culture every time — that's the exact persuasive mechanism this talk itself relied on.

Honest caveats: what doesn't transfer

☺ Like you're 10: One famous, well-received talk from one company, fifteen-plus years ago, isn't a controlled experiment — treat it the way you'd treat any single success story.

• The headline number is self-reported and anecdotal. "10+ deploys per day" comes from the presenters' own account of their own team, not an independently audited log. Treat it as evidence the approach clearly worked at Flickr, not as a benchmark to hit as a target in itself — a team that starts deploying ten times a day without the tooling and culture underneath it is just shipping risk faster.
• This was a specific, relatively small, highly skilled team inside a much larger company. Flickr's engineering organization was a focused unit within Yahoo, not Yahoo's entire multi-thousand-person engineering org adopting these practices uniformly. The 2015 organizational-learning retrospectives on this story (comparing Flickr's release cadence to slower-moving Yahoo properties of the same era) make this contrast explicit: the rest of the surrounding company did not automatically inherit what one team had built.
• The talk is a survivor's account. This is the team that made frequent deploys work, presenting at a major conference about their success. It says little about teams that attempted something similar and quietly failed, and those failure stories are, unsurprisingly, far less documented and far less often invited to keynote a conference.
• Cultural principles are the hardest row in the table to copy, and the least verifiable from outside. "Respect," "trust," and "no-blame" are stated commitments in a 2009 slide deck, not something an outside reader can audit the way a deploy-logging tool can be inspected. Whether Flickr's day-to-day culture actually lived up to the ten principles as consistently as the talk suggests is not something this page — or any outside account — can verify independently.
• Even the presenters revisited this critically. The SREcon21 "Review of a Failure" retrospective above is itself a caveat: take it as a signal that the popularized version of "DevOps" the wider industry ran with diverged, in the original authors' own view, from what this specific talk actually argued.

Where this connects in the course

☺ Like you're 10: This one talk touches almost every lesson in this course — follow whichever thread matches what you're building next.

The origin summary this page expands on lives on What is DevOps? and the DevOps lifecycle. The deploy-mechanics half of this story is covered in full on CI/CD pipelines, version control & branching, and deployment strategies, with feature flags and dark launches specifically getting their own deep dive on Feature Flags & Progressive Delivery. The cultural half — shared incentives, blameless response to failure, and developer on-call — is culture & collaboration, incident management, and On-Call Culture & Sustainable Operations. For "you build it, you run it" carried to its fullest, most literal conclusion at a different company, see Amazon & "You Build It, You Run It." For another real company's continuous-deployment story from the same DevOps-founding era, see Etsy & Continuous Deployment. And for how "measure it, don't just believe it" eventually became a formal discipline of its own, see measuring success: the DORA metrics.