Why enterprise network automation with Ansible and Python is not enough
Network Automation Ansible 5 min read

Why Ansible and Python are not enough for enterprise network automation

Picture of Pieter van Os

Pieter van Os on May 1, 2020

Let me get this straight: I love Ansible and Python! But I’m convinced that you need more to successfully implement network automation. A simple example to illustrate my point of view: where do you store your data, your keys and passwords? There are solutions for this, sure, but it shows the main disadvantage of Ansible and Python: you need so many extra tools to really make it work.

Ansible is easy to start with, flexible and above all: it’s free! But it can only do as much. When you want to automate workflows (and let’s be honest: that’s where the real automation is), Python comes in. Python can really help you orchestrate your routines and workflows. And the good thing: it’s free as well. The bad thing, however, you’ll have to learn how to code.

In this blog, you’ll learn why it can be quite challenging to implement network automation with Ansible and Python, especially when your network is continuously changing and new services preferably have to be implemented yesterday. I will give you tips on what elements to pay attention to in order to successfully implement network automation. Let’s dive in!

Network automation with Ansible and Python

Ansible is easy to learn, there is a big community of helpful people and when you want to do one-off mass config updates, backups, or code upgrades in a small network, it’s great. But when you want to do more challenging stuff, for instance, if some tasks must precede others and checks are needed to make sure others have worked, it starts getting very complex, very quickly.
Ansible comes from the server environment where you only have a small number of variables to deal with. This, however, is the opposite for networks where you easily have the number of variables x 10; interfaces, ACLs, static-routes, VLANs, passwords. So this is the moment where Python comes in.

As a network engineer, when using Ansible, Python is something you have to familiarize yourself with. It’s flexible, so you can program anything you want. I remember reading somewhere: Ansible gives you a sandbox to play in; Python gives you the world to play in. And I think there’s a lot of truth in that statement; anything Ansible can do can also be done in Python. However, I would not recommend building your own automation solution in Python from scratch. You should use it to enhance and understand the other tools you use, but not waste time replicating their functionality. My main reason for this is time. There are only so many hours in a day and do you really want to spend them reinventing something that’s already been developed?

Coding in Python will be complex; you’ll have to think about all the configs yourself and you’ll have to translate your own language to the Python language. This takes time and usually, you don’t have that. For me personally, it is important that I develop myself as a network engineer, I don’t want to be a software developer. I think it’s good to understand the basics of programming, but my heart lies with the network. I want to automate the boring stuff so I can focus on improving the network.

If you want to use free tools like Ansible and Python you basically need three people: a software developer to code, a network engineer to tell him what he has to code, and a database manager to securely store all the information.

So what? I can do that!

I pride myself on being a network engineer that can handle complex challenges. And I’m sure you do too. So I’m confident you and your team can build a network automation solution with Ansible and Python. But as soon as your network grows you’ll run into problems. What do you do when an outage pops up and you find yourself going through templates, configs, and scripts that you only half understand? All this while your manager is nagging you why it’s taking so long.

Let me list some of the things you have to consider when building a network automation solution yourself:

Scalability is critical to keep up with the demands of ever-growing and expanding use cases. When you have a truly scalable network, you can address specific business needs the moment they arise. How can you be in constant control of your network so you can scale by only pushing a button?

Supporting a large network is always teamwork. How do you make sure that everyone is up to date with the latest information? Is there a common way of planning and preparing changes? Do you have a central place where you can share your engineering logic, for instance by means of templates?

You need a safe place to store credentials, but also information about your configs, topology, ports, vrfs, ip plans, subnets, services, and so on. This single source of truth will help you with security, communicating with other IT systems, and network reliability.

Data model
Do you have a data model of your network, devices, variables, and relations? Only if you do, you have a basis for your Ansible or Python scripts, or whatever mechanism you select for automation. With a large number of parameters, having a model in place that represents the state of your network in a structured way is vital.

Not all essential information comes from your own database, but from other sources in your organization. So you need to think about a universal way to relate to those systems. It’s good to know that Ansible uses its own language, not the language from the network device, and has no API, you need a third-party tool or Ansible Tower for that.

Single point of failure
If you leave the organization tomorrow, no one will know about your solution. So you need to professionally document what you’ve built and have a versioning system in place. From my personal experience, this is something that almost never happens ;-)

Dynamic configurations
In an ideal world, you would like to retrieve state information from your network devices and use it dynamically in your jobs. How do you make dynamic configurations? Ansible playbooks are mainly static, so you need Python or Ansible Tower as an orchestrator.

Why reinvent the wheel?
I love to create new solutions. But when someone with the same problem already found a solution, then yes please, let me use that. One condition though: the last update should not > 5 years ;-). But that’s why I love the open-source community, sharing playbooks, scripts, and solutions. These shared solutions, however, are never really integrated into your own solution without you piecing it all together.

Make your Ansible and Python solutions more effective

So, to make your Ansible and Python network automation solution more effective, you have to think about all of the considerations mentioned above. My advice would be to look for a platform where your scripts are running in. This platform takes care of all non-functional things like logging, version control role-based access, approvals and system management features.

There are several options here: you can consider Ansible Tower. However, this has a steep pricing model and it lacks the integrated database. There’s also a free version but again, no database. NetYCE offers a free version of its platform and a growth path for Enterprise and Service Provider networks as it has many advanced functionalities like design modelling, an integrated database, collaboration, IPAM, and out of the box tools for compliance and OS upgrades.

A lot of the challenges mentioned above are already solved with the free version of NetYCE. Do you want to know more? Talk to one of my colleagues. They can help you understand more about the NetYCE platform and what it would mean for your specific network and the automation challenges you have. We want to hear from you!


Picture of Pieter van Os

Pieter van Os

Pieter van Os is a Solution Architect at NetYCE and loves helping people succeed with Network Automation. He has spent the majority of his career in the financial industry, gaining experiences in areas such as traditional networking, Python / PHP, and SDN. While network automation is his primary job function by day, Pieter also enjoys hiking, video games and reading books.