The Rebirth of Network Automation

Don't let your admin job suck the life out of you!

It was 1991 and I was on a Network / Unix / Banyan Vines admin team for about 8000 users. My favorite tools were ksh, perl and expect. We used them for everything we possibly could. That’s right, we were building tools with them that we needed for everyday use. Why not buy something or download something from a website? Well, it was either because a one of the 50 or so web sites in the world didn’t have anything, or the lackluster excuses for management wouldn’t approve the expense.

In those early days of networking it wasn’t uncommon to make changes to dozens of routers or Ethernet hubs. We would fire up the appropriate expect script and it would be done in 30-45 minutes without one of us being involved. We would read the report after it was done and make sure nothing failed, but this was much better, faster, and less error prone than doing it by hand. Oh, and we didn’t spend 2 days telnetting into device after device and pasting in a config snippet. I was no different than the engineers I was sitting next too. We were all developing and sharing scripts and other handmade tools to help us all do our jobs more efficiently.

On the team only one of us had any formal programming experience so the rest of the team took at “C” programming class together at a local college. We used the knowledge from that to expand our understanding of how to write code, structure jobs better, and learn more advanced techniques. Before long our simple scripts became more complex, could accomplish more, and were more resilient when something unexpected happened.

At the time, I figured this type work was normal. The belief was confirmed when I left that team I saw other doing the same things. Each of the teams had the “shared drive” with all the team scripts on it that they had built. These comprised everything needed for accomplishing the routine tasks that turn a great Admin job into a torturous waste of your existence. Automating network operation components was normal in the small-scale shops everywhere I went.

At some point, I skipped out on my brothers and sisters of IT and became a sales engineer for a networking vendor and my finger came off the pulse of everything happening in the network admin world. I kept doing what I was doing, building scripts, learning new languages, writing small tools to help do my job. Setup a proof of concept network? No problem, let me run a few scripts and it’s done. Build an interactive demo? You bet, just let me get a few things from my “shared drive” and we’ll have it ready in no time. This went on for over 15 years, all the while I thought my old teams had evolved into the new languages, bash, Python, and REST APIs as I was doing.

I was wrong.

I don’t know when it happened, but somewhere along the way many of the network and system admins stopped building tools and forgot how to code their own. How is it that something so vital to the job in the ‘90s could just disappear? Does everyone have awesome management now and they buy you everything you need in a canned application? That’s certainly not it. There are lots of tools now that you can download for free, so I’m sure that contributed a lot. I still can’t help feeling like something was lost in those years. More importantly it’s going to be a problem for those still doing the job without programming skills of some sort.

I recently interviewed someone who was an accomplished admin and I have no doubt that they could have accomplished every bit of work I tossed at them. They had a great personality and had a natural ability to present at a whiteboard that was better than most people I’ve met that make a living doing it. Did I mention that I didn’t want them to do the work, rather I wanted them to automate the mundane, life sucking tasks I would be assigning? Automation would free them up to do other work that requires a brain and provides a sense of accomplishment at the end of the day. Why didn’t I hire them you ask? They didn’t have any experience with any type of scripting or programming. They were a long way behind the other candidates- and “too busy” to learn these contemporary ways.

If self-driving cars, machine learning, cloud computing , and Big Macs served in vending machines aren’t enough to tell you the world is changing then I don’t know what you need to hear about before you realize the following about your career:

“As software takes over the networking discipline, engineers who don’t learn to code a general-purpose programming language will be left behind.”
– Network Computing Article: http://www.networkcomputing.com/data-centers/programming-an-essential-skill-for-network-engineers/a/d-id/1297898

Now that you know the bad news, what can you do about it?

Every relevant vendor in IT has an API to work with their tools and equipment. Those APIs aren’t there for you to enter CLI commands into, they are there to let an application provision its own network. They are there to enable tools to orchestrate the rollout of a new application with the network resources it needs at the same time. Those act ions eliminate the need for you to telnet into 40 switches and add a VLAN. They also replace that configuration management tool you’ve been trying to use for the lasts 5 years but either don’t trust or can’t get to work right.

While you might not have a job being a CLI jockey in a few years there is still a LOT for you to do. Those API calls don’t write themselves and I can’t think of a better person to write them than you.   We need experienced individuals that understand what should be happening to the network because 99% of the programmers out there don’t understand a thing about your world. You know how OSPF should be configured and what happens when network start flapping. Only you will know what needs to get pushed into the API to make that router conform to the business goals and security requirements.

Maybe you won’t need to write all the code, but you will certainly need to at least understand a language or two and help programmers with the work to build these new automations and integrations between devices. You will certainly be more valuable to your organization and your net worth if you can write, troubleshoot and explain to others what needs to be done.

At IGNW we have helped many of our customer organize automated workflows. While most people associate DevOps with code and applications, we also practice NetOps and provide automations for networking teams. We can write the code for you, provide a foundational system to help you grow your budding script library, or come talk over lunch about what can be done and how to get started.

To start your journey to the coding network and systems engineer that I know you want to be search and read about a few of these terms.

• API – A set of clearly defied methods of communication between compute systems used for passing and requesting information. APIs fuel the information exchange of the internet.
• Python – A general-purpose language with lots of support for networking. It’s also very easy to learn.
• Go (Golang) – Another general-purpose language that is easy to learn and is less complex than Python in many ways.
• JSON – Easy to read data structures that make it easy to pass large amounts of information between devices (usually by using an API).
• Configuration Management (Puppet and Ansible) – Tools that help you both configure and maintain state of devices.
• GIT – Software system for controlling and tracking versions changes to computer files that is typically used for software code.
• PowerShell – The Python of Windows computer.

It’s a new world everyone. Come join the virtual team of networking engineers that are building scripts and writing code again. Maybe we can get a shared drive going for all our code. Together we can foster the rebirth of network automation.