In this interview, Coveros CEO and founder Jeff Payne explains why DevOps is changing everything. He talks about how DevOps has to be incorporated as a complete culture change, as well as the differences between good and bad DevOps implementation.
Josiah Renaudin: Today, I'm joined by Jeff Payne, the CEO and founder of Coveros and a keynote speaker at our upcoming Better Software Conference, Agile Development Conference, & DevOps Conference West. Jeff, thank you very much for joining us.
Jeff Payne: Thank you for having me.
Josiah Renaudin: No problem at all. First, could you just tell us a bit about your experience in the industry?
Jeff Payne: Sure. Coveros has been implementing DevOps solutions for quite a while—in fact, before it even really was called DevOps. Mainly because as a company that focuses on agile development and helping people transition toward agile, the automation of your builds, your tests, your deployments, your deliveries of software into environments is so critical to working in a fast, agile manner that you're really driven to doing that kind of work. We've been helping organizations through our agile solutions, but also just directly helping people build out DevOps solutions for really eight years here at Coveros.
Josiah Renaudin: Now, before we learn why DevOps changes everything, which is kind of the main topic of your keynote, can you give us your definition of the term? We hear it thrown around all the time, but what's your personal meaning of DevOps?
Jeff Payne: Yes. There are a million different definitions, and, as usual, when I speak at conferences, people are really confused about what it is because everybody talks about it so differently. To me, DevOps is fundamentally a culture shift toward collaboration and communication between everyone involved in the software development, delivery, maintenance, and support lifecycle. It's getting everybody to communicate and collaborate effectively.
The goal really is to reduce downstream errors, find bugs and errors earlier in the process where they're cheaper to fix, and replace costly manual efforts associated with setting up environments, managing environments, monitoring environments, tearing down environments, et cetera, et cetera, with as much automation as you can. There's plenty of tools out there and processes and techniques that help make DevOps efficient, but fundamentally, it's about culture, collaboration, and getting everybody to work together.
Josiah Renaudin: Like you just said, a lot of people hear the word DevOps and they're just confused about what exactly it's about. Why are organizations failing to see the grand impact DevOps has on the software development lifecycle? Have you seen different groups just assuming this is another buzzword that will fizzle out over time?
Jeff Payne: I think today people do see it. A year or two ago, not so much, but I think people today are starting to get it. The results of doing DevOps properly are so compelling, and there is some great data out there about what kind of efficiencies it can bring to your processes. It's really hard to ignore at this point. Like a lot of new technologies and new ideas, people are a bit skeptical, right?
Josiah Renaudin: Mm-hmm.
Jeff Payne: They're used to buzzwords popping up in the industry and there being a lot of hype around it. When you go to a trade show, every booth now has the word DevOps on it—same message, same tools. Now, though, they're all DevOps tools. There is a lot of hype, but I think DevOps is here for the long haul. I think that the efficiencies it brings to the overall software development lifecycle are so enormous, if you do it right, that it really makes it unlikely that it's only a passing fad.
Josiah Renaudin: Like you said, everyone's getting into DevOps, but not all DevOps implementation is created equal. What are some of the major differences between DevOps done well and DevOps done poorly?
Jeff Payne: I'm going to talk a lot about that in the keynote at Better Software. Two major points that I'll make and will elaborate on further in the keynote. The first is that, and I mentioned it a little bit earlier, is DevOps is hardcore cultural change. In order to get people to collaborate across really siloed pieces of the organization, your development teams, your test teams, your operational teams, your maintenance and support teams, customer service teams, et cetera, et cetera, it really takes a very strong change management process and a lot of mentoring and coaching to get everybody to work in a way that they're not used to working.
Same challenge we have in agile, same concept, trying to get everybody to communicate on a day-to-day basis, to do things more efficiently and keep communication flowing. Most organizations aren't doing that. They're trying to paste DevOps into the organization without changing the way the organization works and communicates. Fundamentally, that's not going to work. You've got to figure out how to get everybody working together and you've got to figure out how to align incentives and people's jobs so that they know it's their responsibility to do that. That's the first thing.
The second thing has to do with the tooling. When you're building out what we call DevOps pipelines … Those are tools that support the automation of your builds, your tests, your setup and teardown environments, your pushing of applications through that process toward production. … you have to really think it through. What we learned early on in building out DevOps solutions is it's really easy to snag a bunch of open source tools, paste them together, and start getting something that functions. Unfortunately, what you build doesn't scale, it's not very usable, and you run into all sorts of problems.
One of the things that is really important is what we call engineering your DevOps solution, and we actually have a new webinar series on this, free webinar series for people that are interested. The whole idea is how do you think through the overall design of your DevOps solution and how it's going to scale as it gets used, hopefully, across your organization? How do you reuse and build DevOps code that is maintainable and supportable? How do you address usability and user experience issues so that when people are utilizing the DevOps pipeline they know what the error messages mean, they know what the data that it produces means, et cetera, et cetera?
Then last but not least, if you're going to build DevOps capability and constantly be improving it, how do you do that in its own environment that isn't going to impact your production DevOps capability that you have, that everybody is using really 24/7? Thinking through all those kinds of things, if you don't do that, you end up with spaghetti code really quickly, and it just really doesn't work very well.
Josiah Renaudin: You're speaking of DevOps as a comprehensive culture change. Could this almost be related to agile where you're not just half-doing agile? When you're doing agile, you have to actually change your team's culture and its mentality from the ground up. Is that a fair comparison?
Jeff Payne: Yes, very fair comparison. In fact, I think I Tweeted out maybe a month or so ago that ironically, DevOps came out of agile, the same collaborative type of model, and you need automation to succeed in agile. Today, it's kind of funny, DevOps is kind of driving agile. We're seeing a lot more people coming to us because they're trying to figure out how to tackle DevOps, and once they get involved in that, what they realize is you really can't tackle it unless you're doing things in a fundamentally different way, building your application in very short increments so you can continuously integrate, automating your tests at all levels so that you can regression test and find bugs during the whole process, et cetera, et cetera, et cetera. They are, to me, intimately tied. It's funny, though, that DevOps really seems to be driving now the move to agile instead of the other way around.
Josiah Renaudin: I don't want to show all of your cards, but can you just give a few tips on how to take advantage of DevOps? What can a single member of a team do to make use of it and empower the entire group?
Jeff Payne: Yeah. The first piece of advice, like almost anything, is you should start simple. If you're already doing agile and you have collaborative teams that are working together, at least developers and testers in your sprints, invite the maintenance and ops people into your stand-ups. Try to get the people that are going to be responsible for maintaining and supporting your applications and that probably own some of the environments that you need to test within, get them into the process so that you can communicate your challenges and needs, they can communicate their side of the picture because there's always pros and cons.
I will talk in the keynote about the tension between what developers and testers are trying to accomplish and what maintenance and support organizations are trying to accomplish. Start breaking down those walls and getting everybody to talk together.
Second is if you're a developer, you should be pushing hard to automate your builds and your own unit tests as a way to start putting that process in play. It's pretty easy to get going as a developer. As a tester, just start doing a better job of automating your tests and bothering the people who maintain your continuous integration environments to start putting more tests into that process so you can start checking new functionality as it comes out against existing functionality so you find problems quicker. Real simple ways to get going, really based upon what you're already doing to hopefully move along the process of getting more of this technology automated and get more people talking to each other.
Josiah Renaudin: Beyond assisting the team, how can someone effectively advance his or her own career through the correct use of DevOps?
Jeff Payne: Sure. Back to my two major points, the first being around DevOps being about communication and collaboration. No more is it acceptable for people, regardless of their position in the software development process, to sit in a cube with their headphones on and never talk to anybody. In agile, we don't use documentation to communicate and collaborate, we talk to each other. Whether it's stand-ups or walking down the hall or whether you're collocated, distributed, you've got to get out of your seat and talk to people. Focusing on communication skills and being able to facilitate and collaborate with people is critical in this new world. Call it agile, call it DevOps, et cetera, et cetera.
In terms of the technology side, DevOps is all about automation from the technology perspective, so you've got to learn how to do some automation. I know testers hate to hear that sometimes. Even just script, whether it's shell script or Ruby code or whatever it is you're doing will take you a long way toward being productive in this environment and give you some skills that you can utilize to advance your career. Learn Jenkins, which is a free technology that really often orchestrates your DevOps pipeline and all the tools and how they work together. Learn how to use it, learn how to integrate tests into it. Do those kinds of things and you'll start to become a guru in DevOps, and that will take you pretty far.
Josiah Renaudin: Now more than anything, what message do you want to leave with your audience in Las Vegas?
Jeff Payne: Yeah, a couple of things. First of all, don't let tools race ahead of cultural change. As I mentioned earlier, if you just focus on the tooling aspects of DevOps, you're going to get spaghetti code set up and you're going to get code set up in an environment where you haven't really changed the way people collaborate and work together and you're going to see a lot of slowdown in that process. Get the training and help you need when you need it.
Make sure your executives understand that DevOps is change and that it's going to take time. It's not going to happen overnight. One of the good and bads about DevOps is you can quickly set up a tool chain and show some pretty neat stuff in a demo, and it gets people pretty excited and they want you to immediately deploy it into production and "ship it." The blessing is that it's something you can demonstrate and show value really quickly, so that gets people behind it. The curse is that that doesn't necessarily mean that is production-ready capability.
Josiah Renaudin: All right. Thank you very much, Jeff. I appreciate you talking with us today. I'm looking forward to hearing more about the significance of DevOps at your upcoming keynote.
Jeff Payne: Thank you very much for the time.
Jeffery Payne is CEO and founder of Coveros Inc., a software company that builds secure software applications using agile methods. Since its inception in 2008, Coveros has become a market leader in secure agile principles and was recognized by Inc. magazine as one of the fastest growing private US companies. Prior to founding Coveros, Jeffery was chairman of the board, CEO, and cofounder of Cigital, Inc., a market leader in software security consulting. Jeffery has published more than thirty papers on software development and testing, and testified before Congress on issues of national importance, including intellectual property rights, cyber terrorism, and software quality. Follow Jeffery on Twitter @jefferyepayne.
User Comments
OMG. Finally someone tells it like it is. Thank you Jeff.
Jeff is right that one can easily end up with unmaintainable code for one's infrastructure. Dynamic languages? That is the worst choice, but we are stuck with that for now because all the tools are written in dynamic languages. And the worst thing you can do is put some really smart "gurus" in charge of creating your "devops system" because they will rapidly create a mountain of code that no one else can use, understand, or maintain: thus, you have an immediate key person dependency and bottleneck, and your devops framework will come crashing down after a year or two.
The right way to approach devops: As Jeff says, include ops people early. They probably will not come to your standups, but they might call in. Definitely invite them to your release planning!!!! That is the place to start: when you plan your development pipeline, testing, and deployment. And have automation engineers in the room to advise you on what can be automated. Another piece of advice: keep it simple, and use the tools are they are: don't create a home-grown framework unless you are prepared to go the full distance and turn it into a robust supported product. The advantage of today's devops tools is that programmers can google them when they get stuck and find an answer instantly: if you create your own framework, you take that away.
Excellent overview, Josiah! Many thanks for addressing the topic with such clear and to-the-point questions. If people would like to learn more about the Engineer Your DevOps Webinar series Jeff mentions in the interview, they should register for the next one upcoming June 17 http://ow.ly/Nrhec and check here for more dates http://ow.ly/NrhhG
Thanks Cliff and Elinor! There's soooo much confusion out there about DevOps and what it means. Glad to try and help people weed through the hype. If anyone is in Vegas the week of June 7th for the Better Software conference, track me down! I'll be there Sun - Wed. Our free DevOps webinar on June 17th should be a good one too. Check it out at the link Elinor provided.