Networkers and Coding Q & A

In Part One of this blog I mentioned that I liked to start the second day of the workshop a little differently. The workshop itself was aimed very much at network engineers but the second day was all about using Python to interact with the ArubaOS-CX API. I know from experience that not everyone is comfortable with the notion of engineers diving into coding, that for many an API is just the latest ‘bright and shiny’ that will dull soon, and that network automation is just a marketing buzzword bubble. Regardless of all this, the exercises were all Python and the attendees were going to make API calls and pick through JSON. There was no exam, no compulsion to attend, no (ridiculous) participation certificate and no armed guards blocking the exits.

"Why are you here?"

With all this in mind I thought we might as well tackle the 'networker vs. dev' subject head on, so I put it to the attendees; "Today is about Python, you are network engineers, why are you here?" Rather than just have them listen to me provide my viewpoint, I wanted the group to interact and provide their own experiences and opinions, and I’m glad to say I did because the majority of these sessions were an excellent way of hearing from the attendees. The reality is that the majority of people in Networking are not bloggers. They aren’t in marketing and they aren’t tweeting their every waking thought.
These discussions were unscripted, I tended to bring up roughly the same points of information to fire up the discussion. For example:

• Automation is happening across IT.
• Aruba’s networking kit now has REST APIs.
• Gartner is telling all who will listen to get off the CLI for the ‘day-to-day' chores.

My aim was to provide evidence that automating tasks in IT is happening right now, what did they think of this trend moving into our beloved world of Networking?

Across the six countries and twelve sessions that I ran this discussion, there was a variety of views and opinions expressed. But there were some general points that were raised across the sessions by completely different attendees, in different geographies, which I would venture to propose offers some suggestion of consensus of thought. The most popular discussion points, and my responses, were as follows:

"I’m a network engineer. Why do I have to become a programmer?"

Firstly, you don’t. Do whatever you like. If you work in IT and you do not like learning new things then sorry my dude, you’re in the wrong game. Sitting around complaining that your employer hasn’t sent you on a training course holds little weight in today’s world. There’s a wide range of resources online. We’re not performing surgery here, you don’t need elusive resources like a fresh supply of cadavers to practice on. You need a computer, an internet connection and maybe a cup of tea.
Furthermore, this whole effort is not about turning network engineers into senior developers. It is about networkers picking up the skills to interact with the network in a programmatic fashion. Lightweight automation tools to reduce the amount of time spent using the CLI for repetitive every day tasks is the aim, not getting you to write Enterprise grade software. Your focus still remains Networking, the coding just becomes another tool in the toolkit.
Moreover, by just skimming the surface of this world of programming I realised how interconnected the systems and tools being built in other areas of IT are. Well, yeah, I mean that is the point of APIs at their heart, but it was greatly encouraging to feel part of a bigger effort. A really simple example of this was when I started using the Postman REST API client for calls. There’s a ‘code’ button, hit that and the Python, or the whatever language you want, to recreate that call was produced. That's a really useful feature. I feel Networking needs to learn from this mindset of putting the user first, how to break down barriers, to share, collaborate and interact.
Finally, the ‘plot twist’ to my recent Python training efforts is that this really isn’t about learning Python. This is about learning to interact with distributed systems in a programmatic way. Python is the deliver system for this, not the active ingredient.

"A Network Management platform can do all these automation tasks."

It is true that in the framework of learning to use an API, a lot of the tasks performed seem to be about configuration management and grabbing the current state of the network device, all tasks that an off-the-shelf network management platform would normally perform.
But, as mentioned above, learning to use an API isn’t just about using that API. Your NMS might be great for tasks A, B & C each evening but what happens when you want to do something different from what the platform offers?
In a recent customer meeting, the people I was speaking to were not particularly interested in APIs. I gave them my enthusiastic presentation but I could tell it was being coolly received. As the meeting was coming to a close, things got a little more interesting over a relatively simple matter. The customer started to talk about the different reports generated by their NMS and what they really wanted was to combine the reports into a more customised version than currently supported. After a quick discussion my conclusion was, ‘yeah, would take a bit of work up front but you certainly can do that’. They could just use the API to grab the required data and write to a .xls.
An NMS is a software system, it's going to have an API on it. If you are using the GUI only you’re actually going at things in a laborious, manual way. If you want to go to the next level you would be using the API.
I think this point illustrates why I think learning these new skills is so important for us in Networking, you’re not just learning a network-specific process like dealing into SNMP MIBs. If you learn to interact with your first API, such as on a switch, with the basics in hand you've already done the hard part and can work on sending API calls to the other systems at your disposal, like the NMS. Right there is the interconnection.

"Automation is for large customers only."

It is correct that writing and testing a script to perform a simple task, such as grabbing the MAC address table, takes much longer on a single device than just logging in via the CLI and issuing a 'show' command. But if you had to do that same task on 1000 devices, the script would be quicker than the CLI. So it follows that often attendees to the workshop would say automation and APIs are for the big customers only and not for the majority of their customers, most of which would fall into the mid-size campus bracket. I do not agree.
From a few meetings I've had with end-users recently, it is obvious to me that there are a huge amount of hours being devoted to repetitive everyday tasks. These could be on just a handful of network devices, if you are doing the same thing over and over again, that job is prime for automating.
Also, automation isn't just about doing the same, it is about improvement. Improving the reliability and consistency of those tasks plus adding new levels of service.
Checking whether someone has breached security policy by enabling telnet across even a modest estate is a pretty menial task to perform manually, perfect for automation; a scheduled script doesn't get tired or bored of checking and alerting. What about ensuring consistency of BGP prefix AS-PATH? No users will complain if a backup path changes but it would be good to know the behaviour of the paths you failover onto.
In one session each example I gave had the response of "yeah but customers aren't doing that. They hardly touch the network." To that I say if the Ops team only perform a few tasks now and again on their network, they are likely to get swooped up by cloud management platforms as they roll out. "I hardly do anything" is not a great defense as the juggernaut of automation bears down on the industry.

"Automation is the new SDN."

By "SDN" I mean the latest trend that everyone gets excited about, with promises of great change, but then we all go back to configuring spanning-tree once the VC money dries up.
This trend is a little different in a number of ways:

• This is not networking specific
  Other areas of IT have already embraced automation, society in general has too....Check any major newspaper for articles about the impact automation is having across all industries right now.
• Evolution not revolution
  An openflow SDN network was a new concept in Networking and meant huge changes even down at the packet forwarding level. Automation in the initial stages is about taking tasks you are performing today and making them more efficient and more reliable.
• Vendors are all in
  With SDN there was more than differing opinions, there were competing approaches and protocols (remember OpFlex?). This time round, every vendor is onboard and drumming out the message that automation is a thing and the future, even Cisco.

"Automation is nothing new."

SNMP is structured data, an API is just another interface, and someone, somewhere once had all their Network Operations entirely automated using Perl. I've heard this a number of times and I wonder what motivates the speaker to voice this opinion when the context is trying to urge people to do an objectively good thing, that is, the acquisition of knowledge. The evidence, from my experience at least, is that people are far from automating networks, that manual CLI rules and that the vast majority of network engineers can not code.

Gold star to the Perl scripter, now let's get on with changing this industry.

@joeneville_