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…
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
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.
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.
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.
- 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
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