In the buzzword-filled wasteland of enterprise technology, DevOps has to rank somewhere near the top of the hard-to-define list, right up there with “cloud” and “big data” (or its subset, “dark data.”) Describing these things is like soldering Jell-O to a motherboard.
DevOps is a different case than the others because, while it certainly has been co-opted by marketing teams everywhere, it did not start out that way. As we’ve written before, engineers trying to solve a real problem coined the term. It’s a bottom-up idea.
In our ongoing quest to help surround the question – “What is DevOps?” – we reached out to some of the luminaries leading the discussion, folks like Patrick Debois and Gene Kim – with a range of questions about DevOps. We wanted to know:
What is it? What are the biggest obstacles to implementing it? Is DevOps hype or the real thing?
Over the next few weeks, we’ll be sharing the responses we received, some of which may surprise you.
To start things off, here’s part of our conversation with Ruston Vickers, the chief DevOps architect at CA Technologies:
What’s the difference between DevOps for startups and DevOps for enterprises?
The big difference is the “Museum of Technology” you get into at a large enterprise. All of the different ways of doing things, the M&A activity that they’ve probably had over the years. All of that is the legacy that they’ve carried from being around a long time – not really a legacy but a burden. They carry huge transactional systems that they have to deal with across all technology.
Obviously, you’re going to have to adapt some of the DevOps principles … to fit within the context of that very, very different ecosystem than a startup. You have a lot more to deal with.
Do you think there’s a nexus between the size of an organization and the successful implementation of DevOps?
Well, no, I don’t. It’s almost like, ‘We don’t have a choice. We’ve got to do something different.’ The size of the organization doesn’t matter. You’ve just got to make it happen.
Now do you, from an actual, get-it-done perspective, try to maybe break off projects, and get teams working that way so you have really good examples of how to operationalize that across a large organization? Sure. That’s probably the best way to do it.
When you look at the advent of agile, it’s about breaking things up into smaller chunks anyway. If it’s a huge organization, you also maybe want to break things up to where you have these parallel changes – lots of changes, but they’re smaller changes. We’re breaking up a problem into smaller chunks to enable us to move more quickly and more efficiently.
What are the biggest management obstacles in implementing, or encouraging, a DevOps culture?
From a people management perspective this is the biggest challenge. People don’t generally like change, especially folks who are in the trenches. They’ve got their routine. They’ve got their process. They’re very comfortable with that repetition. They’re human, and that’s a human trait.
Some humans are different – they love change. So the challenge is finding a way to bring both of those types of folks along to make this change actually happen.
The second-biggest challenge is realizing you’ve got to get some different skills. So when you shake up your organization, you’re going to have to make some hard changes. And in a lot of cases, that can be difficult. It’s almost like, if you think about the gas station on the corner. Let’s all of a sudden we’re all running electric vehicles. And so there’s this person who bought a gas station and was ready to retire on that. All of a sudden he has to make a massive change – new structure, new skills. It’s a very similar thing.
Next week, we’ll have Part II of our interview with Ruston Vickers, including his thoughts on whether it’s possible for large organizations to disassemble the development and network operations silos.
This post originally appeared on servicevirtualization.com.