Why DevOps Seems to be More “Dev” than “Ops”

I’ve been struggling with something recently, and in that struggle – which I’ll share in a minute – I’ve had some realizations that I wanted to put before you.

Whether you’re a fan of Apple or not, the company has done something pretty important to the IT industry: they’ve taught people to want apps. Don’t get me wrong; users have always wanted their applications to work, but before Apple and its iPhone, users didn’t really ask for “apps.” It wasn’t in their vocabulary. The switch to “apps” remains a conundrum for traditional IT, because for decades now we’ve been worried about delivering desktops, not apps.

Consider Virtual Desktop Infrastructure, or VDI, a set of tools and technologies that came along at almost exactly the wrong moment. Instead of using inexpensive client hardware, cheap storage, and well-understood techniques to “deliver desktop” to the user, VDI proposed we switch to expensive server hardware, expensive storage, and expensive hypervisor licenses to do the same thing – all at a time when users were finally realizing they didn’t want a desktop at all. They just wanted apps.

“Desktop,” however, is something that traditional IT Operations was really good at. “Apps,” on the other hand… well, that was a Developer thing. Once we got the desktop out, we could distribute your apps to it, but it was the desktop that was important.

Except that the desktop was never actually important. It’s infrastructure, and infrastructure is boring. Sure, it might be necessary, but it isn’t visible, or at least it isn’t supposed to be. Satellite TV customers don’t complain when atmospheric interference causes reception problems, because they don’t pay for reception, they pay for TV shows. Nobody thinks about their water piping – they just want fresh water. And IT Ops is, really, all about infrastructure. It’s not sexy. It’s not interesting. It’s supposed to be invisible.

And that’s why the “Dev” side of “DevOps” has gotten a lot more play and attention. People want apps and services; Dev creates and maintains those. The President of the US didn’t stand up on TV and say, “everyone should learn to subnet,” he said, “everyone should learn to code.” Nobody remembers the guy who installed the kitchen appliances – they just remember the celebrity chef.

And when you start thinking about what DevOps is meant to do, it really is just a formal way of ignoring the infrastructure. Sure, someone has to physically build the servers and ship them to me, but if I’m “doing DevOps,” as the kids these days are saying, then I’m not paying attention to the hardware. Or the network. Or the storage. They’re all appliances – it’s what I do with them that matters. And doing stuff with them means – in a DevOps world – writing code.

I tend to tout PowerShell’s Desired State Configuration as “programming without code,” but that’s deliberately disingenuous. Of course it’s code. A MOF file, despite having no programming logic in it, is still itself a programming language. A high-level one, yes, but a language nonetheless. It’s letters and numbers and symbols, telling a computer what to do, which is all that “code” actually is.

So: Apps come from code. Infrastructure comes from code. All is code.

The struggle that started me down this path was the Hour of Code. It’s a series of high-profile events that are designed to show kids that, in an hour, they can code something interesting and useful. It’s designed to engage their imagination, spark their interest, and get them into coding. Pluralsight was heavily involved in one in 2015, which is when I started noticing the event and its reach. And, as President of The DevOps Collective, I thought, “what could we do, to achieve something similar for Ops and infrastructure?”

I thought, “maybe we could put together little hardware kits, and let kids build out their own computer.” Interesting, yes, and definitely engaging. But, despite my own personal attachment to BYOPC, it’s not really something that sets kids up for big success. We’re moving to an era where normal IT people just won’t build hardware. Machines are already increasingly integrated, prebuilt, and non-serviceable. Yes, there’ll always be jobs in that space, but it’ll be a niche space, and I’m not looking to prepare kids for a niche job.

So I thought, “well, maybe we could distribute something like Raspberry Pi computers, preconfigured with a sort of operating system. Kids could learn to write configuration files, telling the Pi to turn on lights, make sounds, and whatnot.” Except, I mean, toys. That’s just a toy. It’s not like Hour of Code, where you’re getting engaged in something that can be a legit career. And at the end of the day, configuration files are just dumbed-down programming. Why not just let kids do the damn Hour of Code and learn real programming? Sigh.

I’m still struggling to come up with an “Hour of DevOps” or “Hour of Infrastructure” or something, because IT Ops is, broadly speaking, not going to be a niche job. It’s not as headline-y as coding, but we’re still going to need people in their field, and I want to find a way to get kids interested and engaged, as I was when I built my first PC. But in the meantime, this is why I started to realize why the “Ops” side of “DevOps” has been so neglected. Not only is it not terribly “sexy,” and supposed to be invisible, but it’s hard to even define what the heck it actually is. Yes, I get that plumbing is important, but how do you make it exciting for kids? How do you make someone want to do that when they grow up?

And in the meantime, I think it’s an important revelation on where we, as IT Ops people, sit in things. The better we do our jobs, the more invisible we become. The smoother the flight path between app and user, the less the infrastructure is seen. And while that’s the absolute goal of DevOps… how do we make sure it doesn’t become so invisible that it fades into obscurity?



Comments are Closed