Accenture's Keith Pleas and Stas Zvinyatskovsky Say a DevOps Transformation is Continuous and Never Done

Brian Dawson: Hello. This is Brian Dawson. I'm guest hosting DevOps Radio, live from Jenkins World. Here at Jenkins World, we have a number of fantastic attendees. I'm lucky enough to get two of them here with me for a DevOps Radio segment today. I have Keith Pleas and I have Stas. Stas, can you take the opportunity to introduce yourself for me?

Stas Zvinyatskovsky: Of course. My name is Stas Zvinyatskovsky. I lead modern software engineering for Accenture, and that involves – so we're helping companies to adopt modern software engineering practices. So that involves things like organization, operating models, roles and responsibilities, technical practices, architecture, development practices, as well as processes, so Agile, DevOps. 

Brian: Awesome. Thank you. And Keith you and Stas work together. Can you tell me a bit about your background and what you're doing?

Keith: We do. In modern engineering, DevOps is certainly the on ramp to that. I work in our DevOps practice and we provide DevOps services to a number of Accenture teams. So we have a platform, the Accenture DevOps platform. There's even an acronym, like there is for everything, and it's based on actually CloudBees Jenkins. So that's one of the things that brings us here. Then I'm also the DevSecOps track chair for this event. So I've been working on the programming side of that as well. I don't know. That's one of the interesting themes. I mean something that we're working on pretty heavily inside of Accenture because that's what our clients want, and I see tremendous interest from the folks here as well.

Brian: All right, awesome. Thank you and welcome. I appreciate you guys taking the time. Before we really dive in, I'd like to hear a little bit more. Maybe I'll start with you, Stas. What has your experience at the show been so far?

Stas: It's been great. I've been coming to Jenkins World, now DevOps World, since 2012.

Brian: Okay. Wow. Since the first one, right?

Stas: Actually, I think it was the second or third one, down in Palo Alto. It's been getting, bigger, grander. I always enjoy coming here. I get to talk to a lot of people across industries, various vendors as well and meet up and catch up with old friends as well.

Brian: Awesome. So, Keith, I think this year's conference theme is transform. How do you define a DevOps transformation?

Keith: Well that's that's an interesting question.

Brian: That's a big one.

Keith: But before one does that, I think you have to define what is DevOps.

Brian: There you go. Let's start.

Keith: We could blow the entire time on that. The sweet spot of it is probably continuous delivery. You can see it has CI in there and so on, but it's continuous delivery of software, and continuous implies automation. No one person can make decisions fast enough to be continuous.

Brian: Right.

Keith: So that's what it is about to me is automation and layering some of the additional capabilities. Once you build an automation engine, then you can add to it, and the most logical thing to add to it is security. That's where we're seeing a lot of interest is trying to embed security not only in DevOps, but through the entire modern engineering process.

Brian: That's interesting that you say that. Do you find, going back to the word transform that once you kind of get beyond just traditional development and lifecycle automation, and you start to involve what would be traditional security practices, that does start to force a transformation of the way the organization operates? Keith: It does. Now one of my challenges with using a transformation is that organizations typically like to announce it. That's a good one. They name people to run it, and then they want to be done and they want to be done when they said they're gonna be done, and none of this has really got it done. It's building the capability to add new capabilities continuously.

Brian: Continuously. I love that.

Keith: So the "done" doesn't fit. Another one organizations have been working on are Agile transformations. In fact, most of them have done several of those.

Brian: And many of them still do it.

Keith: So don't waste a transformation. It's certainly a good opportunity to use it as an initiative, to focus people around the practices and the values and so on, but it is really, I guess, unfortunate if it's a checklist and you hit done and walk off into the sunset.

Stas: Going back to the definition of transformation, by definition, it's a change in substance of something. I think it captures what companies have to go through in order to achieve division of DevOps.

Brian: Right.

Stas: Companies ultimately, the reason why they're talking about Agile transformation, DevOps transformation is because they want the speed, the productivity, the quality that cloud native companies are experiencing.

Brian: Right.

Stas: Right. And their current processes, their current operating models do not allow for that. So for them to achieve that vision, they have to change the operating model, the architecture. They need to change processes, practices. Their entire world is changing. People that have had a lot of success implementing the old processes for decades are finding that those processes have run their course.

Brian: Right.

Stas: So they have to fundamentally transform how they do things, and that involves not just automating software delivery. It involves enablement of people. People need to be up-skilled, re-skilled. It involves changing of how people cooperate with each other, their organization, their daily experience, a set of values, normative practices. Everything is changing.

Brian: Right.

