The dark side of DevOps: Forewarned is forearmed

Ideal scenarios rarely play out in real life, and DevOps is no different. Learn how implementing this software development philosophy can flop—and how to avoid disaster.

digital transformation devops primary

DevOps is an increasingly popular organizational philosophy that boosts collaboration between development and operations staff—perhaps even combining them into a single department—and prescribes constant integration and continuous delivery (CI/CD) of new code, with software features being rolled out incrementally every few days or weeks rather than unleashed as huge, monolithic updates. In theory, it makes development more nimble and cuts down on internal strife.

Of course, theory doesn't always play out in practice. We spoke to people who've helped roll out DevOps in the real world to find out the philosophy's dark side—both problems inherent to it and ways in which its implementers often fall short or screw up. We hope these cautionary tales will help you go into any rollout with your eyes open.

DevOps is more than a suite of tools

Ernest Mueller, on The Agile Admin site, defines what he describes as "DevOps tools":

Tools you’d use in the commission of these principles. In the DevOps world there’s been an explosion of tools in release (jenkins, travis, teamcity), configuration management (puppet, chef, ansible, cfengine), orchestration (zookeeper, noah, mesos), monitoring, virtualization and containerization (AWS, OpenStack, vagrant, docker) and many more. While, as with Agile, it’s incorrect to say a tool is “a DevOps tool” in the sense that it will magically bring you DevOps, there are certainly specific tools being developed with the express goal of facilitating the above principles, methods, and practices, and a holistic understanding of DevOps should incorporate this layer.

Unfortunately, treating these tools or others as a totem that will "magically bring you DevOps" is exactly what far too many shops do, without making an effort to change processes or mindsets. "Mike," who worked in the office of the CTO of a medium-sized tech company during its attempted shift to DevOps, describes this sort of "cargo cult" vision of DevOps. "I’ll blame engineer tunnel vision on this," he says, "because software engineers look at problems with software solutions. We looked at DevOps as a suite of technologies to be installed across many applications. This is so totally wrong it’s hard to pick where to start. We bought copies of The Phoenix Project for everyone that wanted one. We had ‘lunch and learn’ lessons on Ruby and Chef. We ran hackathons and actually awarded top ranks to infrastructure projects."

Mike's DevOps transition, it turned out, was riddled with failures, and he places much of the blame on this original failure to grasp even what the project he was embarking on actually entailed. "If DevOps isn’t software, what is it?" he asks. "Looking back I feel dumb for not noticing. DevOps is a culture. Changing culture is one of the hardest things an organization can do. People—and perhaps engineers in particular—are naturally defiant and don’t readily accept edicts from on high. Culture must be grown and cultivated from within by strong people managers, and strong people managers are rare in software organizations."

To continue reading this article register now

The CIO Fall digital issue is here! Learn how CIO100 award-winning organizations are reimagining products and services for a new era of customer and employee engagement.