NetOps Embrace of Automation will lead to need for NetOps Ops

Automation is the future. DevOps has long embraced the idea of automating everything in sight, but NetOps is quickly closing the gap between them using automation and orchestration extensively in production processes.

Nearly half (46%%) of respondents in our State of Application Delivery 2018 survey indicated at least ‘partial’ use of automation in production. That includes always using automation for major production changes (25%), minor production changes (26%), and even incident response (22%). More than half ‘sometimes’ use automation in all three cases.

That automation is implemented in a variety of ways. Network automation like that from Cisco and VMware and OpenStack are popular, as are frameworks and tools like Puppet, Chef, and good old Python scripts.

To say that automation is a thing that’s really happening is not an understatement. NetOps has arrived. This is not a drill.

That’s exciting, on the surface, but when you dig into what that means we find there are challenges that might not yet have bubbled up to the surface.

For example, automating a change on the firewall or router is one thing. Including it in an overarching deployment process, well that’s another (and the proper term for that is orchestration, in case you were wondering).

Once you start chaining (integrating) systems and scripts you’ve built what is equivalent to an ‘application’. There are many moving parts that have to be deployed, managed, maintained, upgraded, patched, and licensed.

This is not a Sisyphean task, but it is one that NetOps is likely not taking into consideration.

It’s great that developers can now enter a ticket in ServiceNow and that will kick off an IT workflow that automagically provisions, configures, and bills for the desired resource. But what happens when ServiceNow chokes? Or when one of the components in that fragile chain sudden keels over. Or when an upgrade of one of the components breaks the integration?

If you close your eyes you’ll hear the sound of developers chortling from an overdose of schadenfreude at the thought.

One of the unintended consequences of automating IT is going to be that IT has more software and systems to maintain. Some of them will be critical, and require more care and feeding than others.

Just as there are legions of ‘maintenance’ or ‘support’ developers within enterprise organizations whose task it is simply to keep software systems running, there will be a need for a similar role within IT to deal with the day-to-day operations of NetOps Operations.

NetOpsOps. Yeah, it’s a terrible portmanteau but it is an accurate way to describe what’s going to be needed as automation consumes more and more of NetOps deployment tasks.

Some of those tasks will be of a nature (integration, software systems, etc…) that can be shouldered by existing operations staff. But some are specific to the network, and that means someone who both understands the scripts and systems and the networking components involved.

You can’t troubleshoot, update, or modify code/scripts/templates if you don’t know what they’re doing.

If you ask me what’s wrong my snowmobile I’m going to tell you I have no idea. I know how to open the hood, and charge the battery, but don’t ask me to go tinkering with the parts that make it go. That’s the same as asking a development intern proficient in JavaScript to go updating a COBOL copybook. That’s a recipe for disaster right there.

Ultimately, NetOps is going to need some folks (the NetOps Ops) who are knowledgeable about the network and the systems used to automate it. The more automation is used, the more imperative it will be to have said folks in place to take on the mantle of maintaining that automation while engineers are working on the next big thing.