Why should I even start a network automation journey ?

Well, I might know what you think. Despite all the successful automation efforts in other areas of IT, networking is kind of special – not only because of the massive blast radius if Murphy strikes. Being a seasoned enterprise professional you also know how ‘fast’ change really happens and that most internal computer and networking problems need to be approached at the people and process level, rather than throwing a piece of technology at it.
After all, box-by-box configuration backed up by occasional scripts or template one-offs has worked for decades now…

Updated 09/2021 – New section about process documentation

But don’t you wonder why your incumbents sales rep proudly uses words like REST-API and Python SDK more often lately ? Or, did you notice the exponential footprint of the DevNet Zone at CiscoLive over the last few years ? Why does Juniper sponsor an open project like NRE Labs, to teach basic programming skills and tools ?

Change might be real this time and it might also happen at an unusual speed. At least more than IPv6 in the enterprise … 😉

First things first

So lets get this out there straight up front:
Knowing an ‘industry standard’ vendor CLI won’t be enough anymore!
(And believe me, I’ve had this discussion several times over the last months)

No matter how good you are at handcrafting your configuration, how many nerd nobs you might master or how fast you troubleshoot the unintended features of your current networking platform.
The demands in the new era will be quite different. There is a good chance that the job role of a network engineer will be replaced by something more general, like an Infrastructure Engineer with broad knowledge about the whole IT stack, going deep on only one/two topics.

The reasons why

  • Complexity
    You will need to do more with less.
    Networks are getting more complex. Not only by the number of devices managed, but by adding more and more layers of abstraction, overlays being the obvious one. There is a healthy trend to simple and robust L3 networks by pushing services back into the application (service mesh) or into the edge (SD-WAN / 5G / SR …). But this can take many, many years to become a common phenomenon, especially in the enterprise space.
    In the mean time there is a need for tooling to support those challenges.
  • Speed
    You will need to do it faster than today.
    Folks get used to the cloud consumption model and you will definitely hear questions like “Why does this XXX thingy take two weeks to complete ?” or “Is there a portal where I can provision the Switchinterfaces myself ? – I know my VLAN, dude !”
    At this point you can default to justify the processes and explain how special networking is. Or make new friends and answer “Challenge accepted !”. Try to automate some simple tasks away and make them easier to consume – direct benefits for your and other teams.
  • Reliability
    Gain consistency and repeatability
    When was the last time you fat fingered some configuration, followed by hours of troubleshooting a few days later ? There may be also colleagues at your team not exactly following the committed configuration templates in your Team-Wiki (or even worse, Word/Excel-Spreadsheet) ?
    It is in the nature of automation to avoid these problems and gain consistency paired with repeatability of day to day tasks.
    Plus: If you use git(lab/hub) as source control in an advanced stage of your automation journey, the documentation and versioning challenges disappear in the smartest possible way.
  • Process Documentation
    You can only automate what you know
    Surprisingly, an accurate, consistent description of the processes that are to be automated is often missing or hidden as operational knowledge in people’s minds. So, it is often the first time that we think about which input parameters must be known, which steps have to be taken in which sequence, and if dependencies may exist on other tools or teams – and finally document them.
    An obvious win, and not just in terms of automation efforts. Just think about onboarding new employees.
  • Ownership + Flexibility
    Automation tooling ultimately enables some kind of abstraction layer to become more vendor agnostic. You can model the ‘business needs’ in one or few central places on a higher level, instead of distributing it all over the place via box-by-box CLI configuration. This facilitates a multi vendor strategy or platform changes, especially in the light of mature open-source API solutions like Napalm.
  • Time to innovate
    Nobody gets replaced by an ansible playbook, period!
    Data models and automation stacks need to be maintained like every (distributed) software system. Although this is quite a paradigm shift, network engineers are smart people, so there is hope! From my observation, it’s easier for a network engineer to learn some programming skills, then to equip a full blown developer with decades of networking scars experience.
    And for the first time in years there is also a good chance to free up some time for innovation. So, refresh networking fundamentals, learn new skills to iterate over your tooling or leave the comfort of your silo and understand the needs of adjacent infra teams.
    Lucky you, if your organisation has in house developers. Buy them a beer and talk about the possibilities if someone would be able to represent the infrastructure as code …


The big elephant in the room is a counter argument about automation being nothing more than the ability to blow up your whole network with one keystroke.
Fine, that is true and you definitely need to understand what you are doing! That’s what is meant by saying “Know your fundamentals!”.
But by approaching the network in a more programmatic way, you are also able to build automated validation tests against your changes (aka code).

Finally, I would like to point out that automation is not only a question of device count. If there are frequent changes on a small network or if only your NMS lacks some important information regarding day2 operations => go for automation as well.

It is possible to start very small, get comfortable in the mindset and build upon that foundation. Nobody uses a fancy CI-Pipeline on day one to simply change a ntp-server on a bunch of network devices. Plus: You’re not alone, there is a strong community of fine people out on the Interwebs, helping each other to master this transition.

The next post will cover one of many possible ways to get started, so stay tuned …

Headerimage by freepngimg.com

2 thoughts on “Why should I even start a network automation journey ?

  1. Are you a hand-ons network engineer? or you are just copying whatever those “opinion leaders” are saying?

    1. Oh yes, I am a real network engineer, with lots of scars … 😉
      And I don’t give much about those ‘opinion leaders’ you might have in mind.
      What I write about is experiences made in our team over the last 2-3 years with regards to automation, IaC and so on.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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

This site uses Akismet to reduce spam. Learn how your comment data is processed.