Like many of you, I’m a network engineer who’s made every automation mistake in the book. I’ve spent years writing scripts that, while clever, always ended up biting me later when someone else needed to run them. So today, I’m sharing some hard-earned lessons on how to stop being the “script hero” and start making network automation a team effort.
The Solo Automation Trap
We’ve all been there: you write a few scripts that make life easier, maybe save you a few late nights. They’re solid, they work… and they live on your laptop. Then what happens if you leave? A new engineer comes in, rewrites everything, and suddenly all your work is obsolete. The thing is, isolated scripts may get the job done, but they aren’t scalable, and they sure aren’t something you want to leave behind for the next guy (or for 3 a.m. you to troubleshoot).
The Move From “Me” to “We”
The goal isn’t just to write automations for ourselves but to make them accessible for the entire team. This is what we call “operationalizing” your network automation. In plain terms, it means taking scripts from one-man tools to team resources, so they’re there for everyone to use, not just the engineer who wrote them. But how do you get there? And preferably without having to deal with this operational nightmare.
Setting Up a Service Catalog
That’s where Itential comes in. We’ve built an automation service that lets you take those scripts and automations and turn them into a catalog — one that anyone on your team can use without needing a crash course in coding. Now, instead of being on-call every time Bob needs to run a script, he can log in, find the automation he needs, and run it himself. No more hand-holding, and no more babysitting scripts.
Role-Based Access Control (RBAC): Keeping Bob from Breaking Everything
Of course, not everyone should have the same level of access. That’s why we have RBAC baked in. With RBAC, you can control who gets to run what. Junior engineers can execute the standard stuff, while the more sensitive automations are reserved for the experienced folks. It’s about letting people contribute without risking everything because, let’s face it, nobody wants to be the guy who accidentally takes down the network.
Input Validation: Keeping Bad Data Out
Another big problem we see with team-wide automation is the risk of bad inputs. Let’s say Bob decides to enter “cat” instead of an IP address. (Bob, if you’re reading, nothing personal!) Itential’s decorator feature lets you set input validation so you can define what data can and can’t be entered. That way, your scripts won’t choke on invalid input and the network won’t go down because someone tried to get creative.
GUI vs CLI vs API: The More Options, the Better
One last thing that’s a game-changer: Itential’s flexibility between interfaces for my script. Some engineers prefer the command line, others need the GUI, and some just want the API. With Itential, everyone can get what they need, which means fewer people calling you to ask, “How do I run this again?”
Wrapping It Up
Operationalizing network automation means creating automations that don’t rely on you personally to keep them running. With a service catalog, RBAC, input validation, and all needed UI options, you can get everyone involved and finally make your automations scalable. And trust me, it’s way better than getting a call at 3 a.m. because someone can’t remember how to run a script.
To see all this in action, check out our Networking Field Day video below.
You can also give it a try yourself (or even get your teammate Bob to try it out). See here for details on the unlimited 30-day free trial.
Tags: Itential Automation Service NetDevOps Network As A Service Network Automation Network Engineering
Peter Sprygada
Chief Architect ‐ Itential
Peter Sprygada serves as the Chief Architect at Itential after serving as the Chief Technology Officer at Pureport where he was responsible for their multi-cloud network as a service interconnect platform. Prior to Pureport, Sprygada was a Distinguished Engineer for Red Hat, where he played the role of Chief Architect for the Ansible Automation Platform. Sprygada also held senior technical and leadership positions at Arista and Cisco, as well as several networking startups.
