By Jason Ritzke — Senior Technical Consultant
Attacking overtrodden topics is almost always a bad idea. The questions of “what is DevOps” and “what isn’t DevOps” have been used, reused, and rehashed to such an extent that there remains little ground to cover in those arenas. But even though that ground has been walked into a muddy rut, while so many people seem to “get” DevOps to the point that discussing it further seems a pointless waste, many organizational leaders still seem unsatisfied with the answers. If you’re among the unconvinced, unhappy with all the direct and explicit answers that abound, let me tempt you with an esoteric and obscure assertion instead.
DevOps isn’t anything special, and that’s precisely why you absolutely must begin applying lessons learned in that culture to your organizational culture if you want your organization to thrive.
If you’ve attended an IT conference with an infrastructure focus in the past five or so years you may have noticed a bit of a subculture struggle muddying the waters of the great DevOps product explosion. While the DevOps movement has garnered a lot of attention and enabled a great deal of very aggressive business improvements for some very successful companies, there yet seems to be a strong contingent of anti-DevOps (or should I call it ProTraditionalOps?) thought leaders. The people I’m concerned with aren’t grade B or C employees, not a throwback or regressive professionals. Rather they’re grade A, tier 1 operations and infrastructure specialists, successful revenue enhancers and sometimes strong (albeit fringe) thought leaders. I like to call these people…
The DevOps doubters
A good friend of mine (let’s call him Jim) is one of these people. Jim is a really great guy, he does Windows and Linux infrastructure management, networking, and has a strong specialization in information security. Jim is smart, he gives talks, and people listen and take furious notes because Jim is almost always right. Jim is also fond of the phrase “DevOps Doesn’t make me angry. I can’t be angry at something that isn’t real and doesn’t exist.”
What does he mean by this? Simply put, he believes there is nothing positive about DevOps that distinguishes it from what is good infrastructure management. And while he’ll certainly agree that DevOps is distinguished from bad infrastructure management, that simply makes it equivalent. On the surface, this seems like an almost nonsensical proposition, but there’s some substantial wisdom in it.
It’s not the tooling
Jim, like most “DevOps engineers” (to use a term he’d hate), makes heavy use of automation, autodiscovery, centralized management and configuration, and continuous delivery/deployment. He and I use similar tools, tools like Ansible and Salt, Vagrant and Docker, Consul and Etc. We regularly share notes on designing highly available hybrid cloud infrastructure. The bottom line is that Jim isn’t behind the ball when it comes to deploying (to great effect) powerful tools that help his business IT run better.
But while all of these tools are new and shiny and associated heavily with the DevOps cultural phenomenon, the ideas and methodologies behind them are not. Tooling to instantiate and configure systems on the fly have with automatic service discovery and monitoring have been around for decades. CFEngine has been around since 1993, and DHCP (the last building block in modern network booting) was published as an RFC in 1997. And considering the fact that many field deployments of distributed data stores use DNS for propagation (formalized in 1987), none of these developments seem truly groundbreaking from a business perspective, given a little historical context.
All the tools necessary to do automatically managed deployments at scale have been around for decades. What has changed, paving the way to the explosive popularity of their successors? Ubiquitous virtualization, plummeting commodity hardware costs, and fast networks. But Jim would argue (and I’d agree) that these changes don’t invalidate all the thought that came before, don’t entail a complete paradigm shift. Rather it’s just more growth along the same curves that really good, top-tier IT professionals had already been working along. Truly revolutionary recent technologies (such as blockchains) really haven’t found a place in infrastructure space yet. The tools are getting better, slowly but surely, but obviously, the tools aren’t what makes DevOps special.
Therefore, it must be the culture
One of the more interesting things about working in the field of IT infrastructure is that it tends to be full of academics, a remarkably idealistic breed. Coming myself from an academic background, it’s a culture that I fit into well. This is something about which Jim gives me grief constantly. “Computers are tools, tools don’t have ideals. The ideal tool is the one that does what you need.” As much as I want to play with the best, fastest, most perfect tooling with the cleanest implementation, I have to concede the point. As long as the tool performs the function and performs it well, concerns of some kind of arbitrary correctness are back seat concerns at best.
I don’t know if Jim realizes that this is another area where he’s a model of a modern DevOps engineer, but it’s absolutely true. Systems thinking, a cornerstone of the approach of DevOps cultural implementation, all but necessitates dispensing with this kind of localized idealism. If there is room for idealism, it’s retained on a grander scale, the question of providing tools to perform the task that the organization wants to achieve, not ones that inflate the IT sub-organizations ego or clout. And the other cornerstones of DevOps culture, feedback loops, and continuous experimentation and learning flow naturally from the first. Being a good DevOps engineer is no different from being a good infrastructure engineer in this regard.
But what about the bad stuff?
There are components to modern DevOps culture that attract negative attention to be sure. The recent left-pad fiasco in the Node.js programming language highlights one of the biggest ones: making your own code deployments highly dependent on the behavior of external actors.
It’s no wonder that people regularly incorporate external dependencies into their systems. When configuration management modules and runbooks are represented as code, when so many libraries for your new app are easy to pull from Github, it’s very convenient and fast to simply pull these down as you require them. But the internet is malleable and fluid, things are moved or even removed on a daily basis. Furthermore, it’s not necessarily safe to trust these external packages, as there are many ways to potentially insert security vulnerabilities (on accident or purposefully) or even outright backdoors into systems via this route. And such things can be even more difficult to find when using tools like Vagrant or Docker, where it’s possible to pull entire operating systems down from the internet.
In the world of infrastructure-as-code, unvetted external dependencies in your automated systems are functionally equivalent to sliding unknown equipment into your racks and cabling it into your systems. That wouldn’t be tolerated and for good reason. If you won’t run untrusted hardware or software, why would you use untrusted configuration parameters for either of those things? This is simply bad management of your assets. And for that reason, I would assert that it’s also bad DevOps, as it exposes your entire system of value delivery to incredible risk. In this way again, DevOps is indistinguishable from traditional administration.
DevOps is not special
At this point, we can see that there are strong parallels (if not outright congruence) between DevOps and good IT infrastructure management. And this leads me to conclude with my original assertion. DevOps is not a magical solution to a special problem. DevOps is just a name that happens to align with the known good methodologies that you should be used to deploy and manage infrastructure at scale, and to have a thriving culture that fosters that workflow. DevOps “isn’t real and doesn’t exist” in the sense that the question for an organization should never be “should we do DevOps” but “shouldn’t we do the best we can?” After that point, well, DevOps comes naturally.