📚 Tutorial: Tips for Better Governance - Techstrong TV - DevOps.com

David Williams, VP of Porduct Strategy at Quali, and Charlene discuss David’s top tips to better governance in DevOps. The video is below followed by a transcript of the conversation.

Charlene O’Hanlon: Hey, everybody. Welcome back to Techstrong TV. I’m Charlene O’Hanlon, and I’m here now with David Williams, who is the VP of product strategy over at Quali. David, thank you so much for joining me. Good to see you.

David Williams: It’s good to see you, too, Charlene. It’s good to be here.

O’Hanlon: Excellent, excellent. So, lots of stuff going on in the world of DevOps these days, but one of the things that we have been hearing a lot more noise about is governance in DevOps. And especially with just the insane amount of automation that’s going on to help kind of speed up the processes, obviously, it can be pretty easy for things to kinda go off the rails. So I wanna kinda get a sense from you as to what you see happening in the space with respect to governance in DevOps, and how we can kind of maybe move away from the herding cats mindset when it comes to governance.

Williams: Yeah. It’s been a journey on DevOps. DevOps, when it was introduced many, many years ago as a concept immediately aligned itself with Agile, so it became only the ability to get things out as continuously as possible, and also as fast as possible. And so what happened is that at that time, things were very much managed. It was small teams doing lots of work. As enterprises started kicking in, with DevOps become a serious strategic way of actually delivering applications to their consumers, the amount of people got involved grew.

The amount of teams that were involved grew. Even though the DevOps philosophy was small teams, fast moving, application componentry going out into the ether as fast as possible, it stopped being that quite a while ago, and started becoming much more mainstream. So unfortunately, DevOps grew up a lot, and one of the things that became an issue was governance. And governance from that perspective wasn’t really just about security – y’know, SOC 2 compliance, and making sure that your secrets are held and managed efficiently across the pipeline –

but it was also around, how do you understand what people are doing? And what is the interaction that they’re having? And why are they having that interaction? And basically it’s a fragmentation challenge, more than anything else. DevOps pipelines are fragmented, and so how do you get control without inhibiting innovation? And how do you get visibility, having lots of teams that wanna innovate in their own areas, but not necessarily give you that full end to end? So that’s the challenge that has emerged.

And I think it’s going to continue to do that for quite a while to come, because the applications are getting bigger and more contention-based in regards to infrastructure sharing. So governance is gonna be the thing.

O’Hanlon: It’s interesting, because I think of it a lot like a company itself growing out there. When you have two or three people working in a company, it can be very difficult to get a lot of achieved without everybody kinda going all in. But as a company grows, you’ve got more people who are doing the work, but maybe they’re not necessarily talking to each other, and not everybody has all the information they need. So you kind of have to kinda build a technology, or at least a process, around being able to get the information out and helping everybody be on the same page.

And it kinda sounds like the same thing is happening in the DevOps space with respect to just having a greater understanding. Not just an understanding of the process, but just, I guess, a better way of enabling the process from an understanding and a communication perspective – as well as just making sure that all the right things are getting done at the right time. So what do you guys propose? What do you see that you believe could make a real difference?

Williams: You used two words that always make me smile when I talk DevOps. I used to be an analyst, talking to a lot of DevOps practitioners, and the two words that I used to run for the hills were “process;” y’know, that was one thing. And so they wanted collaboration, but they wanted to be able to collaborate without being governed in any way. So I think that that process word is one, and anything to do with “abstraction.” So abstraction’s not a good thing. It takes you away from the core.

So what I’m saying to you is that any solution that enables you to get greater control on governance and understanding has got to be able to do it without impeding people’s ability to do their jobs. And it’s gotta be something that is subsumed within their normal breathing in and out. It can’t be something that’s another job to do. That defeats the whole point of, anything that’s to do with lean practice is about removing stuff. We’re the software industry, so the way that we make things less complex is by adding something, y’know; that’s the normal inclination.

I think DevOps, when you actually use it, whatever you add into the mix has got to be subsumed within your normal day-to-day activities. So it can’t be yet another thing to do. For example, security has gotta be there, but not intrusive. Why I came to Quali was because I’d spent a lot of time with companies where infrastructure, the ability to provision into the cloud, do all the things, was becoming a bit of a mystery. People would assume infrastructure.

So the governance around what you’re deploying and how you’re provisioning your infrastructure not only became fragmented through your pipelines – Because you plan something, and then you code it, you build it, you release it, and test it, et cetera. Each one of those is a very defined area. It might be one person; it might be many teams. But each one of those is a very specific thing you have to do. But wouldn’t it be cool if you could subsume testing into your code? Wouldn’t it be cool if you could consume compliance while you’re coding?

So you’re coding, and it’s automatically looking at configurations and modifications, and logging that appropriately without you having to add another layer. And I think the same with infrastructure. I think that the companies I’ve worked for before really didn’t know what was going on, and I worked for DevOps companies that were trying to work out, “Okay, so the infrastructure was there; now it’s gone,” or “It’s there, and it’s modified.”

