What’s Holding Network Engineers Back from Enabling Scalable Network Automation?

Network Engineer 1: “Alright, since you’re new to the team to get you acquainted with our practices, I’d like you to implement this change on 10 switches.”

Network Engineer 2: “Well, that doesn’t sound so bad. Seems pretty quick and easy. Sure, I can handle that.”

Network Engineer 1: “Excellent. That’s just the can-do attitude I was hoping to hear. You’re right, it’ll be really simple. I just need you to write up your change scripts, schedule it with the affected areas, submit a change request, and present your change to the approval board. I’ll get you the lucky rabbit’s foot before you head to the next meeting — it seems to help check the vendor website for any bugs.

Then, temporarily disable monitoring during the change, take pre change backups, re-up your car’s extended warranty, let the NOC know when what you’re doing and then, right before the change spin around twice. Hop on one foot three times and say the alphabet backwards. Make your change on all the switches, validate your change, re-enable monitoring, take post change backups, update documentation, close your change request and let the NOC know when you’re done.”

Network Engineer 2: “Whoa, that’s a bit more complicated than I thought. The actual change is such a small piece, how am I supposed to manage all that?”

Sound familiar? That conversation definitely sent chills down my spine when I heard my friends on the Art of Network Engineering discussing it on a recent podcast with Itential’s VP of Product Management, Peter Sprygada.

Enabling Scalable Network Automation

In all seriousness, this dramatized conversation resonates with every network practitioner in today’s fast-paced, multi-domain network environment. This is a world where even the most basic network changes come with long, multi-step, complex processes that must be followed. Even with automation scripts to help make network changes, the amount of time and effort that is spent on the manual processes turns a 5-minute network change into an hour or more process. As more and more changes are required to keep the network running on a daily basis, the increase in the time to accomplish network changes has created a tremendous backlog for the network team, who are tasked with both making changes quickly and keeping the network up and running.

The natural response is to turn to network automation to overcome these challenges. While that is true at the core, what network teams really need is a platform that can deliver scalable network automation for the enterprise. Network automation scripts are a great place to start, but they can only get you so far in the automation journey and teams soon realize that going beyond that comes with some hidden challenges that aren’t simple to overcome.

Three Questions to Ask Yourself When Choosing Your Automation Platform

This got me thinking. How can network teams make sure they choose the right platform to help scale network automation efforts? It boils down to answering three very important questions.

How much time is spent on a network change process?
Network engineers pride themselves on the ability to make manual changes quickly across a wide variety of different devices. The change itself may take minutes or even seconds, but how much time was spent before the change gathering data from an IPAM, opening a ticket in ServiceNow, waiting for approval, notifying the NOC, checking the device before the change. After the change is made how much time is spent checking the device to ensure old and new services are up, updating and closing the ticket, and notifying the various teams of the completion of the change? Any platform you choose needs to address automation of the network change as well as the process that comes before and after it, otherwise you’ll never escape backlogs.

How will your network automation integrate with IT systems?
In order to automate the before and after processes, the platform will need to integrated with all of the IT systems involved such as ServiceNow, IPAMs, Slack, MS Teams, monitoring, and more. Manually swivel-chairing between all of these systems to copy, paste, and replicate data is tedious, error-prone, and takes up a huge amount of time in a network change process.

Integrating with these systems is must-have in your automation strategy, and if the solution is to write code to integrate with every system you use today (and the ones you will use tomorrow), that means someone will be responsible with writing and maintaining integration code for every automation script — a very tall order and one I personally would never want to be in charge of.

How do you build guardrails into network automations?
Guardrails are necessary to prevent any potential network problems from occurring before changes are made and to ensure that if something doesn’t go according to plan (yes, it happens — thanks Murphy), it can be detected quickly and resolved immediately. Network automations must have very robust pre-check and post-check functionality that is easy for network engineers to create and understand. If network practitioners cannot build these functions themselves, complex network automations will not be possible due to a lack of trust and confidence.

If you’re searching for a way to get out of the world of network backlogs and into a solution that can help with these challenges and more, I’d like to invite you to check out this recent demo I gave to AJ and Tim from The Art of Network Engineering podcast. During this session, I demoed the Itential Automation Platform and showed firsthand how any network team can create network automations with robust pre- and post-check processes, integrate with other IT systems without writing any code, and even leverage any existing automation scripts you may already use.