There are few names in DevOps as big as Gary Gruver. He's an experienced software executive with a knack for implementing the continuous release and deployment pipeline in large organizations. In fact, he literally wrote the book on the subject. His latest, Starting and Scaling DevOps in the Enterprise is an insightful and easy-to-read guide that breaks down the DevOps process and principles, putting them all in a context enterprises can use to gain alignment on their journey to continuous delivery.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
In the first part of our conversation, Gruver defined DevOps, explaining the challenges in transforming large organizations. Here, we tackle why starting a DevOps process is often like five blind men building an elephant -- seriously -- and how silos can suboptimize an enterprise's the transformation.
How important is leadership to a DevOps process and transformation?
Gary Gruver: In a lot of cases, you'll see a transformation where it starts grassroots, and you'll get the change. But when you really get down and start talking to those people, they'll be frustrated in their ability to drive change in their organization, because they're struggling to convince their peers and other people up in the organization to change things. And a lot of times you'll see them suboptimize the system.
So, when Agile rolled out into large enterprises, the concept of releasing code for the customer on a more frequent basis fell off, because it was hard. And that's why I think DevOps came out as a term, because that Agile principle of releasing to the customer more frequently needs to be focused on and done in these larger organizations.
Since it was hard, you saw these Agile teams do things like create a dedicated environment, sign off with the product owner, do their sprints, redefine the definition of 'done' as signed off by the business owner, and, eventually, every six to eight weeks, it's going to get handed off to the large monolithic release processes. It's difficult.
So, culturally working down that path is important. You need somebody who can look across the value chain, from the business idea to working code for the customer, and optimize that as you go off to do DevOps, instead of teams localizing their piece of it.
What you tend to get when you do the grassroots thing is when people run into roadblocks working across the value chain, they tend to grab a piece that they can control and fix and own on their own. In a lot of cases, it suboptimizes the overall system. You really need someone to be taking a broader view of the problem and ensuring everyone is working together to optimize the system, which, in my view, is the role of the leadership team.
In your book, you describe how starting the DevOps process and journey is like having five blind men build an elephant. They may have all the right parts, but it doesn't really look like or work like an elephant because none have necessary macro view. Can you elaborate on that metaphor?
Gruver: When I go into large organizations, I find everybody excited about a DevOps transformation. I go talk to the developers and they say, 'Oh yeah, I want to do DevOps.'
Really? So, you're going to make sure you have automated tests in place for all your code? You're going to make sure that any changes you make to the infrastructure is in source-control, so you can track any changes? You're going to make sure your deployments are automated? And any changes you make to deployment are automated and do that on a concurrent basis?
And they say, 'No, no I don't want to do that. That's hard. That sounds really difficult. I heard DevOps just means, like, Netflix, on your first day on the job, you get to push code to production. I want to do that.'
And I go talk to release managers and say, 'So, you want to do DevOps?'
'Yeah, I'm way excited about doing DevOps.'
Learn more about digital DevOps transformations in large scale organizations. And time is of the essence. According to Gartner, one in four businesses will fall in competitive rankings due to "digital incompetence."
And you go down that path of … So, you're going to release every day or multiple times a day in small iterations and go through that process?
'Well, no I don't want to do that. That sounds really hard. What I want is everything under source control. I want all my testing automated. I want to know exactly who changed what about the environment, who changed the deployments [and] the databases so I can manage this. Because, right now, I'm the babysitter in this organization. No, I don't want to release things more frequently. I just want everything in source control so I can easily track the changes.'
Now, you talk to the Ops people about DevOps. 'Really? So, you're no longer going to manually log into a server and make any changes? You're going to make sure any time you make a change it's to an automated script; you'll start that at a developer's box and have it work down the deployment pipeline?'
'No, I don't want to do that. I just want to have feature toggles so I can turn it off when I have a problem.'
Sometimes, you get everybody excited about doing DevOps and they go off to do what they think it is or their own individual piece of it is. What you end up with is something that doesn't enable you to release code more frequently on an ongoing basis.
So, how I talk about it is … you've got all the parts and pieces to the elephant, but it just doesn't work like the DevOps elephant you're hoping to get, and it doesn't deliver the business results you deserve.
What I do with the process maps when I got into organizations is, I use that to give everyone a common understanding of what the issues are and introduce everybody at the same time to these DevOps concepts from the front end to the back end. Then we map their processes and get everybody to agree that you're all looking at the same thing. You're all looking at data. Let's agree on what the biggest issues are. Let's go after those.
We'll do those for 30 days and figure out what we can learn. And we'll learn and adjust together and go down this path of continually improving. Not each individual piece, but the overall system all the way from the business idea to working code production.