Why I'm telling network engineers to learn Python

During a wet autumnal walk, I was explaining to my girlfriend about my recent presentations. I've been doing my 'Getting Started with Python' talk at Aruba Airheads meet-ups. I recorded an early version of it, see below. One point I mentioned is that the reaction is always mixed. When I ask who is learning Python, about 5% of each audience put their hands up. Regularly people object to the idea of network engineers learning Python. The arguments are usually along the lines of 'network engineers already have enough to learn'.
The conversation continued as we walked through sodden leaves and we discussed why, if the other speakers were doing talks that the crowds want to hear, like product updates, I'm burdened with a subject the audience are less enthusiastic about. The assumption being that I was assigned this topic. My response: "Oh no, I choose to do this." The next question was, of course, "Why?"

My Why

There's something of the two-edged sword in the word 'why'. It can be used to undermine, casting doubt about the veracity of an argument, cutting through the rhetoric and leaving those with ill-reasoned ideas to flounder and stutter a response. But it can also galvanize, provide the opportunity to refine and reinforce one's thoughts, to thrust home one's argument.

Here's my why. Why I think learning Python is a worthwhile exercise as the first step on the road to automating networks, and this conviction stems from personal experience.

Example 1: Config Wrangling

All talk about network automation will tell you that it is much more than just configuration management. That's correct, but it isn't like we've got config management all sewn up.
Both in my Operations days and my work on Proof of Concepts I would deal with large configs; core boxes, PEs, L3VPN work. I used to handle them without any coding skills. Being an inventive type and having no clue just how useful learning Python would be for this, I worked out a weird tricks with Excel to 'auto-manually' generate configs.
Admittedly using a Network Management System would have been preferable, and the core network had all the configs neatly archived. But I used to do a lot of work on new networks, ad hoc changes and onboarding. Then there was a lot of sandpit builds and test environments prior to major changes. Not every config task was on the live network and all that preparation was vital to getting things right. In a later role as a Proof of Concept engineer there was no NMS, I would build up and tear down test networks for large deals in maybe two weeks and some of these were not small.
Doing all this as a full-time job I got pretty good at banging out these config files but a few times they were just too big and were taking too long. For example, rewriting full PE configs or 500 IPSEC tunnels that I needed ASAP. Faced with those problems I reached out to others with some scripting skills to help out. That's it right there. I can point to those occasions and honestly say that even as a full-time CLI focused Ops engineers, I knew having at least some basic scripting skills would help me out. Hence why the 'network engineers don't need to code' argument doesn't wash with me.

Example 2: Get off the CLI (or GUI)

Fast-forward to 2012, I'm in the midst of the biggest PoC I've ever been involved in. High revenue potential, high profile new account and high pressure. The customer's test plan is weighty, coming in at nearly 100 pages of A4. The tests are very specific so hardware and resource are hired from Spirent. Now I've got a buddy to work on the build with, a chap named David, he builds the traffic profiles, I build the configs. The Spirent has a GUI and a wizard, that's my interface. But Dave is a pro at this and he's used to whipping up 100 streams of UDP in a test profile in a few minutes. Does he use the GUI? Of course not, he's scripting everything. Dave sees my efforts and my .xls .txt juggling act and tells me I could save myself a lot of time if I learnt to code. At that point I was convinced. As for the PoC, it was a success and we got the win. I got a bottle of champagne.

Example 3: Right Tool, Wrong Hands

I think these examples illustrate the simple principle of using the right tool for the job. My quirky use of Excel or using a GUI for large scale tasks was the wrong way to go about things. But that isn't always the problem, and this is a major issue in Networking today, the tools do exist and they have done for years but we in Networking are either unaware, or blissfully ignoring them; happy with the idea that networkers need to know speeds and feeds and how to neatly cable. However, this kind of thinking is not only holding us back, it means that tools are harder to adopt.

Night of the Living Orchestream

In the early stages of my career working for a carrier, I supported a newly deployed Cisco MPLS network. That meant lots of L3VPNs and lots of new Cisco configs. The carrier deployed an active config management system called Orchestream. The problem was that the operation of this tool was poorly understood by the Ops team. Configured incorrectly, Orchestream had a habit of running a diff in the early hours and stripping out live config that was not committed to its source config files. Working changes from the Implementation day shift suddenly disappeared, mass outages ensued and no one knew why. Orchestream was quickly found to be the culprit, fingers of blame pointed to the tool and it was deactivated permanently. Night-shift engineers happy in the knowledge that this nascent skynet was taken off-grid.

Git for Config Management

Now I'm not saying Orchestream was the answer to all our networking problems, it wasn't, they went out of business. But I'm reminded of that system when I talk to people about using newer tools for config management and version control, namely git. For all the pain when starting out, git is a wonderful tool and I believe all network configs should be checked into a repo. But why isn't it being adopted en masse by network teams? This looks like a case of the right tool, wrong hands.
My guess is that most are unaware of git and, if they are, there is the stigma around git's workflow. I introduced a colleague to git last year. He called me the next day, suddenly all his files were missing, there were warnings filling the screen and he froze, afraid of doing anything least git would permanently delete all his work. He cursed this new, malicious spell that had been cast on his file system.

Orchestream Flashback

I got an Orchestream flashback. I know this feeling with git, I've been there. But it is vital to not act like a modern day Luddite, to not do away with these new tools. Git just takes a bit of time to get to grips with. Personally, I found that once I got the hang of the basic workflow I was happily committing changes into github (enterprise), watching my green tiles grow. No more filling my hard drive with slightly different .txt files or worrying about losing the thread of config changes. As mentioned, I'm convinced git should, and will, be adopted more widely by the Networking world.
But what's this got to do with Python? I used, and more importantly, persevered, with git as a useful ancillary exercise while learning to code. By working with Python, I stepped out of the bubble of Networking and into a new world of tools associated with software. I believe the industry as a whole would benefit from doing likewise.

We don't need no education

Networking is a different discipline to software dev and sysadmin, but it has built a wall around itself during my career to the extent that we are disconnected from the progress made in other areas of IT. For the most part I feel the majority are just unaware of the developments outside of the Networking bubble. But also, even if aware there is an inability to adopt new tools. Many have said it, and I'm going to add my voice, we do need to expand the networkers skill set through education to embrace new tools, new approaches and a new culture.
For all the naysayers, I knew years ago that if I could code my own scripts, even if just for my configs, I would save myself a lot of effort but I simply didn't know how to start. This is why I'm telling network engineers to learn Python. That was my key to thinking outside of Networking, and to do things like to play around with APIs. It was through a Python tutorial I first started looking at git to backup my code. From my travels around Europe this autumn, I get the feeling there are many others in this industry that would benefit from setting off on their own journey down this code rabbit hole. My advice, as always, don't delay any longer, just start.

@joeneville_