Skip to content

A Summary on DevOps - DevOpsDays Beijing 2017

talks 2 min read

Event logo

The DevOps story starts with a simple observation: developers and operations had completely different incentives. Developers wanted to ship changes fast, operations wanted stability. That tension led to the famous “wall of confusion” where code got thrown over the fence. The spark came from John Allspaw and Paul Hammond’s 2009 talk “10+ Deploys Per Day” at Velocity, showing that speed and stability weren’t opposites. That inspired me to organize the first DevOpsDays in Ghent later that year, and the movement took off from there.

The CAMS model – Culture, Automation, Measurement, and Sharing – became our way to frame what DevOps actually means. Culture is about trust and collaboration between teams. Automation covers everything from configuration management to deployment pipelines. Measurement means monitoring and metrics that everyone can access, not just ops. And Sharing is the glue: open communication, blameless postmortems, and learning from failure together.

I break DevOps improvement into four areas. First, extend the development pipeline into operations – continuous delivery, infrastructure as code, automated testing all the way to production. Second, create feedback loops from operations back to development – monitoring, alerting, and making production data visible to developers. Third, embed developers into operations work – on-call rotations, incident response, understanding the production environment. Fourth, embed operations thinking into development – non-functional requirements, capacity planning, and operational concerns from day one.

Configuration management tools like Chef and Puppet were catalysts, not because the tools themselves were revolutionary, but because they forced developers and operations to collaborate on the same codebase. Suddenly you had version control, code review, and testing applied to infrastructure. That shared practice broke down barriers faster than any cultural initiative alone.

Chaos engineering, ChatOps, and game days became the practices that kept pushing the boundaries. Injecting failure deliberately, running operations through shared chat channels, and simulating incidents before they happen – these all build the muscle memory teams need. But the frontier I keep coming back to is external services. We’ve gotten decent at collaborating within our own organizations, but the moment you depend on a third-party API or cloud provider, all those DevOps practices hit a wall. Learning to extend trust, communication, and feedback loops across organizational boundaries is where the real work lies next.

Watch on YouTube — available on the jedi4ever channel

This summary was generated using AI based on the auto-generated transcript.

Navigate with