Late last year Adam Angell shared a very thought provoking observation on the Network Automation Forum Slack channel, part rant, part shared experience, part lament.
I want to quote a statement he makes that really struck me like a "Gibbs head slap".
For me it seems easier to go from a Software dev(eloper) to come into network automation rather than an network person to go into network automation automation. --Adam Angell
Of course it is! Network Automation is Software Development!! This post really started to put that into perspective for me.
We have done the networking community a disservice with the whole "netdevops" thing.
IF a network engineer figures out what "DevOps" is, it will look like some kind of strategy or a set of principles for software developers (typically coming from Cloud environments).
And they will say..."OK, that is not me"...and set the expectation that to adopt "netdevops" whatever that is, they have to become a software developer. Many network engineers went into network engineering to avoid software development!
There is no doubt in my mind that is a big reason why we have not seen more adoption.
Once you have this epiphany (Network automation is Software Development) you have two paths forward.
I've been on both.
Hire a developer
Over 10 years ago now, I was on a project with many delays but we still had to make the targeted implementation date. This was not an arbitrary date but rather the work we were doing needed to be done during a facility shutdown which had been on the books for some time. The shutdown dates were not going to change.
The only hope we had was to throw some automation into the mix. I've always loved programming but I knew my skills were not up to this task. Luckily management heard me and we were able to bring in a developer and I walked her through the logic and tested while she wrote the code. That strategy was incredibly successful and I learned a ton from her so the next time out I was better prepared.
The down side to this strategy was that she was not dedicated to our project so her automation work for us had to compete with her other projects. This works well if you can provide very tight requirements and specifications. It is important to keep this in mind if taking this route. Its also important to discuss ongoing support and maintenance.
DIY
Do it yourself.
One day you decide you are not going to manually piece together 50 access switch configurations in notepad.
So you start learning Python and become familiar with modules to help you automate your configurations.
That sounds pretty easy because I don't mention things like having to learn revision control, or the very basics of programming if you don't have that background, and using APIs, and Linux, and serialization, and virtualization, and so many other "side trips". Now you have paid your dues and the sky is the limit. You want to automate the application of your configurations so you become familiar with some frameworks that help you do that to one or more devices and then you .... and then ....
Make no mistake, this is a long road (and probably a loop).
Adam Angell shared his journey along with others and I encourage you to read what they shared firsthand.
That is how I learned and now I'm one of the "scripters" (not developers) that develops automation for our clients and for ourselves.
The network engineers who take this path (automation providers) will come to a crossroads at some point. Are they going to move more into software development and support or back off a bit with a better understanding of what they can and should automate and what they should delegate to a developer (if possible).
Its critical to understand that anything you write, you have to support, maintain, enhance.
I am there now.
This is the message we need to get out.
Not every network engineer needs to become a developer or a scripter but I believe every network engineer is going to need to be familiar with much more of the software development and server tooling to be successful in the future.
How much network automation stuff should I learn as a network engineer? This was my view in 2020 and not much has changed.
Adoption
There will be automation providers and automation consumers. We have to pay attention to the consumers. They don't have to write network automation but they have to use it.
Adoption within my team was difficult. Invariably they all fall back to the CLI even when they don't have to. Its a little infuriating.
Eventually a few of the network engineers recognized the value and understood they did not have to "code" but only use or execute this process. Executing a procedure is a well established pattern with network engineers.
Testing and Documentation (Documentation avoidance more like)
Every ITSM process has rigorous testing requirements. Anything you change you test. Lets be honest here, that can often translate to.."I am sure its working so I'll just test a few."
One of the things I love about network automation is that it gives us time to test every change on every device. Before, there would be "spot checks" but that invariably missed something. Now, if you don't use the script then you manually have to test on the 150 switches we just updated with full documentation. The beauty of this is that the team sees the resulting high quality of our deliverable and how it has minimized, if not eradicated, user issues down the line.
Translation: I am less likely to get called in the middle of the night and I don't have to spend so much time on the stupid documentation.
Brutal honestly here but that has really driven adoption.
So the network engineer has two choices. They can manually write the full as-built documentation package we have to deliver or they can push a button and have it generated in seconds (and the manual version will be rejected because it likely won't be up to the standard). Tip: Make your PMO a partner in adoption!
Uniform access to scripts so the entire team can use them
Another barrier to entry is getting the automation to the team.
We tried many options to get consistent environments out to the engineers.
These days, we set up servers where we can, so the network engineers are just using a centralized Web Based "tool".
In situations where the team needs local scripts we package them up using Streamlit or Solara so even locally the network engineer is using a web front end and that has proven very successful.
This can still be a challenge if you can't go the centralized server route. We have tried things like executables (non-starter), and purpose built Docker images. That is why I could not wait to get my hands on Torero which is specifically targeting this issue.
Final Thoughts
If we start thinking about network automation as software development, I think we can start to better understand the implications and ask better questions.
Its a little funny if you think about the current situation. We have actually been asking why network engineers are not adopting coding and software development.
We should be asking: Who should be doing the software development for our network automation initiatives?
We have brought in professional developers on occasion but we've not hired any full time ..yet. We have hired System Administrators to help run our servers. Make of that what you will.
Having said that, I do think network engineers who don't broaden their network skill set with some software development and server tooling will not be the best versions of themselves.
- Know Linux basics
- Know enough git to clone a repo and execute a script or launch a web page
- Know how to launch a virtual server or lab
- Know the basics of accessing data from an API
- Know data serialization formats like YAML and JSON
Personal Productivity vs Organizational Service
Looking at network automation as software development also shines a light on the level of impact network automation can have in your organization.
Network automation as personal productivity is great and many of us started there.
"Hey...get Betty to generate those configs for you. She has a script and can get them done in minutes!"
Network automation with organizational and business impact, that is, offering a service into your network, is a project which needs funding, marketing, and management backing just like any other software development project.
Joey: "Hey...we need to move this port to the new Temperature Reading IoT vlan. I guess we have to call the help desk and it will take days...."
Betty: "Are you kidding, the Networking Team now offers a self service port change portal. We can change it right now so we can finish this installation and testing!"
Lurk or Participate
I encourage you join the Network Automation Forum's Slack channel. You don't have to attend an AutoCon Conference to join. It is a chance to become part of a community that is rich in experience and opinions. It is a community which can either help, suggest, or just listen and commiserate.
On top of all of that you will learn alot about beer and ranch dressing.
RanchOps anyone?