Skopos is free for beta use. Check it out!

Spend a little bit of time reading about DevOps and you’ll no doubt discover the term NoOps. That’s right, the idea that eventually we’ll have “no Ops” seems to be attractive to some Dev folks. At the same time though it’s easy to find posts from DevOps managers writing that their Dev team doesn’t take Ops seriously. Some of the posts and the comments devolve into rants. So almost a decade into the transition to DevOps it seems many companies still struggle with a significant divide between Dev and Ops.

Friction between Dev and Ops isn’t new, of course. As long as I’ve been in tech (and that’s a long time now) there’s been friction between Dev and Ops. IMHO the rub arises from the fact the very nature of their roles has historically been quite different. A friend who was CIO of a major bank once told me “I won’t get fired because a new service is late, but I will get fired if a core app is down.” His remark exposes a quintessential Ops mindset; he got paid to keep stuff running. Putting yourself in this mindset for a moment isn’t hard. Imagine being CIO of a bank and having the ATMs down. What kind of calls do you think you’d get? I bet you can easily understand why Ops likes periodic releases, large staging environments, long QA cycles, centralized logging, monitoring absolutely everything, and remote access to manage everything. Sure, these things slow down delivery but they enforce stability.

Dev, conversely, is paid to deliver new apps. Without new features and apps being deployed Dev has no way to show their work output. How would you like to face your boss each quarter and report no new results. Doesn’t sound like a good time does it. After a couple quarters like that you’d be willing to take a little extra risk to be able to roll out a new service. Hence, from the perspective of Dev needing to deliver, much of what Ops has classically done to ensure stability actually looks like barriers.

The relationship between Dev and Ops has never been static either. At one time, believe it or not, Ops held all the power. In the last decade or so the relationship between Dev and Ops has changed significantly. First virtualization and cloud commoditized repetitive provisioning functions Ops used to provide. Cloud also eliminated much of Ops capital budget. In addition, web companies like Amazon, Google, Facebook and others have changed the expectation of feature delivery to the point some companies now deploy as frequently as every minute. The emphasis on speed and commoditization of infrastructure has shifted the power dynamic in the relationship in favor of Dev at the very time the industry began a migration to DevOps, merging Ops responsibility into Dev. Given all of that, it’s not surprising some Dev folks assumed Ops was dead.

Contrary to popular opinion, though, Ops isn’t dead. It’s just changed. As I mentioned at the start of this post you can find a lot of posts online about Dev teams not taking their new Ops responsibilities seriously. While I know many Dev teams like that, I know a lot more Ops folks who haven’t completely adapted to their new responsibilities. Ops folks need to start thinking like Dev and embrace the concept of Ops as Dev.

What do I mean by Ops as Dev? Let’s take a simple example of monitoring. In a traditional Ops environment I’d expect to monitor the availability of a service and provide an alert to operators the service is unreachable. In a modern online service, of course, this is simply too slow. I’d expect the monitoring to trigger a corrective action. The questions of interest here are what corrective action, who specified that action, and who wrote the code. All too often I find someone simply scripted the old solution of monitoring and corrective action, but if you truly embrace the concept of DevOps the monitoring and the corrective action aren’t separate from the service, they’re part of the service. They have to be written, tested, deployed and maintained as part of the service even if the actual code is written by the devops team.

Ops folks need to learn how to put operational needs into user stories, get them on the backlog, prioritize them during grooming and work with Dev and product owners to ensure they get built. To keep their features in the mix during backlog grooming they’ll also need to learn how to make them forward looking, enhancing strategic goals rather than simply “we need to monitor x.” This latter requirement, keeping Ops features in the mix during backlog grooming, is going to be the biggest mindshift. Ops isn’t used to thinking this way.

My suggestion to Ops folks – start buying lunch for product owners ( or product managers at some companies). I’m not being flippant just because I’m a product guy and I always love a free lunch. Product owners live and breathe user stories so they can help you figure out how to write Ops requirements in ways that align with strategy and user experience.