Donnie Berkholz's Story of Data

The interface from Dev to Ops isn’t going away; it’s rotating

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

When I talk about DevOps today, it’s about three main things:

  • Bringing agile development through to production (and back into the business)
  • Infrastructure as code
  • The revolution in IT monitoring (#monitoringlove)

However, what doesn’t seem to be appreciated is how this shift, particularly the first and most important aspect of it, changes the roles of developers and operations teams. And that’s regardless of whether the latter group is called sysadmins, SREs, or DevOps engineers. After three recent discussions and inspired partially by Jeff Sussna’s writing on empathy, I figure it was worth sharing this with the rest of the world.

DevOps isn’t just about developers taking on more work and ops learning Puppet, Chef, etc. That may sound obvious, but it’s the way many organizations seem to see it. It’s not just about making developers responsible for code in production, so they’re getting paged at 3am. Despite the DevOps community being so driven by the ops side of the house rather than developers coming into ops, it can’t limit itself to one-way empathy and one-way additional effort. It has to go the other way too. Developers do need to be responsible for their code in production, but ops also need to own up to the importance of maintaining stable infrastructure in dev and test environments. I’ve seen ridicule for Facebook coming out of the CMO for Marketing Cloud talking about Facebook’s new motto of “Move fast with stable infra” over “Move fast and break things.” But that’s perfectly applicable to this transition, even in spite of it being terrible marketing.

Developers today often own both their application code as well as their environment in dev and maybe test as well, while ops owns applications and infrastructure in production, which the top of this image illustrates:



On the bottom of this image, conversely, the separation between dev and ops has rotated. This is key. It also underlies shifts like Red Hat’s incorporation of CentOS and its move to position both CentOS and RHEL as stable environments to innovate on top of in the context of cloud.

And yet, in every case, what’s missing is the understanding and communication that developers must own application-layer code wherever it lives, while ops must own the infrastructure wherever that is. The external system environment is irrelevant — dev/test/production must all have environmental parity from the application’s perspective. Also irrelevant to this point is whether your ops are traditional or are essentially developers building infrastructure tools. In many cases this rotation may involve using tools like Vagrant or Docker to provision identically from the ground up, but the key transition here is a cultural one of bidirectional empathy and bidirectional contribution.

Disclosure: Chef, Red Hat, and are clients. Puppet Labs has been. DigitalOcean, Facebook, Hashicorp and Docker are not.



  1. […] few weeks after I jotted down this post, Donnie Berkholz of RedMonk wrote a post titled ‘The interface from Dev to Ops isn’t going away; it’s rotating’ where he illustrates neatly how the outcome companies need to be looking for is not what many […]

  2. […] Donnie Berkholz talks how the shift changes the roles of developers and operations teams Read more here (via […]

  3. No mention of PaaS ? Isn’t that the layer ? Docker/PaaS will mean Ops deals with deploying infrastructure only again. And developers only use the PaaS to deploying their applications.

  4. I think this picture is still incomplete. Operations should also be very much involved with the applications (just like dev has to know something about the underlying platform). Closing this mutual gap is really necessary since Dev usually focusses on delivering functionality, while Ops focusses on delivering non-functional business requirements.

    For an application to be able to be useful to the business both functional and non-functional business requirements (stability, performance, security, etc.) have to be satisfied.

    In my experience (and I’m generalizing a bit here) this non-functional aspect is where often dev actions leave something to be desired, and where ops excels (and vice versa).
    The most important thing is therefore that both groups COMMUNICATE with each other.

Leave a Reply

Your email address will not be published. Required fields are marked *