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.