One of the criticism of DevOps we hear often is that it’s too focused on getting operations to change according to what developers want than getting developers to adjust to the realities that constrain operations. For example, Circonus CEO Theo Schlossangle made this point on theCube earlier this year.

There are exceptions. J. Wolfgang Goerlich told Wikibon earlier this year that he lead his IT ops team to adopt agile operations practices before the dev team adopted agile development practices. And I’ve written before about how prominent members of the DevOps community emphasize the importance of Ops.

But the culture gap can be a problem, and the flap about “NoOps” was representative about the tensions that can arise as developers gain more influence, possibly at the expense of operations.
A few months ago Alex Tatiyants ran a story called “DevOps is Ruining My Craft:

Sure, you might get your precious “predictability”, but at what cost? I mean, can you even still remember that rush of intrigue and anticipation you get when your application refuses to work on two of the twelve servers it was deployed to? The thrill of the hunt as you figure out exactly which configuration settings are different and, of those, which one is causing the problem? The sweet taste of relief that you get after hours upon hours of debugging finally narrowed it down to a rogue registry setting?

It’s obviously satire, but I can understand why sysadmins would be unhappy to see developers coming in telling them how to do their jobs. As I wrote before:

Developers are now treated like rock stars. That’s got to burn a lot of people on the operations side. I know from first hand experience that ops people – system admins, system engineers, networks engineers, data center managers, etc. – have it rough. They work long hours, have enormous pressures and are often seen as “cost centers” who love saying no and slowing down progress. It’s often thankless job.

Meanwhile, we keep hearing “developers, developers, developers” and “developers are the new king makers.” The RedMonk analysts try to make it clear that when they say “developers” what they really mean is “practitioners.” They include system admins, designers, etc. in their definition of “developers.” But it does seem that most people are pretty focused on programmers, not the people out there racking and stacking servers, when they say “developers.”

So what causes this cultural divide? Ops staff tend to be conservative. Not necessarily in the political sense, but in the sense of preferring stability to new shiny things. I’m painting with very large strokes, but in the companies I’ve worked in the operational IT people (system admins, DBas, network engineers, etc.) have been more likely to live in the suburbs, drive pick-ups or SUVs, have served in the military and eat meat and potatoes for lunch. Developers, on the other hand, were more likely to live in the city, ride their bikes to work, have gone to college and eat sushi for lunch. The individual traits vary from person to person, but the pattern is that one team like stability, the other is neophilic.

It makes sense that conservative people would gravitate to careers that emphasize up-time and neophilic people would be more attracted to development jobs. But it creates an atmosphere where one group would prefer to stick with something that works, both in terms of technology and process, and another that constantly wants to try new things. Add the possibility that DevOps might reduce the number of Ops jobs, and you can see why the Ops side might not be as down with DevOps as the Dev side.

What can be done? As usual, I’ll recommend getting developers on the call rotation. Once developers can start to see the Ops’ pain, there can be much better communication between the two departments. Ops should also accept that, done right, agile will mean less downtime and rollbacks. But these are the normal, predictable recommendations. Are there any less obvious solutions to the Dev/Ops divide?

Photo by Zitona