Non-Developers and DevOps
The DevOps communities have a LOT of non-developers, and this post is about them. I’m talking mostly about enterprise IT engineers and architects. These people often have a specialty such as networking, security, servers, enterprise applications, virtualization, storage, automation, monitoring, etc. If you are one such specialist, you’ve probably used some DevOps tools by now, and maybe have been to a conference or two. You also might have found yourself feeling a little out-of-place at times, not really understanding or relating to a large number of the topics and tools being discussed. If so, you are not alone.
The Gap
Many of the speakers we hear from at DevOps conferences come from software companies (or occasionally large enterprise software teams) which are focused almost entirely on developer problems. They often begin their talks with “ops-related” battlefield stories which include being on call when outages occur. This is great because virtually everyone can connect with this experience to some degree. However, the connection often begins to dissolve when the speakers start talking about software-specific problems and tools which are foreign to our non-developers attendees. The problem continues in conferences which have “breakout rooms”, where it’s clear that some of the attendeeds are quietly wondering why they can’t relate to the conversation at all, even though they use the tool the group is talking about. This isn’t really groundbreaking news, but what is surprising to me is how little people talk about it.
The Reason
There’s certainly a psychological component where people don’t like to speak up about what they don’t know. However, beyond this I think the situation surrounding tools is another big part of this phenomena. There seems to be a bit of a use case see-saw among tools that are used by both developers and enterprise engineers. Most of the DevOps tools are rooted in development first. Some really smart developers tackle a very specific problem really well with a bold new technology or concept (eg. “Immutable Infrastucture” or “Containers” or a new cloud orchestration methodology). All the weight on the see-saw begins on the side of the developer use case, and eventually it gains a following in one or more developer communities. Inevitably, any obvious benefits and overlap with enterprise use cases draws enterprise attention, and the potential for enterprise revenue draws the vendor’s attention. Enterprise engineers start trying to jam the new product or concept into their environment, and the vendors do their best to expand their features and accomodate (while also clarifying and hardening their scope boundries). During this period, more weight goes over to solving enterprise problems and a product or process can become pretty flexible and robust this way. Over time, then the see-saw starts to balance out and it starts to meet the “Definition” of a DevOps tool, truly applicable to a fair number of uses cases in both realms.
Sharing Tools: Abstract Problems vs Specific Problems
I think one thing that might be helpful for companies developing DevOps tools is to think more deeply about the problems they’re “willing” to solve as early as possible. I think this is one case where it’s very important to divide your potential target market into two separate groups: 1) Enterprise Infrastructure Teams, 2) Development Teams (whether at a startup, major software company, or enterprise). While a large part of the unifying message of the DevOps movement is that these two groups share problems, it’s critical to look at the situation more closely. Indeed these two groups often share a large number of common “abstract problems” (eg: configuration management), but it turns out that they have very different “specific problems” (eg: enterprise solaris configuration management with RBAC that also integrates into service-now). The size of the differences between specific problems is another rarely-discussed challenge in DevOps.
The Confusion
In a way, the tools of developers and enterprises have essentially been dumped into one big DevOps “toolbox”. This has benefits, but makes the use cases of the individual tools less discernable for the non-developer. The maturing of these tools takes time, and the sheer number can be very hard to navigate for the average “enterprise shopper”. Most teams are forging ahead and eventually figuring out which tools they need and making them work with varying success. However, I think this situation is a near-silent, but potentially defining characteristic of the DevOps movement.