Every commit that a coder does is, y’know, a point in time. “So what has happened between that commit and the next commit?” And so all these stages of infrastructure, how do you build that in? So at Quali, what we looked at is providing a method with which you can let people use infrastructure as code practices, configuration management tools. Do what you need, but it gets automatically subsumed into a model. And the model is what you rate on. That’s what applies the policies around access and et cetera.

But it should allow the coders, the release managers, the testers to do what they need, but also it provides sort of like a control plane on top that enables you to talk and be governed, but without that Big Brother type of thing looking at you. So I think that’s the magic about DevOps, is if you add something in, it’s gotta be something that doesn’t get in the way of speed. It’s gotta not provide another barrier. It’s gotta do these things. It’s a hard problem to solve, but if you approach it in a way that assumes that people are going to do things, they’re gonna break stuff –

People do that; that’s what they do. They do their own stuff. They don’t like being told what to do. So if you can provide as subliminal a level of control over infrastructure that says, “I know how you’re doing it. I’m now going to provide that same capabilities that we used in build to help the testers understand what to build.” So now you’re providing some consistency across, using the control plane. So you’re using your models, and you’re moving them across. But it subsumes what they already use, so you can add it in.

Your infrastructure stack and the way that you deploy it is implemented in the model that has policy, access control, secrets integration. And so that’s really the philosophy, is to make sure that we can provide the end-to-end capabilities, accelerate the delivery life cycle, but not impede the practitioners from what they do, but provide the business with visibility which they do not have today. So I would just follow up by saying cost isn’t a governance thing, but unless you govern it, and you understand why you’re doing something, then how do you associate a cost of the cloud, if you can’t associate it with a pipeline?

At the moment, cost is associated with instances, and you’re having to group that together. What if you could provide the model with a value while you’re doing it, the application that you’re delivering on? And if you could do that, then you’re subtly applying what they do at the practitioner level with an application, with an owner, with a cost. So that is a way that governance actually comes in with the access, the controls, without being intrusive. We can basically provide all the capabilities there, and enable the business to get better visibility control over all sorts of things, including, for the first time, cost on the end to end.

O’Hanlon: Yeah, that makes a whole lot of sense. And in my mind – please tell me if I’m wrong – but it also means that the developers don’t really have to think about, how shall I say? They don’t actually have to learn more about something that would – If they’re moving from, say, a regular kind of a developer motion into more of a DevOps motion, it doesn’t require them to kinda add on a level of expertise that they might not need otherwise. This kinda does it for them, and kind of fills in the blanks for them, and also kinda helps other organizations or other teams within the organization understand the flow a little bit better, which makes a whole lot of sense.

And I think that may be part of kinda the governance conversation as well, is if we all have a greater level of understanding about what is happening at any particular time, we can better manage it.

Williams: Yeah. I mean, secrets management, people hear a lot about that. They don’t quite know what it is when you talk to them about secrets management. I mean, something like a password or a username would be used maybe throughout a process, and it’s a shared piece of knowledge that you don’t wanna expose. So you keep that consistent throughout your environment, but keep the access controls consistent throughout whoever uses that access throughout the pipeline. One thing that we’ve learned is that DevOps isn’t a thing; it’s an interpretation of a thing.

The objective is very clear for people, but how they implement it can differ, depending on organization, application, design, et cetera. So what we also have to do is make sure that people with lesser skills – And I don’t mean lesser skills in regards to infrastructure; infrastructure can be cloud provisioned. But what if they have to manage all the networking components and the database instances, the things that aren’t inherent within a cloud-provisioning environment?

So we’ve gotta make sure that as developers of different skill levels interact with the infrastructure, we can fill the gaps for them, so they can do what they need to do, but if there’s networking, et cetera that needs to be managed, then the model should be something to give them the guardrails with which to implement that in support of the application requirements to that part of the pipeline. So it is something that we’re working on quite heavily, to make sure that we can get those guardrails in place.

O’Hanlon: That’s great. And I think about all of the things that have kind of expanded DevOps, if you will, beyond the original parameters, including the implementation of DevSecOps, and the adoption –

Williams: Yeah.

O’Hanlon: – and DevNetOps, and all of these things that have kinda piled on top of DevOps.

Williams: [Chuckling] Yeah.

O’Hanlon: It can be very, very difficult for the DevSecOps community, or the DevOps community, especially developers, to kinda have to manage all of that knowledge. So having those guardrails in place, I imagine, is going to be very well received by a lot of organizations, simply because we’re also talking about the dearth of talent in the developer community these days.

Williams: Yeah.

O’Hanlon: So anything that an organization can do to help ensure that there is a level of governance around the way their DevSecOps tools and practices and culture and everything is run, I think is a huge benefit. David, thanks very much for walking me through what you guys see happening with DevOps and governance. And hopefully this is an issue that is going to get better as we move forward. To your point, we do tend to throw technologies at problems, and hopefully this is one that will stick, if you know what I mean.

Williams: Yeah.

O’Hanlon: So thanks again for your time. I do appreciate it.

Williams: Right. Thank you, Charlene. It’s been a pleasure.

O’Hanlon: All right, everybody. Please stick around. We’ve got lots more Techstrong TV coming up, so stay tuned.