AMA: Am I “Doing” DevOps?

Luis asks:

Long time fan here, first time writer :). Over the last 10 years I’ve learned a lot of Powershell and have increasingly used it more and more at my place of employment. It’s more or less now 80% of my job (which I love!). However, I know that simply working on automation and scripting alone is not necessarily a “DevOps Lifestyle”. I know it’s more about treating the infrastructure like “cows” instead of pets. I think we’re moving in that direction, but there’s still a terrifying amount of “state” in my infrastructure servers that I really can’t do a whole lot about.

I assume this is probably true for most IT professionals in the Enterprise vs those who are lucky enough to work for the unicorn companies. I assume there’s always going to be some “pets” here and there. I’m working hard to apply DevOps principles in my day to day work, but I can’t tell if I’m just getting better at scripting now or if I could fit into a “DevOps” organization.

When do I know that I’m functioning in a DevOps fashion? Or is that just a thing that happens when your job title includes the word “DevOps” in it?

I hope you’ll ask a question, too! And I hope you’ll stick with me here, because this is gonna be a long one. And here’s the list of everything asked so far.

So, let’s clear up one thing first: should you be doing DevOps?

DevOps is a management technique. Just like screaming at someone and making them do push-ups works well for Marine Corps drill instructors, but works perhaps less well in corporate America, DevOps has a place and a time. It’s not just “anytime I need automation;” automation is a component of DevOps, but it’s hardly the whole picture. DevOps is useful when you have an entire environment that needs to be repeatedly and rapidly spun up and then re-done. Say, if you’ve an Agile development team continually releasing code, and you need to spin up dev, test, and production environments to run that code. “I want to be able to deploy patches to my production machines” isn’t a DevOps scenario; it’s a scenario for owning a patch management solution.

Even organizations that need DevOps rarely need it globally. Take Spotify, a fairly famous DevOps organization. They use DevOps principles throughout the Spotify product that you see, like the smartphone app. I doubt they use it to manage their own desktops, laptops, and mobile devices used by their team. When they let someone go or hire someone, I doubt they’re tearing down the entire environment and rebuilding it to reflect the new org chart. Sure, they probably use some automation, but the point is that no company is “fully DevOps” in every aspect. Companies with no internal dev team and few on-premises resources will also not “do DevOps,” because they’ve likely no need to.

There is tremendous value in providing automation in non-DevOps scenarios. Enterprises need automation, and they need it almost everywhere, not just in places where DevOps might be a legitimate approach. Automating on boarding of new hires isn’t DevOps, and doesn’t need to be, but it’s a solid thing to automate. DevOps is not going to “take over” IT because it isn’t a suitable methodology for managing all of IT.

Even organizations practicing “Infrastructure from Code,” who might well use DevOps to manage that, won’t do it with every possible piece of infrastructure. You’re likely not spinning up new SharePoint environments, and tearing down the old ones, every ten minutes, but that’s largely what “Infrastructure from Code” is designed to facilitate. Sure, maybe you use Desired State Configuration, Puppet, Chef, or something else to maintain the existing environment, but that’s not a DevOps scenario, either. DevOps rarely seeks to “maintain;” it seeks to simply re-build from scratch.

You’ll likely always have significant investments where you do have a lot of “state,” and have to treat servers like pets, not cattle. That’ll especially be true for older-style line-of-business applications that weren’t built with Agile in mind. The cattle-not-pets thing is for when you’re operating at scale; it’s not meant to be a goal for the onesies and twosies in your datacenter. Do you think Microsoft treats their SAP servers as pets or cattle? I’m betting pets. But that doesn’t mean they have to run Azure that way, right? Different scenarios.

That’s very much the fun of IT for me. I don’t want an entire environment that’s only managed in one way. I want differences. Yes, I want that public-facing web farm to be as Agile and DevOps-y as possible. They won’t belong to a domain and they’ll be regularly torn down and spun up. But I’ll use entirely different approaches for internal assets, because I’m not a one-trick pony. Can I “do” DevOps? Sure, but I don’t want that to be the only thing on my resume just because it’s the New Shiny these days. I want a variety of capabilities in my arsenal, and I want to be able to expertly deploy them everywhere they’re best used. I get a little frustrated with IT folks who’re like, “well, I’ve learned this new thing, and now I want to use it in All The Places, and anyplace the new thing doesn’t work I’ll just hate and ignore.” It’s like when classes came out in PowerShell 5, and suddenly everyone had to write classes. That’s dumb; classes have a point and purpose in life, and they’re not the One True Thing You Must Always Use. And this is a bit of an overall human trait, I suppose; let BuzzFeed run a story on how a glass of wine a day is good for you and suddenly everyone’s guzzling a bottle for breakfast, lunch, and dinner.

