Bridging the Divide Between DevOps and NetOps

In case you hadn’t noticed, we’re writing a series along the lines of “Bridging the Divide between…”

This one’s about bridging the divide between teams, which initially strikes me as a trap.

I’ve seen too many articles that pit DevOps teams and NetOps teams in opposition to each other, almost at the personal level. That’s not helpful – because it’s not about the people or the teams – it’s about the constraints and expectations that have formed them. The individuals within those teams mostly all enjoy doing the same thing at work – cool stuff. We all want to make something that we’re proud of, that does something useful, and that is, well, cool.

What’s different between teams, and what determines the shape of our working day is the boundaries and impacts of what we do, and the tools at our disposal. DevOps teams generally solve for an application or a collection of services. NetOps teams solve for an enterprise, or hundreds of enterprises in the case of cloud NetOps teams (yes, they do exist). Most network teams have at least one foot in the physical world, because something actually has to shove those photons and electrons form one place to another. Most DevOps teams work in the ethereal world of the virtual, enjoying the power of almost instant creation and destruction of resources. While development and DevOps teams happily (and quite rightly) abstract their code and business logic away from the nitty gritty of the underlying architecture, they do this with the implicit trust that someone is making sure that their API calls get to and from the right place. Everyone wants to move fast, everyone wants things not to break, or to be easy to diagnose and fix when they do. It’s just that the universes they inhabit can look a bit different from the inside.

It’s at the boundaries of these two realities that the trouble can start. It’s clear that, in many organizations, there is a divide between the working practices and SLA requirements of different teams. Although this friction might be regarded as a new thing, it’s a condition we’ve observed for well over a decade – simply because F5 technology has always been the interconnect between application focused-teams and infrastructure-focused teams. Whether it’s just a change in the number of backend servers or in application behavior, changes to the application architecture have always needed to be reflected in the application delivery layer, where security inspection, content routing, or load balancing is happening. Now that developers are organizing their workflow to be more iterative, these changes are happening faster and faster, and so the symptoms are becoming more obvious.

Which is why it’s such an exciting time. Because there has never been an opportunity quite like this to bridge this divide. At F5 we’ve been developing more and more tools to plug our hyper-robust, enterprise-class technology into more agile, automated workflows. We’ve been giving training in these new ways of working to anyone that wants it. And we have been transforming the way we work internally.

But the best bridge between divides is built from understanding and shared experiences. The tools and processes to support the bridge won’t hold in place without the mortar of collaboration. That’s what I’m looking forward to most about working more with NGINX – the opportunity to jump the gap and see what things look like from their side, and more importantly, their customers’ side of the process divide. Working together, we can help joint customers drive better and better understanding between all the teams involved in delivering secure, fast, and, innovative applications. Sure, there will be technology in there; it is, after all, what we make. But it will cover a wider range of use cases and be driven by a more complete vision around DevOps and NetOps to serve the needs of the group we’re most focused on – our customers and users.