Keith: And there's one that we haven't even mentioned yet, and that's the business. We've been talking about this as an engineering problem and so on, but all of this is done to support the business. If the business is not able to take new features and take new change, is resistant to that you're wasting your time. I mean you're just gonna piss them off, giving them stuff that they can't use. They need it to be the same because of how their people work and so on.

Stas: The best transformation stories are with companies where engineering and business work closely together.

Brian: Right.

Stas: If you orient everything towards business success, things magically start to fall in place.

Keith: Well, the business, they have the money to pay to for this. So you want the business pulling the change instead of engineering, trying to push change on the business.

Brian: Absolutely. I think we see a lot of cases and I think we are seeing sort of business change, where we are seeing business hear about increased speed competitive advantage. I personally have started to see the demand for change coming from other areas in the C-suite, other than the CIO, for instance, and engineering sort of reaching that tipping point dev, operations, QA, the IT portion of the organization I think finally getting to what I would call that tipping point, where we can confidently react and respond to that request from the business. I'd like to run this by. I think another thing about the transformation and why I think it was important for CloudBees to post pictures of proven transformers around the conference, et cetera, is I think it's important, to a point that you made earlier, Keith and Stas. You said in a different way, to signal that a DevOps transformation is more than just development and operations. I like to say it goes from concept to customer, which means it won't be successful, I think like you said, unless you bring the business into it. Any thoughts or comments on that?

Stas: Absolutely. I think businesses in many ways are driven towards this by the disruption that is happening in the marketplace. There's a lot of reasons for this disruption from technological capabilities that have been developed to demarcation of technology and access to technology to price of technology. So there are many enablers that enable disruption, either in business practices or in pricing disruption.

Brian: Right.

Stas: As a result, companies are craving the ability to move faster, to take advantage of market opportunities, to fight off market challenges. That ultimately brings us to technical ability to execute fast.

Brian: I'd actually like to ask you. Do you want to chime in on that, Keith? Go ahead, please.

Keith: I do. We've used homogenous terms like the enterprise and the company, but it's not. It's a collection of teams and business units and so on. So that's another one with starting with a smaller effort, a more pointed effort, again, one where the business is asking for it more and learning from that. So that's another one. There is no – like I had no solid definition of DevOps, no corporation's DevOps or the way they build software is the same as ever other's. So they need to build their own. It's not a cookie cutter recipe. You've got to learn what works within your organization and then scale that. You wouldn't want to try and do that with, like, running a pilot with ten teams simultaneously. All you're gonna learn is that's not gonna work.

Brian: And people are different. Actually, I like the way you brought that up because we always talk about DevOps is about culture.

Keith: Yeah.

Brian: Continuous delivery is really – is the more tangible aspect of implementing or supporting a DevOps culture. But, yeah, I agree with you, Keith. Culture is something that is unique to each organization, each entity, each environment. So you can't assume that you can just go borrow Netflix' culture plug it into your organization and make it work.

Keith: Our clients say that. They say, "We want to be like Netflix," and I say, "Really? You want to throw away 80 to 90 percent of what you make," and they go, "Oh my god. No, we can't do that." So you don't really want it. You want some of that and that's great. So what I like to talk about is how do we speed the diffusion of the innovation that's going on into the enterprise. Again, the enterprise has multiple units. It has systems that are purchased and used elsewhere, PaaS and SaaS systems, but they want some DevOps magic. They want to be able to deliver new features quicker and so on. It's not that everything is just, you know a cloud native HTML app, but that's certainly the sweet spot and that's driving a lot of the innovation. But we want to use that to help improve our capabilities.

Brian: Across the organization.

Keith: Absolutely.

Brian: Mainframe guys want to go fast, too, right?

Stas: Everybody wants to go fast. Keith: Yes, they do. Surprisingly, yes.

Brian: So on that point, that's actually good. I'll start directing this at you, Keith, and then, Stas, I'd love to hear you chime in. As teams move faster and as organizations seek to move faster and in particular in mature organizations, large enterprises, risk becomes more of an issue. So it's one thing to have a small greenfield mobile team saying, "We're gonna shift features once a day every day" but as we start to scale that across a mature enterprise with a range of applications, all of a sudden there's more risk introduced, and I would assume that security and governance become more of an issue. So I'll start with asking you, Keith. What do these organizations that are looking to move faster need to do in consideration of security and governance in pursuing DevOps?

Keith: Well, again it kind of starts with there's multiple layers here. There are the public-facing things like websites that are not even confidential. Then there's confidential systems. Then there's secure systems and so on. You want to get your system in place before you try the most complex, the most advanced version of it. That's one. Number two is you're absolutely right. As you expose more and more of the organization to the outside world, the organization has got tremendous value that's built up over the years, whether it's customer, the money, the IP and so on, and yes, they become naturally resistant to losing that.

Brian: Right.

