Four years ago, I wrote about the 2016 NetDevOps survey. Back then, I was starting my journey into network automation, and I looked at the data for answers on where to start and what tools to use. Now, in 2021, I am a lot further along that journey, but I'm frequently helping people finding answers to their questions on getting started with automating their networks. So it's a good thing to for me to occasionally revisit my thinking and see if the same answers are still are valid.
2020 NetDevOps Survey
So last week the results for the 2020 NetDevOps survey were published. As before, the source data is all in the open for us to look at, but this time I'll just go through the report to see if I can answer my two fundamental questions:
- What tools do I need to learn?
- What should I automate first?
The usual caveat applies: this is an internet survey held in a self-selecting community of people interested in network automation. So you can't read this as representative of the networking world as a whole, but it does provide insight in the tools and methods that people in the NetDevOps world prefer to use.
All the graphs I use in this post are lifted straight from the GitHub repository, with just some minor editing from my part.
Are we there yet?
First things first: does it still make sense to start with NetDevOps, or is it too late to get onboard the automation train? We've been talking about automating networks for a long time already, and if the industry is maturing than it would be a good option to just buy something off the shelf since it will be too hard to catch up.
To answer this, I'll refer to my own maturity model for automated network operations. I see it as four stages of development, each with its own goals, tools, and processes:
- Individual scripting;
- Shared tools and processes;
- Infrastructure as code;
- Autonomous operations.
Pretty much every automation journey starts with individual operators creating scripts to automate their own work. The end goal (for now) in my eyes is a network that practically runs itself, with self-service for end-users and auto-remediation of errors and faults; a "self driving network" if you will. So are we there yet?
Take a look at these two graphs. Only about 11% of respondents are far enough in their automation journey to disable CLI-access to their equipment and implement some form of unattended configuration deployment. So no, we still have a long way to go.
What are we automating?
So we're not automating all the things, then what are we automating? Like in 2016, mostly configuration-related tasks (generation, deployment, and archiving) are automated, with data collection/reporting a bit behind that and other tasks significantly less often.
This makes sense, since as network engineers a lot of our work is modifying and deploying config and would therefore automate that first. However, I usually advise people to start with data collection and pre/post change checks. As read-only operations they are a lot less risky and complicated to start with, while still being very useful in day-to-day operations. It might not be as much of a time saver as automated config management, but you can definitely improve the quality of your work and demonstrate value to other stakeholders.
Tools & Languages
Let's take a look at the tools that we're using to automate all that configuration management.
Clearly, Ansible is still king of the hill, even more so than in 2016. The people at Ansible have spend a lot of effort in making networking a first class citizen in the past couple of years, and clearly this is paying off.
There's clearly still value in internally developed scripts. Tools like NAPALM and Nornir are gaining traction but are still a ways off from Ansible's market share.
Another key point is the lack of enthusiasm for vendor specific tools. The "buy vs. build" decision is heavily falling down on the side of "build" for the people in this survey.
Like in 2016, Python is the programming language of choice for network operations. I agree fully with this: there are plenty excellent networking related libraries for Python, and many free "Python for Networkers" tutorials to be found.
Shellscript is also in common use, which is a testament to the pervasiveness and usefulness of Linux. If you're a network engineer and you're not comfortable with using Linux: time to get yourself a Raspberry Pi and start learning. The Netbeez blog is a good place to start, and Cumulus has a nice free book.
Writing all this, it strikes me that not much has changed in the survey responses between 2016 and 2020, even though the NetDevOps community and the tools we use have matured significantly in the past few years. Ansible, for instance, has become much better at managing network equipment. A much higher percentage of network equipment in production has a sensible API to avoid screen scraping. But the fundamentals I learned five years ago (Python, Git, YAML, …) are still very much useful and will remain so for a long time.
While obviously the best time to start learning network automation was yesterday (or 2016), the next best time to start is right now. And to end this with a bit of good news: most of us learned this on our own, and can call ourselves a fully qualified network automation engineer within 2 years.
So if you're not yet comfortable with network automation, there's no reason not to start learning. Fire up your favorite search engine, or hit me up on Twitter if you need some pointers to get started. And next year, you can fill in the NetDevOps survey to say that you've used Ansible to automate your network configuration management just like the rest of us.