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.
rand($thoughts); 
12.25.12 at 12:17 pm
Hey there just came upon your website from Bing after I entered in, “No DevOps without standardization « rand($thoughts);” or something similar (can’t quite remember exactly). Anyhow, I’m glad I found it simply because your content is exactly what I’m looking for (writing a college paper) and I hope you don’t
mind if I collect some information from here and I will of
course credit you as the source. Many thanks.
10.14.13 at 8:43 pm
casio 7300
09.14.14 at 10:25 am
Many who were unable to obtain financing from any other source have successfully bootstrapped their
way to business success. In personal finance, the earlier you
start the better it is, and the simpler it is than when you start at later
date. We would venture to say that the overall cost of
production varies greatly in Canada depending on which province is utilized, via labour and other geographical incentives.
Have you company evaluated by a professional, so you would
have an idea how much equity you will have to give up in exchange for a required
amount of financing.
10.02.14 at 2:54 am
If your firm is growing rapidly, highly leveraged and unable to meet bank covenants, or is you
just have curse of growing too quickly (. How do these tax credits affect the average independent, and in some cases major studio production owners.
it was saying business owners should be cheering for alternative lending sources,
because it was they took up the slack when the 2008 global meltdown happened.
they are in fact just specialized lenders that are experts in inventory and purchase orders and letters of credit.