DevOps has a point and a place; it is not the only technique we need.

Now, there’s another notion I need to point out: there are characteristics of DevOps that we should be using pretty much everywhere, even if we’re not “doing” DevOps. Automation, for example, is a good thing in and of itself; we’ve over 100 years of industrial progress to prove it. Automation is, in a broad sense, the way economies grow. It’s beneficial.

Being able to treat IT assets more like cattle and less like pets is beneficial even if you’re doing aiming for DevOps. People who manually manage IP addresses, for example, are a blight on the Earth (and persist in not understanding why IPv6 is a thing, and it isn’t about “running out of addresses” for pity’s sake). If you can’t architect a reliable, available DHCP infrastructure that just works, then you’ve probably no business in the business, if you take my meaning. People who worry about server naming conventions rather than intelligently using DNS (it’s more that just “A” records, folks) are, similarly, operating in the 1990s and should be feared. Basically, anything that a user or client application would use to access a server should be abstracted away from the server, including stuff like IPs and names. So there are lessons to take from DevOps, even if you’re not “doing DevOps.” Making it easy to rapidly rebuild key servers, either on-prem or in a cloud, is objectively a beneficial capability for disaster recovery if nothing else. But you don’t need to be “doing DevOps” in order to achieve that.

Major corporate IT has been a thing since the late 1990s, and it’s been snowballing ever since then. But the snowball has in large part moved faster than our understanding of the consequences. Companies started combating “server sprawl” when they realized their management techniques weren’t up to scale; they should have focused on fixing their management techniques instead. So now we sit in a world where, yes, we’ve a lot of pets in the datacenter. That doesn’t change quickly. I mean, look at the Windows XP point of sale system your local restaurant is running and you’ll realize that IT, for all that it’s the industry of change, don’t like change so much. So we’re always going to have the oddball system that just doesn’t fit “modern” management techniques. I’ve a friend with a Windows NT 4.0 virtual machine he still has to baby along. IT, like life, is messy, no matter how clean and consistent we’d love it to be. It’s about the journey, more than the destination.


When do I know that I’m functioning in a DevOps fashion? Or is that just a thing that happens when your job title includes the word “DevOps” in it?

It’s something that happens when you’re in an organization that needs the DevOps management approach. It’s more than automation (which you realize); it’s also stacks of tooling so that you have build pipelines, automated testing and validation, and automated deployment. You check in code, a miracle occurs, and that code is deployed – whether it’s an application or some portion of infrastructure. It’s tools like Team City, VSTS, Jenkins, and so on. It’s not a job title; it’s a way of flattening the path between a developer and the users of their code (even when that code is producing infrastructure instead of an application). DevOps is about automating the “Ops” piece so that it’s essentially invisible, and letting developers deploy on a whim. DevOps is about having the intestinal fortitude to let developers do that, too, which means not every organization can tolerate it. I’m fine with my bank, for example, being slightly less-than-Agile for their back-end systems that keep track of my money. DevOps has a purpose, and it comes with unique risks that you have to decide to embrace. If you’re in a DevOps shop, you will know it. And if you’re not, maybe you just don’t need to be, in your current organization. DevOps isn’t all things to all people.

Anyway, I hope that helps a little, and thanks so much for asking.


3 thoughts on “AMA: Am I “Doing” DevOps?

  1. luisrorta

    This answer helps a lot! Kind of brings me back to do just what makes sense and not worry too much about what it’s called. In terms of career development, I hoped to get that flashy “dev ops” title, but in the end, knowing what your business needs and where you fit in that equation is going to be a lot more important. Thanks Don for taking the time to answer that question!

  2. Pingback: AMA: Am I “Doing” DevOps? | Don Jones | Kapua

  3. Pingback: AMA: Am I “Doing” DevOps? | Don Jones | Kapua

Comments are closed