Keith: So part of it is basically separating what needs judgment from what can be done in an automated fashion. That's where the DevSecOps stuff comes into play. It doesn't mean lay off your security team.

Brian: Right.

Keith: The security team is still there, but we're gonna do the heavy lifting of testing stuff early, giving the right guidance to the architecture team, so that it gets baked into the design, so that coding standards are followed and we test it and so on so that the security team, when something happens, they can focus on...

Brian: On the high value.

Keith: Right.

Brian: Stuff that needs expertise, human judgment.

Keith: It also has the most liability, right. You want them focused on your major systems of record, not the website.

Brian: Good point. Actually, Stas, I'm gonna ask you to continue that thought and ask what do organizations need to do to ensure that security and compliance isn't treated as an afterthought? 

Stas: Yeah. You can kind of play this mental game. How long does it take or what does it take to deploy a Hello World program to production. Technically, you can just go to production, type it up right there, save it, and it's there. And maybe if you're a startup that's one week old, that's what you do. But if you're an established company with an established customer base, with established revenue, maybe you're a public company or you're a regulated company we cannot tolerate that kind of behavior. So you start establishing sort of patterns and practices. You mentioned governance, and you start codifying them and enforcing them with the pipeline. That's where all of your security compliance will go into as well. Then you start applying some of these, almost using theory of constraints. An auditor shows up. You're a public company, a Sarbanes-Oxley auditor shows up. They will ask you, "On July 25, you deployed something to production. Tell us who deployed it and what exactly was deployed." And all of these requirements ultimately translate into processes that you need to codify into your pipeline.

Keith: And you need to guarantee that those processes happen.

Stas: Exactly.

Brian: And are you guys seeing because of course you guys are spending a bunch of time. You're supporting guys that are interacting with real world enterprises implementing DevOps every day, right?

Stas: That's what we do.

Brian: Are you seeing a shift in the acknowledgement of the fact that DevOps now, at this level of maturity, has to consider security and governance codified and automated in the pipeline? What's the state of the landscape that you guys are seeing out there right now?

Stas: In terms of the mindset that understanding has been there for a number of years, from the development side. What we're seeing, and it started happening recently, is that traditional approaches to security are starting to break down as companies are moving faster, as development is moving faster, and as companies are moving to the cloud. The traditional approach to security has been very much focused on the perimeter. If I secure the perimeter, it doesn't matter what happens on the inside. Now we're seeing the perimeter disappear as companies move to the cloud, so security shows up and says, "Okay. We need to ensure the application at its core. So for a lot of security folks, it's a new set of skills. It's a new set of challenges, and they need to be educated. They need to be brought onboard. So there's a lot of conversations happening. Really, it started this year, a lot of collaboration between development and security, to figure out what are those best practices. At the same time, we have a lot of best practices developed already, the tooling especially. There's so many tools in the security world to help you make your application a lot more secure than it used to be. You can secure it from the coding practice throughout the lifecycles, out into the operations.

Brian: Okay. So would it be fair to say that – so to repeat, the understanding has been there. The move to cloud native and the increased risk exposure with cloud native has kind of necessitated that dev and security work together more collaboratively.

Stas: Absolutely.

Brian: And at the same time, we've seen tools the appropriate tools come to maturity. Is that fair, Keith?

Keith: It is. I'm trying to think about it. I was a little worried when you said an explosion of secure something, but I think that's fair. It is a trust boundary. We have things that were inside the trust boundary, and now when they're in the public space and they are factored into something small, this is a micro-service it's outside. It's in the wild. So yeah, that changes the nature of how you secure stuff. Now you secure the message coming in and out as well. So there was a tremendous amount of focus at the show on Kubernetes, for example.

Brian: I was gonna ask you about that, yeah.

Keith: I can talk about it in architectural terms, but in real terms we have containers and they have their orchestration engines, and then they have their systems that build them. Now, we typically now have almost a little security and logging container that goes along with the micro-services. Well, they're refactoring that. So as all of that is evolving, then tools to help secure this container ecosystem are also evolving. One of the curious things, though, about security is it's not open source. So here we are at Jenkins World, where Jenkins is a large open source project. Most security-related stuff, I mean maybe some of the cryptographic algorithms are in the wild, but most of it is proprietary.

Brian: That's interesting. So how about OWASP and ZAP and those tools? Is it that the tooling –? We're seeing some open source tooling, but the records and the knowledge that's been codified in that tooling didn't stay proprietary?

Keith: Well, also, that's open Web. This is not highly secured systems.

Brian: Right. You're talking about kind of the back flame security.

Keith: Right. So if you had a tiered system. These are presentation layer things.That's one, but the container security is another whole level past that.

