Devops – the challenges go deep
Last week, one of my team members forwarded me a link to this blog by Savio Rodrigues, entitled Why devops is no silver bullet for developers. It’s a well written blog and Savio makes some good points, namely that environments that the Devops team hopes to build on need to be standardized. He comes so close to hitting some important topics right on the head, and then just misses the mark slightly, IMHO.
Savio nails it when he points out
“One thing I’ve come to understand is that these two groups tend to think differently, even if they are using the same words and nodding in agreement.”
Bingo Savio. He goes on to say,
“It’s no surprise developers want to adopt tools and processes that allow them to become more efficient in delivering new applications and continuous updates to existing applications. Today, these two tasks are hindered to a degree by the operations teams that are responsible for production environments”
But then, he misses an opportunity to drive the point home and starts a discussion about standards. I agree standards are important, but what needs to be reckoned with are the very different culture, goals, and reward systems between the two disciplines of Engineering/Development and IT/Operations.
How are these teams measured and rewarded? The answers to these questions tell you many things about the team’s culture. A Development team is typically measured and rewarded by amount of innovation, quality of their deliverables, timeliness of delivery, and responsiveness to market. An IT team is measured and rewarded typically by uptime, stability, security, and control. (Note rewarded can mean “not punished due to failure” as well as more expected definitions of reward).
All of the above seem like good things! We want uptime, innovation, quality, stability, etc! Right? I envision one could draw a Venn diagram for the Dev culture and the IT culture and there would be overlap, but there would be just as much outside the intersection. Innovation is often at odds with stability. Responsiveness to market can be at odds with uptime, etc.
We’ve had the good fortune of having a few opportunities to implement a new Devops model. When everyone is rowing together the boat certainly moves faster in the desired direction. But it is difficult. It requires continual investment in the Devops team because at the core, these two very different cultures aren’t going away anytime soon. Savio sees it too when he says, “This isn’t a technical issue. It’s a cultural issue.” I’d suggest we spend as much time looking at the measurements and rewards as we do thinking about standardizing platforms.