A word of caution

This post is addressed to all those people who think they know what DevOps means, but they don’t. If you don’t recognize yourself in this post, then maybe it’s not for you. If you recognize yourself, then beware: you’re going to be insulted: read at your own risk and don’t bother asking for apologies.

DevOps is everywhere. So bad it’s not.

DevOps is in everyone’s mouth. It’s the theme for entire conferences or the topic for at least one talk in many conferences. It fills the blogs of people and companies. It fills the mouths of clueless executives.

Unfortunately, the more widespread the word, the less understood the concept. It’s easy to expect how, as the word “DevOps” goes up and up the management chain, its meaning gets oversimplified to the point that when it reaches the Board it has a complete different meaning than when it started the journey. That’s understandable. The depressing part is when this meaning goes back down the chain and owns the head of mediocre techies, giving birth to horrible monsters that, alas, get tagged as DevOps. Examples of such monsters are:

• DevOps is identified with the usage of a certain set of tools: you use Puppet, CFEngine, Chef? Or maybe Ansible or SaltStack? You make nifty graphs with your Kibana? You have an hybrid cloud with OpenStack and AWS? You do microservices, pack them into Docker containers, deploy them “in the cloud”? Then you DevOps.
• You fired all your operators and your developers must now take care of everything? Operators are a stinky legacy of the past? Then you DevOps.
• You replaced your job title (“Web developer”, “System Architect”, “Crow counter engineer”…) with “DevOps” or “DevOps engineer”. Because yeah, you DevOps.

Bullshit.

The first, for example, is bullshit. Using a certain tool/set of tools isn’t DevOps, the same way that owning a Ferrari doesn’t make you a professional racing driver.

The second is also bullshit. Let me whisper a thing in your ear: it’s called “cloud”, but it’s not thin air. Guess who’s taking care that your shitty containers are running on something? Hint: it’s not your granma.

The third is, guess what?, bullshit. Let’s be clear: it’s a good move in order to get caught into the nets of keyword-based CV scanners of recruitment agencies. You have a point there. But it’s no more meaningful than someone running a one-person company and tagging himself as “CEO at John Smith Consulting LTD”.

But these misconceptions are now widespread. While it’s understandable, though very sad, that non-technical executives don’t get it right, fire all the operators and make a mess of their own business, it made me furious and frustrated at the same time when a developer, now tagging himself as DevOps because “hey, I’m deploying Docker containers in OpenShift”, addressed me and my professional category as a useless legacy of the past in front of an audience. My dear fellow, it was just out of respect for that audience and not for you that you didn’t get a loud “fuck you” in return.

DevOps is the best evolutionary step that happened in our industry in ages, awakening people to the consciousness that well isolated, hyper-specialized people, held prisoner in watertight silos is a poor way to run a crucial part of your business: IT. And it’s a culture, not a tool!

Back to basics: DevOps is a culture…

…and as such is not suitable to idiots, but that’s another story.

The first time I read an organic definition of DevOps it was in Mike Loukides’ booklet “What is DevOps”. There are a few sentences I’d like to quote here.

Referring to a discussion between Adrian Cockcroft and John Allspaw over Adrian’s article NoOps at Netflix [full title: Ops, DevOps and PaaS (NoOps) at Netflix], Mike says:

What Adrian described as “NoOps” isn’t really. Operations doesn’t go away […] If NoOps is a movement for replacing operations with something that looks suspiciously like operations, there’s clearly confusion.

Mike goes on describing how at the dawn of the modern computers era there was no separation at all between developers and operations, how that separation came in the 60’s, evolved into the IT Operations of the 80’s/90’s, was put under pressure by the need for more automation, and started to blur again when “configuration management” had to be accepted as a mandatory necessity. Infrastructure as a code was born.

The end of operators? Not quite. Mike says:

Rather than envision some sort of uber developer, who understands big data, web performance optimization, application middleware, and fault tolerance in a massively distributed environment, we need operations specialists on the development teams.

Keep this in mind for a while: no uber-developers, but operations specialists in development teams. Got it? OK, keep reading:

The infrastructure doesn’t go away — it moves into the code; and the people responsible for the infrastructure, the system administrators and corporate IT groups, evolve so that they can write the code that maintains the infrastructure. Rather than being isolated, they need to cooperate and collaborate with the developers who create the applications. This is the movement informally known as “DevOps.”

We have an idea of what DevOps really is now. It’s a culture of cooperation. Jez Humble goes even further and asserts that there is no such thing as a “DevOps team”, stressing again how “For developers to take responsibility for the systems they create, they need support from operations to understand how to build reliable software that can be continuous deployed to an unreliable platform that scales horizontally“. Operations is still there.

What’s not there is the silo: the wall rigidly dividing the developers and the operations, or the hyper-specialization that requires developers to lobotomise and ignore anything system or network, and conversely for systems or network administrators to ignore whatever has to do with code: that separation is blurred. Developers need to know more about how the infrastructure supporting their software actually works, so that they can make it better and more reliable. Systems and network administrators need to understand what the code is supposed to do to be able to provide the best solutions.

That’s what high performing it organisations are doing.

Are you?

I’m not. And that upsets me.

Resistance is futile. But fierce.

My resistance is futile. People who claim they are doing DevOps and aren’t won’t repent: they’ll go straight on their road, head down. After all, in democracy the majority decides what’s right and what isn’t, and they will be the majority sooner or later. If they aren’t already.

The resistance of those not doing DevOps is futile. The game is a cultural shift at all levels, starting from the lowest level of operators and their managers and up to the top. It’s a change in how some people have worked for one or more decades, they now have to rethink everything. Never easy to do, as the most common reaction for people in such cases is to push on the brakes with both feet.

Unfortunately, we are talking of a vehicle that is more like a bus than a city car. Who drives the bus is not only jeopardizing their own journey, they are jeopardizing the journey of whoever is on the bus with them. Even if you are the one driving, you are surrounded by people doing all sorts of sabotage: they set your gear into neuter, they pull the handbrake, they cover your eyes…

Nobody goes anywhere.

Maybe that’s why so many of us aren’t doing DevOps, even if we’d love to.