NetOps Embracing Github Except for One Guy Hanging on to vimdiff

And other insights from the NetDevOps Fall 2016 Survey conducted by the NetworkToCode community

The NetworkToCode community is full of people passionate about networking and code. As cliché as might be, these folks have been automating networking since before it started to become cool (and an executive imperative) to do so.

During the Fall of 2016 the community conducted a survey on a wide-ranging array of questions that focused on, appropriately, networking and code. The raw results (linked above) are publicly available. The nature of online survey tools is such that resulting data sets can be hard to analyze unless you normalize the data (which takes work). Luckily for you, dear reader, I’ve done that work for you and can offer up insights in a more graphical and colorful manner.

Astute readers will note that I’ve long advocated for the application of what are typically referred to as “DevOps” principles to the network and unsurprisingly that’s where I focused a lot of energy while digging into this data.

There is no surprise that in a group focused on code and networking that views toward DevOps were at least mostly on the positive side. Only 6.75% had “no interest” in DevOps, while 25.74% noted it was already in production. Most of the others were at least thinking about (39.24%) if not evaluating (28.27%).

The fine purveyors of this survey asked some fairly fine-grained questions on this topic, including NetOps perspective on Infrastructure as Code. This garnered a bit more disinterest, with nearly 10% saying “no interest.” What was interesting was that only 19.35% claimed infrastructure as code was “already in production” but a full 54% of respondents indicated they used automation for configuration deployment and another 66% automate configuration archival. Exactly one NetOps is automating configuration management (and I’m pretty sure it’s not the one NetOps who proudly uses vimdiff to manage configuration changes).

The first question that usually comes to mind is “What is Infrastructure as Code” anyway? Which is probably at the root of why so many more are “doing” even though they identify mostly as “evaluating” or “thinking” about it. Fatigue definition is real, you guys, and without clear definitions provided these days it’s difficult to draw conclusions about ephemeral terminology (though we will anyway, because that’s what we do, right?).

So what are NetOps automating? We keep telling them they need to to in order to keep the digital transformation train humming along without delays, but we also know that enterprise networks, in particular, aren’t exactly an environment in which you play around with automation. These are serious networks, on which the entire business today relies. Turns out NetOps are automating quite a bit.

Configuration generation, archiving, and deployment are the top three operations being automated today. Data collection and reporting also appears to be gaining steam.

In fact with the exception of configuration management (and that one, adventurous NetOps) every operation appears to be automated in a respectable number of respondents’ organizations.

But of course automation of configuration-related tasks begs the question, how frequently does it occur and does it, therefore, warrant automation? I’d argue (likely against current thought on the topic) that the less frequently you deploy changes into production the more valuable automation actually is. Sure, you never “forget” how to ride a bike, but with months or years in between that first ride back in the saddle, as it were, can be a painful (error-filled) experience. So it can be with deployments. But that’s a topic for another day.

It turns out that NetOps is deploying on a pretty regular basis, with just about half (50.92%) deploying minor changes more than once a day into the production environment, and 37.59% deploying major changes 1 to 5 times a month. It’s nowhere near the extraordinary “200 times a day” touted by web-native, primarily single-app supporting tech providers (think Netflix, PayPal, or Facebook) but it’s still moving apps along at a pretty good clip for an enterprise that supports on average more than 200 applications (as per our own State of Application Delivery surveys).

Finally, you have to wonder how they manage all these changes? As noted in the title, there really was a single, proud NetOps who claims to use nothing but vimdiff to manage changes. Given the structure of the data it’s difficult to correlate that with the frequency of changes in production, but I really want to talk to this NetOps because he or she is my hero for proudly hanging on to what works for them, no matter the external pressure.

What do the rest of NetOps rely on? Turns out a whole lot of them are using Github. 47% to be exact. And another large group (39%) are using Rancid/Oxidized. Rancid (not to be confused with the American punk rock band formed in Berkeley, California in 1991) is a network tool that manages configuration backups. Oxidized is also a network tool for managing config backups, which is often touted as a replacement for RANCID. There are subreddits dedicated to them, if you get an urge to learn more about them.

A terrifying 8% are not tracking configuration changes at all. I did that once in the lab and wound up with a horribly asymmetric cross-network link that was 100Mbps one way and 1.5Mbps the other way. Yes, I accidentally recreated the modern broadband cable model in a lab in Green Bay nearly 11 years ago. No, I don’t get royalties, unfortunately, but the good news is I don’t get the hate mail, either. Again, it’s hard to understand that rationale without the ability to cross-tabulate against organizational size. Interestingly, 11.91% manage between 0-50 network devices, so it’s plausible to speculate that those 8% have a manageable number of devices to manage and are doing just fine. The largest group of NetOps (38.63%) is managing more than 1000 devices, and another 28.23% are managing between 251-1000, so it’s fair to say that the majority of NetOps are responsible for a lot of devices (almost certainly heterogeneous) and therefore tracking configuration changes becomes not only necessary to the ongoing good health of the network but the sanity of its operators.

Generally speaking, I really enjoyed this dive into the world of NetDevOps, as they label themselves, and the view on what they’re using, what they consider important, and what the environments in which they operate look like, if only from a skeletal 50,000-foot view.

NetOps are the backbone of the IT organization and increasingly responsible for keeping everything running while businesses undertake digital transformations that promise to increase the burden on the network and the operators who keep it running safely.

I don’t believe it’s possible to wholesale overhaul network operations from a traditional model to a more agile, DevOps-like model. Like the digital transformation of business, the digital transformation of IT occurs in stages with an eye toward not disrupting existing processes that might derail the business train. This survey shows there is clearly transforming occurring that, while perhaps not labeled as “DevOps” or completely fulfilling purists notions of what that entails, is definitely moving the enterprise network forward on its own digital transformation journey.