Brian: So are there specific issues that arise when you're running mission critical cloud native apps that further drive this need for container security?

Keith: Well, heck yes. First of all, these mission critical apps have typically taken multiple years to develop. They exist in the wild for ten years. I mean a long time. But the systems that they're running on are evolving daily, weekly. Both Amazon and Azure have announced native Kubernetes services this year. Is it announced? Is it in preproduction? Is it live? Corporations like to wait for things to be official and launched and supported and so on, but the world is moving pretty fast.

Brian: The world does not wait.

Keith: No, the world does not wait for that.

Brian: So you in particular, Keith, as you said earlier moderating...the industry panel on container security.

Keith: Yeah.

Brian: Which overall is part of your acting as a security track chair here at Jenkins World, right.

Keith: Right.

Brian: Are there any key takeaways, either from that panel or from the selection of talks that are in the security track here at Jenkins World that you want to share with our audience?

Keith: Well, yeah. Thanks for asking. I have a long history of being a track chair and helping put technical content together. I like to typically start with an on ramp that's – I don't want to say remedial, but get everybody up to speed and kind of build on it. So, you know, there is what is DevSecOps, which we pretty much have to have a talk like that. Then what does it mean, and how do I industrialize it? How do I...? We haven't even talked about education and so on. What level do..? There's a make/buy analysis. What do I get good at and what do I buy? Then we have, as I mentioned, the types of apps that are changing. Then that builds to the most complex case, which is continuous security in containers. This is really an emerging thing. There are several vendors that are here, a couple of them on the panel. We have an analyst on the panel as well. I would say whatever we say specifically about what to do today, there's a good chance that I'll come back next year and say, "Well, we've evolved."

Keith: That's right.

Brian: So real quick and before I go over to you, Stas, can you actually share the names of a couple of the vendors that are on the panel, container security vendors that people should be keeping an eye on?

Keith: I'm not sure who's exactly a sponsor here.

Brian: We're not worried about it.

Keith: We're not worried about that. Well, some of the major players in this space, of course Red Hat with OpenShift has a security team as well. Twistlock is one of the better known in this space.

Brian: That's really an emerging name in container security.

Keith: That's right. There's another company. It's very interesting. It was funded by Microsoft. It's a company called Aqua.

Brian: I didn't know they were funded by Microsoft.

Keith: Yes. Follow the money.

Brian: And they have an Ansible history, right? Keith: Who does? Brian: Aqua. Somewhere in their lineage, I believe that they have...

Keith: Ansible?

Brian: Yes.

Keith: That's new to me.

Brian: All right. I could be wrong. We'll find out and figure that out.

Keith: It could be strange but true or not true. Ansible of course now is Red Hat. And there is one other sponsor that's on the panel, and I'd love to figure out which company that is.

Brian: Okay. With that, I'm getting the signal that we're starting to march towards time. I'd like to start wrapping up with you, Stas. If there is one thing that everybody that's embarking on a DevOps transformation should remember, your key piece of advice that you can give our attendees embarking on a transformation, what would that be?

Stas: DevOps transformations are difficult, but many companies have succeeded. If you can learn from the experience of others, you can drastically shorten the amount of time that it takes to transform and it will reduce your overall cost and overall pain going through the transformation.

Brian: Okay.

Stas: But the life on the other side of the transformation is beautiful.

Brian: Is beautiful.

Keith: So the one key thing is to encourage experimentation. Like we said with the Netflix example, are you really encouraging it? People need to learn. They need to try new things, and if they can do it in a safe place, but again, many organizations they say, "This is it. All eyes are on you." I ran across one company that they picked a mission critical application for their first DevOps pipeline and their first cloud experience.

Brian: And how did they end up?

Keith: It gets worse. They had a go-live deadline. They assigned the team to it.

Brian: Right.

Keith: They gave them the tools that somebody had said that they should use. I mean there's no buy-in from this team.

Brian: Right.

Keith: Not well.

Brian: It did not go well. So that is a great point to end on. That's a perfect example of what we've been talking about and recognizing that we call not DevOps, but DevOops.

Keith: We saw that. That was good.

Brian: We need to learn what not to do.

Keith: Right.

Brian: Well, Keith, Stas, thank you guys very much.

Stas: Thank you so much.

Brian: I appreciate you taking the time, and giving us the insights.

Keith: You bet. Thanks for having us.

Brian: I hope you enjoy the rest of Jenkins World.

Keith: Absolutely. Thank you.

Stas: Thank you.

Brian: Thank you.

Announcer: Like what you've heard today? Don't miss out on our next episode. Subscribe to DevOps Radio on iTunes or visit our website at CloudBees.com. For more updates on DevOps Radio and industry buzz, follow CloudBees on Twitter, Facebook, and LinkedIn.