Python vs. Platform (Ansible)


In my ENAUTO studies, I’ve been exposed to many components to network automation: NETCONF, RESTCONF, YANG, Netmiko, Ansible, Puppet, APIs, and the list can go on. After learning and labbing up each of these technologies, I always come back to the question “Why and how?”. Why am I learning these technologies and how do I plan on applying them (if they are even applicable to my given use case). In this post, I’ll go over my thoughts on different scenarios of choosing a base network automation tool. I will not go over a complete strategy, but rather how to get your feet wet in the world of automation.

What is your goal?

My obvious first question when beginning a journey for picking a new technology or toolset is to always ask, “What is your goal and/or the problem you’re trying to solve?”. With network automation, people want to automate for a variety of reasons: configuration standardization/auditing, minimize time spent on operational tasks, and many more reasons. These basic, yet essential, goals to begin your network automation journey can lead you and your team to more complex solutions that include CI/CD and true Infrastructure-as-code.

One of the common issues when beginning the network automation journey is the overabundance of choices. This can range from the tools, protocols, and other components that make up a solution. Do I want to use a popular platform such as Ansible? Do I need to learn Python? What are these YANG data models I hear about? What does RESTCONF and NETCONF have to do with it? There are a plethora of other questions a person starting their journey may ask themselves.

As with every goal you set, you need to focus on solving your specific problem or use case, and not the tool or vendor solution. In the next section, we will explore the common question many people begin with: Do I become a software developer and learn Python, git, etc. or should I start with an automation platform such as Ansible or Puppet?

Why choose one over the other?

Before I begin, you DO NOT need to become a software developer to begin using Python in network automation. Software development is much more involved and just knowing the basics of Python: data types, variables, functions, classes, etc. can get you started on your network automation journey.

I’ve personally experimented with a pure Python approach using libraries such as Netmiko, NAPALM, and Nornir and with the automation platform Ansible. Granted, Ansible is a tool built on Python, so you aren’t avoiding Python when using Ansible, but you’re working within the guard rails of Ansible. Obviously I can’t tell you which one to pick since all uses cases and problems are different, but I will go compare the limitations and benefits of each. It will be up to you to choose the right solution.

I’ll begin with Ansible.

Ansible allows you and your team to get up and running with automation within the matter of hours to minutes (if you know what you’re doing). It is well-documented and provides hierarchical organization using inventory management files, group variables, and roles. It may take a little bit to get used to the organization, but the execution is pretty straightforward. Ansible uses playbooks to execute plays and tasks. Within each task, you use built-in Ansible modules or can download more modules from Ansible Galaxy. Each module allows you to perform specific tasks on your target hosts. For example, the module ios_command allows you to perform CLI show commands, while ios_config allows you to push configuration. With the recent release of Ansible 2.10, collections were introduced and can make the structure of the tool more digestible (check out Ansible collections here).

Some of the benefits to Ansible include the readability, extensibility, and quick wins it can provide. One of the easiest ways to introduce a new tool or idea to a group is to show how it can solve a specific problem, but more importantly, the turnaround time it takes to solve it. You could install Ansible, generate an inventory file, and create/execute a playbook all within a 30 minute meeting. That can buy over any engineer that hasn’t explored the automation. On top of that, Ansible provides extensibility and readability. Extensibility is huge because it avoids vendor lock-in and allows you to get creative with the tool. You can integrate it into other workflows within your team or with another team (i.e. IT Security), which may provide some additional benefit to them, and its always good to make friends across the IT org! The last, and one of the most important benefits as it relates to adoption, is readability. Readability may not be the exact word I’m looking for, but the idea is that anyone who reads an Ansible playbook should be able to understand its purpose, without having prior knowledge of the tool. The reason for this is that Ansible playbooks are written in YAML. YAML allows playbooks to be written in pretty much plain English. So to highlight the benefits, Ansible can provide quick wins, can be integrated with other tools/workflows, and, most importantly, it’s very easy to understand, which can lead to better adoption by other engineers.

A con to Ansible is that, with the playbooks and modules, it may limit the functionality that you can find when dealing with Python on its own. You can set variables and perform limited conditionals and looping, but if you need more advanced features, you’re better off using just Python. I don’t want to make it seem like Ansible keeps you in a bubble and limits functionality, but it does provide guard rails. The guard rails can be great when you are first starting out with automation and even pretty far into your journey. Automation is great, but when things don’t go right, it’s amplified at scale, so it’s good to have some built-in guard rails at first before you learn to create your own. When you begin looking into CI/CD pipelines and true Infrastructure-as-code, you may begin looking at pure Python and its associated libraries because it provides unlimited options. With that being said, let’s move on to analyzing Python.

Python has many libraries that do the heavy lifting for many network engineers looking to get started in this new network automation world. Netmiko, NAPALM, and Nornir are a few of the popular libraries out there. I’ll leave links to their Github repos at the end of the post. I’m not going to go explain each tool in-depth, but I would like to provide some guidance on the order you should learn/read about each one:

  1. Netmiko
  3. Nornir

The reason I say to do it in the following order is because one builds on the other. For example, Netmiko is built on Paramiko and helps manage SSH sessions and sending command(s) to one or a list devices. NAPALM provides an abstraction layer across many platforms (Cisco IOS, NX-OS, Junos, etc.). That way you can focus more on the information you are trying to gather. Lastly, Nornir is a framework that allows built-in concurrency and for you to plug Netmiko and NAPALM into the tool.

With all the options available by using pure Python, it makes you wonder what are the drawbacks? One of the largest drawbacks to pure Python is the barrier of entry. Before jumping into the previously mentioned libraries, you need to understand the basics of Python. You need to understand the different data types, declaring variables, difference between lists and dictionaries, and there’s much more. Engineers may find it cumbersome to learn a programming language before diving into the libraries/products that enable the network automation.

Another drawback to Python is the need to create guard rails. I know… I just talked about how one of Ansible’s drawbacks is the use of guard rails. However, when you begin programming, you’ll quickly understand how many things can go wrong and know that you should build protection into your scripts. Besides creating error and exception handling, you will also need to create instructions for your users. Since your script is homegrown, you’ll need to provide documentation for usage of your script and inline comments in your code to explain what’s happening in the script. There are many other considerations to safeguard your script, but the idea is that you need to create those guard rails that other platforms and tools already have built-in.


This was a long-winded post, but I hope I helped get you thinking about your specific network automation use cases and the different ways you can solve them. Please let me know your thoughts and/or questions by commenting or hitting me up on Twitter @devnetdan!



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s