The Network Automation Journey

How is network automation and packing parachute similar? They're both intimidating, and they both involve a learning curve. On the other side of the learning curve/hump, it's pretty nice.

In this episode, I share my thoughts on what constitutes a network controller. Back in the early 2010s, it was thought to be the way devices had their forwarding tables configured. Now it's how a devices configuration state is configured.

What was automation like in the past?

Well, it was mostly non-existent in most of the networking world. But we did do automation in the server world, but it was quite different than it is today.

In this episode I talk about skillsets that I've picked up outside of the networking world that have really helped me out.

Here is just a quick talk about some of the history of network automation, at least from what I've seen in 25 years of server and network administration.

A great question from Twitter: "Any tips for leveraging Ansible in a team environment". In this episode I answer that question with what I've learned.

Coder: Essentially VS Code in webapp form: https://coder.com/

In this episode I talk about open-source versus closed-source projects.

A recent discussion had me thinking about the two common uses for the term "CLI" (Command Line Interface, of coures) with regards to network automation: One is the configuration method (as opposed to API or GUI), and the other is the configuration state (CLI syntax, such as running-config on Cisco/Arista).

Recently RedHat has been making some decisions that has affected a large percentage of its user base. In this episode, I share my thoughts from a network automation perspective.

In this short episode, I talk about making your own platform versus using an existing platform/framework.

An example would be writing your own Python automation platform, versus using something like Nornir (which is a platform plus some Python) or Ansible.

I talk about why it's usually a good idea to use an existing platform versus making your own.

I saw a comment on a network automation forum, and while the poster made a lot of great points, there was one point I disagreed with: That DevOps practices are a necessary component on network automation. While I think there are some aspects that are important, going full CI/CD pipeline isn't necessary. Here I give my quick thoughts on this subject.

In this episode, I give an overview of what CI/CD is (both traditionally and for network automation), how it's used, and why it's used in network environments.

If you have questions about network automation, you can ask me on Twitter: @tbourke

One of the things we think about as network automators is the concept of incremental change versus total configuration replacement. Traditionally all our changes have been incremental. From the day a switch/router comes online, it's little change after little change. In this episode I talk about how this changes from incremental changes to total configuration replacement when working with most types of automation.

In this episode I talk quickly about whether APIs should be standardized.

Pretty much all APIs are open in that the vendors allow anyone to access them and the specifications on how to interact with them are public. But using NX-API from Cisco and eAPI from Arista means using two different sets of commands to do that same thing. Projects like OpenConfig/gNMI are meant to provide a single way to configure parameters no matter the devices through a single data model.

While this is useful, in the data center it's not so much a problem we tend to have. Working with one API is OK, since data center networks are typically built using only one vendor.

In this episode of the Network Automation Journey I talk about some other criticisms of network automation that I've heard of lately. 

One of primary the factors pushing organizations into embracing network automation is the need to dynamically generate complex configurations, specifically for campus and data center implementations of EVPN/VXLAN. 

Different devices have different native configuration methods. Generally they're either syntax (think Cisco IOS) or state-based (more rare, like Cisco ACI). 

When I teach an automation course, I'll typically show a video: https://www.youtube.com/watch?v=HluANRwPyNo (a bit of foul language in it... but very realistic use of it)

In networking, everyone Google's everything. Got an error message? Google Search. Can't remember how to do something? Google Search. The same is true in network automation. 

Also, this comic from XKCD: https://xkcd.com/979/

Recent discussions on Twitter and in a few classes brought up the venerable VI editor (or the more common upgrade to VI, VIM). 

It was once a must-learn tool for Unix/Linux/BSD administrators. It was used for editing configuration files, data entry, and even coding. 

These days it's not quite the must-have it used to be. In fact, most people working in the industry can get by with the less capable, but far easier to learn, nano editor. 

In this episode, I talk about stunted careers, people (including myself at one point) that just won't learn anything new, despite the world passing them by. Luckily I got out of my stunted phase relatively quickly, but it's something I see in networking from time to time. 

Bad Takes: Is Ansible just automation for people who don't know Python? Of course not. And we'll talk about why.

@el_dude_abides asked a few more excellent questions which I did my best to answer:

• How do you lock down APIs? 
• Experience with Terraform?

One of the most important skills in network automation is to know your way around YAML files and JSON, to know the difference between lists and dictionaries, and how to iterate through them. 

In this episode, I talk briefly about two different depths of automation: Supplemental and Total. 

With supplemental automation, automation is used only on part of a config (SSH keys, DNS, NTP, etc.) while the rest of the device is configured in the traditional (i.e. manual) way. 

With complete automation, no more manual configuration is done and the entire configuration is done through some sort of automated means. 

On twitter (my handle is @tbourke) I asked for people to submit any questions about network automation that they might have. I got one response pretty quickly from @el_dude_abides, and here were their questions: 

• Will SNMP ever go away? 
• YANG or NETCONF? 
• GUI or CLI best?
• Will application & server peoples ever understand how their stuff works? (i.e. ports, transport, source/destination)
  

All great questions, and I want to thank the Network Dude for asking them. I answer them in this episode. Enjoy! 

What is the relationship between Python and Network Automation? It's easy to conflate the two, and while they're highly related network automation isn't just Python. 

In this episode I give you a "pep talk", a bit of encouragement for those that are experiencing some fear and perhaps even some loathing when it comes to learning network automation. 

Generally, I see three main reasons why students I encounter and network professional are hesitant to learn network automation skills and tools: 

1. They think they don't have the talent for it (the midichlorian problem)
2. They think they'll automate themselves out of a job
3. They think they're too old to learn

I go through each one and talk about them. I hope it helps address any hesitation you might have. 

In this first episode, I talk about how I got into network automation (by way of server automation from the late 1990's). 

This podcast is a series of single person, just me (Tony Bourke) talking about the network automation journey. While there's a lot of resources out there to help people use the tools of automation (Ansible, Arista CloudVision, Python, DCNM/ACI, etc.) I think there's not as much talk about some of the fundamental concepts, motivations, and how to address the "fear and loathing" of automation that the networking community can sometimes express regarding automation.