Is Ops the Pack Mule of DevOps?
At the recent DevOps Days Washington, DC I made the comment during the Ignite Karaoke that has stuck with me. The image on screen appeared and it was a photo of Yoda on Luke Skywalker's back in a scene from The Empire Strikes Back. The comment referenced a line from the recent Deadpool movie. "Devs are ridin' a bitches back like Yoda on Luke."
As you might expect, many laughs followed as I'm sure the majority of the attendees knew the movie references. What may have been lost was a somewhat painful truth that exists about how organizations might really be getting to DevOps Code-vana. Operations teams are the pack mules of DevOps.
The reality with DevOps is that it is intended to be a framework where both sides have considerable investment stake in the outcome. Imagine a boat where the team at the oars has Devs on one side of the boat and Ops on the other. If one side is working at a considerably higher pace than the other there is only one long term result. Traveling in a circle. Balance is required, yet I don't feel that we're seeing that represented in the industry.
I'd like to share some observations I've noted over the last 6 months as I've spent more time focused on DevOps related events that supports this assertion.
If you go to a DevOps event, it's going to be focused on the Devs. Look over the agenda and their abstracts will have a hyper focus on the efforts of the development teams and what they've achieved. What you'll see glossed over or not mentioned at all were the prerequisite efforts the operations and infrastructure teams delivered to enable the deployments. This isn't entirely surprising as most of these talks are journey talks and who really wants to hear about the mules that carried the gear over the mountain?
In case you're thinking "Here's an Ops guy whining about Ops not getting attention." In a fashion you are correct. My motivations are less selfish than you may think. The $$$ is certainly in the release of new features to customers. The reality is that this works as a result of efforts on both sides of DevOps. Right now the focus at events looks more like DEVops.
My issue here is less in the fact that Ops folks are "not getting credit", and more in that in order for DevOps to be successful the folks in Ops have to be on board. They are not receiving sufficient content at these events to help them overcome THEIR obstacles and better understand how to deliver. They are already a bit hamstrung as I'll outline next, and the community at large is not doing them any favors.
The other reason that this is a huge deal is because frankly the Ops side of the house is EXTREMELY capable of delivering services that are needed. I regularly have conversations with customers looking to evolve who have not recognized that the features and tools they already have contain significant value to their development teams. Why don't they know this? Frankly, no one has told them the pain points or not done so in a context that is relevant to how they can deliver.
This is easily remedied, but the organizers at these events need to make more of an effort to include Ops focused content. The other side effect to this, which I see often when I have an opportunity to speak, is that once the Dev focused attendees hear about the features and capabilities the ops teams can deliver it opens up new possibilities for them. That's how it is supposed to be, right?
The second major hurdle that has more focus on the Devs of DevOps is around tooling. Many sessions will outline how specific tools were implemented in order to enable the group's objectives. Those tools, more often than not, are primarily focused on the developers' needs. I have seen very little content at these events discussing the tools that are leveraged by the Ops side of the house in order to facilitate the end goals.
ProTip: Many of these tools can, and should, be leveraged on both sides of DevOps.
Again this is not entirely surprising. After all, the developers in this space have a very distinct advantage over the operations and infrastructure folks. They're developers! They can build their own tools. Traditionally the Ops side of the house has been dependent on vendors who have worked in their space to deliver tools to enable easier management and doing more with less. What they have not done is demonstrate how to enable doing things faster, with a more immutable attitude, and delivering sufficient extensibility with tool integrations to deliver the increasing demands from the Dev organization. The demands are reasonable. The ability to deliver for them remains difficult. This is one of the reasons I joined SolidFire in the first place, to help expand understanding and bridge that gap.
I'm seeing this start to shift slightly and I believe much of it has to do with the fact that many challenges that face Ops in the DevOps world have not been sufficiently addressed and articulated. The tools are starting to emerge, and vendors are starting to better understand how their products and portfolios fit into the space. Just look at EMC Code, VMware Code, and NetApp's ThePub which recently launched. They've been in the space, but are just now understanding how to contribute.
This leads to the last area where I think we're failing DevOps. We are seriously glossing over the amount of effort required to deliver on the needs of DevOps. This stuff is not always easy and as the latest State of DevOps Report demonstrates, the impact to Ops is great. I find that even this impact is being glossed over in the report. More on that in my next post.
The report stated that failure rates during deployments INCREASED for organizations who were considered medium performers. Their performance status based on their frequency of code deployments to approximately 37 times a year versus two. In the same report we learn that the mean time to recovery actually INCREASES for these folks as well. What the actual...ok hold on a minute. We adopt DevOps and things get WORSE for Ops as a result?
Anyone who has carried a pager is likely cringing at this thought. Without receiving the right expectations, understanding the actual needs, and lacking the appropriate tools to accommodate the new initiatives the Ops folks are left with a distinct disadvantage. Additionally this is going to put considerable strain on the initiative. I can only imagine how difficult it is for the leadership who are seeing their core performance metrics see a drop as a result of a DevOps initiative. "Didn't you guys go to the DevOps conference and read the Phoenix Project? Why are we doing WORSE!?"
Given the items outlined above and the results of the State of DevOps report there needs to be a significant focus placed on getting the Ops side of the boat more information to make them function at a higher level. We need to get them a quantity and quality of content which is more on par with their Dev counterparts. Otherwise, the only result is that they are going to have to paddle considerably harder just to keep the boat from going in a circle and getting them no farther forward. They also may not even know why. My fear is that a high percentage of organizations are currently working in a very circular or sinuous path. It doesn't need to be this way. As a community we simply need to talk less DEVops and making sure we are talking DevOps. We're all carrying the load after all.
P.S. I'm betting the mules have a heck of a story to tell. :-)