Achieving DevOps—a continuous, collaborative product delivery cycle that incorporates software development and IT operations equally—is an elusive goal for many enterprises. Even after agile software development practices have revolutionized teams, the fundamental motivational mismatch between developers and sysadmins often persists. Development is feature-driven. Operations is stability-driven.
Netflix, Google or Facebook aside, how do real-world enterprises get these two groups to collaborate at the symbiotic level advocated by DevOps? We spoke with two evangelists for Red Hat: Markus Eisele, a developer advocate based in Germany, near Munich, and Burr Sutter, product management director for developer products based in Raleigh, NC, to get their perspectives on how enterprise DevOps can best gain traction.
SD Times: From your vantage point as an ISV, what is the most common mistake in trying to achieve DevOps?
Sutter: The No. 1 mistake I see IT organizations, shops and developers make is often they’re looking for a tool to come in and solve their problems. There are tools that help, but in general it’s about cultural change, workflow and process change.
Eisele: Enterprises in general don’t actually see what it means to do DevOps. To them it’s a solvable problem by tool. We have seen independent software development teams and internal IT organizations working together in waterfall-driven processes for years. When people jumped into agile, they said, “Let’s see if we can get the stakeholders closer to each other,” but that never included operations. The whole problem goes all the way up the organizational chain. Getting those cross-business-unit methodologies to work together is not solvable by a tool. And when vendors say, “We are going to sell you containers and microservices so you can achieve Continuous Delivery,” the part they don’t mention is the cultural change.
SD Times: John Willis used the acronym CAMS, for culture, automation, measurement and sharing, to define DevOps. The automation practices rely on tools that are increasingly common for Continuous Integration and Continuous Delivery. What’s wrong with getting the automation going and calling it a day?
Sutter: Your automation is a set of tools: Jenkins, Gerrit, GitHub. They form an automation chain. But the challenge is, they can’t make the culture change. As Willis said, “People and process first. If you don’t have culture, all automation attempts will be fruitless.” The key word you hear in the DevOps space is “empathy.” You have to be able to collaborate well together.
In the average IT shop, your code goes to production every nine months. The code you create has zero value until it goes into production. More importantly, you as a developer can actually learn things once your code goes into production. Many joke that “Our end-users are our testers.” The goal is to make enterprise software development get things into to production faster. Maybe it’s a month, maybe more, maybe less. It’s about lowering that interval to get feedback.