How the DevOps movement started

I cofounded the O’Reilly Velocity Web Performance and Operations Conference in 2007. It became the gathering point for practitioners who were independently discovering the same thing: the wall between software development and IT operations was the single biggest bottleneck in shipping reliable software.

Velocity brought together people who were independently discovering the same principles. That infrastructure should be treated as code. That the wall between dev and ops was a cultural problem, not just a technical one. That operational excellence was a software problem. Many of the ideas that became standard practice, continuous delivery, infrastructure as code, blameless postmortems, were first articulated and debated at Velocity. The conference gave the movement a name, a community, and a shared body of knowledge.

I created the conference because I had lived the problems it addressed. As Amazon’s Master of Disaster, I had seen firsthand what happened when development and operations teams did not share context. In operations, we always missed the launch party, because we were too busy in the data center trying to support a launch. We were never there for the fun part. Velocity was my answer: build a community where practitioners could learn from each other at scale.

I went on to cofound Chef, which put the “infrastructure as code” part of DevOps into practice as open-source software. Chef gave every team the same infrastructure automation capabilities that had been closely guarded secrets at Google and Amazon. The tools mattered. The movements they created mattered more.

DevOps is not dead. It is maturing. The principles are now embedded in how the best engineering organizations work. Automation, shared ownership, learning from failure. The next chapter is AI developer tools, where the same cultural and technical shifts are happening again.

Further reading