Network automation has been around for a while, almost as long as there have been networks. It was easy to see as networks began growing that typing in everything via the command line interface (CLI) was just not going to scale. Enter the age of scripting. We all thought the end all be all of network automation had been achieved. We could now create repeatable automations for everything that mattered, right?
Well, not quite. You see, those CLI commands are such a small part of the overall process that automating them alone is almost not even worth the effort. Sure, if you are a network engineer operating in a vacuum with a tiny network and no one else is ever involved in either the planning or execution of changes, you are likely set. This works at home or if you are a small business with maybe a couple of routers, a server, and maybe 10 users max. Based solely on the fact that you are on a network automation vendor’s website reading this tells me this is not the situation you have found yourself in.
I am willing to go further and bet you have some subset of the following groups involved in network operations/ management: planners, change management, network engineers, a network operations center or other group that monitors your network, security engineers, network operations, and possibly many others. If you are a large enough enterprise, and especially a service provider, you probably have all of the above and more.
The reality is that in a typical network change process that spans weeks of time and 10-20 hours of effort overall, you are likely only addressing between 30 minutes to 2 hours of that total time with your scripts. On average, network operators implementing automation only end up addressing between 10% and 20% of the possible work involved. On top of that, there is usually no attention paid to when the process goes wrong. What happens when your script fails? Back to manually typing in the CLI is what.
Typical Software Upgrade Process
Real end-to-end network automation means looking at the following:
- How you assign human resources
- How you assign network resources
- How you schedule network changes
- How you complete change requests
- How you verify that the network is in a proper state to accommodate the change before you run that script
- How you verify that the change didn’t break anything after the change is made
On top of this, it means accommodating the 5 or 6 groups involved, and the 10-20 people in those groups actively engaged in the change, as well as the 5-10 systems those people have to login to make changes, reserve resources, update network monitoring, etc. It becomes obvious very quickly that this is way beyond writing a few scripts.
At Itential we have worked with network operators to automate everything from network device software upgrades, to service migrations, to service provisioning, and things as simple as port turn-ups and more. Our approach is to provide this full end-to-end perspective, integrating with all of those systems the operators use, and allowing the operator to realize the full potential ROI of network automation. We consider how to recover from failure conditions in an automated fashion as well, instead of the perfect path alone. Where customers have seen 11-hour processes turn into 10.5-hour processes with scripting alone, we have seen the end-to-end approach with Itential take that same process down to 45 minutes.
The bottom line? Scripts are fine, for what they do. The problem is they don’t do enough. However, don’t throw them away. Implement an end-to-end network automation platform that can leverage those scripts, integrate with your support systems, accommodate error conditions in an automated fashion, and deliver real ROI.
To learn more about the hidden costs of the CLI, click here to watch our on-demand webinar on How Current Automation Efforts are Incomplete & How to Rethink Your Approach.