Operations and administrations teams, as the Puppet Labs survey shows, are also drawn to the automation of manual tasks they must do today, some of which result in delays for developers as they wait on the operations team to provision new resources or promote applications into production.
Here's the rub: Although both sides of the devops coin value automation, neither is explicitly calling out the fact that you can't automate without standardization. Well, maybe "can't" is too strong a word. In IT, we can do pretty much anything with enough elbow grease.
But ask yourself: Could you automate the provisioning of a development environment or the deployment of a middleware stack without standardizing what exactly is being automated? No, not really. Operations teams understand this; it's why operations teams promote enterprisewide standards. In most cases, these standards -- whether for operating systems, hypervisors, databases, or application servers -- allow for some limited degree of variability. For example, many IT shops support both Linux and Windows, but if you want Solaris, sorry, you're outside the corporate standard.
This is the environment that developers are working in today: You can select among enterprisewide standards, but not go outside them. And yet, this is the exact environment that frustrates developers. Sometimes, the corporate standard doesn't exactly fit the developer's skills or interests or the project's needs. Hearing "tough luck, champ" is what's driving developers toward devops. But developers automating IT stacks that don't fit into the corporate standard won't help bridge the gap between development and operations.
What's needed is a joint agreement between development and operations on the acceptable environments that make up the corporate standard, which are in turn automated.
This isn't a technical issue. It's a cultural issue. Before your teams push forward a devops initiative, get them beyond the buzzwords and into the nitty-gritty around corporate standards, degrees of variability, and how -- or even if -- to allow developers to experiment outside the corporate standard. If you don't, you'll have developers and operations expecting different outcomes while using similar words.
I should state: "The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions.
This article, "Why devops is no silver bullet for developers," was originally published at InfoWorld.com. Read more of Savio Rodrigues's Open Sources blog and follow the latest developments in open source at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.