Devops - Solution to a Problem, Not a Cure for All Ills

With great interest I read a recent post by Chris Hoff on devops disconnect (make sure to read the comments too).

Devops as a way to promote “collaborative and communicative culture” (see John Allspaw’s comment) - “devops the culture” henceforth - was born out of frustration on both sides of the house (dev and ops) when it was time to push out and troubleshoot a new code release. In most web companies, a new release would happen on a weekly, bi-weekly or monthly basis - and the night of bad blood, fingerpointing, cursing, non-stop conference calls and IM conversations, all-nighters and so on would take center stage, with more of the same a couple of days later at a postmortem. Most frustratingly, anyone who has ever worked through anything similar inevitably realizes that the amount of stress could be considerably reduced by simple coordination beforehand when concerns could be raised and addressed.

Similarly, if you ever had to troubleshoot someone else’s code in a stressful situation, you would often realize that code in question was not written with such situations in mind - inconsistent and/or incomplete logging, lack of clear understanding of dependencies, failure to properly catch network socket exceptions. Again, this experience can be made much much better by close involvement of ops in parts of development process.

I believe it’s important to realize that “ops” in “devops the culture” does not stand for all of operations (which includes systems engineering, networking, storage and security). I specifically mean a subgroup of operations that most commonly is referred to as “application integration,” “application support” or “application engineering.” These are the folks who run the software infrastructure on top of which developers’ code is running. In bigger companies, these would be dedicated people. In smaller ones, the same people may also wear other ops hats such as networking or storage.

Now, don’t get me wrong - I would LOVE to see “devops the culture” applied to all silos in IT. But it’s easier said than done, at least for purely technical decisions. I have been a part of multi-silo technical teams tasked with making specific decisions. No matter how much discussion or coordination occurs, the decision still ends up being made by whoever knows the area best (have you ever witnessed developers giving suggestions to network engineers how to design the network? what about storage people advising security? and the best part - systems engineers advising developers how their code should run?). Hard to say it’s a bad thing either, especially from responsibility and accountability standpoint.

Hence, in my humble opinion, “devops the culture” is not about how to bring collaboration to all of IT. It’s about avoiding frustrating experiences related to running one’s own code in production.

Network, security as well as systems do play a big role in “devops the infrastructure as code” (see Adam Jacob’s comment) however - there’s no question about that in my mind. How well these areas will lend themselves to automation still remains to be seen however.