While the DevOps movement is centered on reducing the friction between developers and operations teams and the ability for developers to deliver applications faster, neither outcome is possible without standardization. But are developers and operations teams ready to agree on standard environments?
Why developers operations teams are focused on DevOps
A recent post from Matt Asay, now at cloud vendor, Nodeable, links to a survey from Puppet Labs of seven hundred and fifty plus respondents. While DevOps is often considered a developer led movement, nearly 4 times as many operations and administrators responded to the survey as developers. Surprisingly, as Matt points out, operations teams appear to see the same potential benefits from DevOps as developers.
In the survey, Puppet Labs finds that fifty five percent of respondents ranked the automation of configuration and management tasks as the top benefit expected from the DevOps movement. Another thirteen percent, ranked this benefit in their top three benefits expected.
You can’t automate what you can’t standardize
I’ve been spending time learning more about the interaction between developers and operations teams. 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.
It’s no surprise that developers want adopt tools and processes that allow them to become more efficient in delivering net new applications and continuous updates to existing applications. Today, these two tasks are hindered, to a degree, by the operations teams who are responsible for production environments. As Matt points out in his post, developers seek automation, which, as an aside, is a reason enterprise developers have been very open to using public clouds.
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 the delays that developers experience when they’re waiting on the operations team to provision new resources or promote applications into production.
While both side 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 enterprise wide standards. In most cases, these enterprise wide standards, whether for things like operating systems, hypervisors, databases or application servers, etc., allow for some limited degree of variability. For instance, may IT shops support Linux and Windows, but if you want Solaris, sorry, you’re outside of the corporate standard.
This is the environment that developers are working in today. You can select amongst enterprise-wide standards. And yet, this is the exact environment that is frustrating 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 towards DevOps. However, 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, across development and operations, on the acceptable environments that make up the corporate standard, and 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 if or how to allow developers to experiment outside of 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.