In this interview, Anders Wallgren, the CTO of Electric Cloud, explains how to help DevOps travel from small, individual teams to the entire organization. He covers the benefits, risks, and best paths to success if you want to make your company faster and more effective.
Josiah Renaudin: Welcome back to another TechWell interview. Today I'm joined by Anders Wallgren, the CTO of Electric Cloud. We'll be speaking on scaling DevOps in the enterprise.
Anders, thank you very much for joining me today.
Anders Wallgren: My pleasure.
Josiah Renaudin: First, before we kind of get really into the context, tell us a bit about your experience in the industry.
Anders Wallgren: I've been working in the software industry for "mumble mumble years now," they say. I've worked all up and down the stack over the course of my years: UI, network stacks, native applications, web applications, back end, you name it. I think one of the interesting things is that all the companies that I've worked at, we always somehow seem to be a little bit on the bleeding edge of how to do our processes better, how do we get out of our own way and produce more software for our customers.
It's been really interesting the last few years, working with Electric Cloud and with our customers and the community in general, just to see how vastly the processes and the culture and the technology has changed over the years. It's really kind of cool to be part of that.
Josiah Renaudin: One of those changes, one of those things that I feel like I've written a lot about at this point, I keep reading a lot about, is DevOps. That's kind of the focus of this conversation today, so to kick things off: Why has DevOps started as such a development-driven movement, since ops—you know, operations—is right in the name?
Anders Wallgren: No, that's true, and I think ultimately, to succeed, it has to be something that covers both. I think part of the reason why a lot of people, myself included, kind of look at it as a ... at least initiated in dev, to a large degree, is simply because that's where agile took root first.
As organizations started to adopt agile and get better at delivering the software, at least out of the development and QA organizations, the logical next question was, "Well, how do we get it into customers' hands more quickly?" Whether that's up on a website, or burned into a chip that goes into a box that you buy on Amazon, or what have you.
I think it's a little bit natural that it started there and if you speak to pure agilists they'll happily inform you that the Agile Manifesto always talked about delivering software to customers, which is a true statement, but I think the practical applications of agile was very often felt much more on the development side of the house than the ops side of the house. I think that's part of the reason.
Josiah Renaudin: I think something that we always have to consider, different companies always have to consider when they're adopting things like ... incorporating DevOps, incorporating agile, is risk. You have to consider, "Of course there's benefits here, but what are the possible issues? What are the stumbling blocks that we can have along the way?" So what risks do teams, especially the operation teams, see in the increased velocity of incorporating agile and DevOps?
Anders Wallgren: I think the first "Oh, crap!" moment that everybody has when they start thinking about DevOps and continuous delivery and continuous deployment, and all of those kinds of things, is: "What do you mean you're going to check in code fifteen minutes into production? What if it doesn't work? What about security? What about manageability? What about accountability?" and all of those kinds of things.
I think those are very right things to worry about, and obviously, traditionally, in going forward, ops is … one of their main goals in life is to keep the lights on and money coming in. Historically that's led, I think, quite a bit to a very risk-averse culture. I think a lot of the processes that were out there before, and to a larger extent are still processed, are kind of about risk minimization or at least; I think some people would say risk minimization theater, which is: "Let's have lots of meetings, let's be very conservative, let's have lots of stamps on everything before we go forward."