Democratizing Network Automation – Why Scripts Can’t Scale

There is a sense of safety and comfort in continuing with a routine that you understand. For many network engineers, scripting has become one of those safety blankets, a staple to accomplishing everyday responsibilities. These scripts (bash, python, perl, etc… ) evolve and grow over time as additional methods are tacked on to address new needs, and issues created by vendor and technology changes require them to be reworked. I’m sure most people can relate to that holy grail script hundreds of lines long for x,y,z tasks that promotes a sense of pride and accomplishment to the contributing engineers. These scripts absolutely have their place and deserve recognition for the tasks they have been able to automate and the time they have saved teams. But the time has come where we need to admit that scripts used for automating a few tasks, just can’t scale. And quite frankly, they’re not the same as automation.

Why Can’t I Just Keep Updating My Scripts?

Change is a difficult pill to swallow, so let’s review some compelling reasons why traditional script-based automation is no longer the answer to all your network automation needs.

• Managing, maintaining, and testing home-grown scripts is becoming more complex and time consuming. As networks become more dynamic, static scripts are requiring more attention in order to accomplish the jobs they were built for.
• Scripts do not provide interactive fallout handling, requiring manual ‘stare and compare’ error remediation and time spent re-executing the failed script.
• Lack of integrations with other systems such as ITSM or DevOps creates segmented network changes that involve difficult swivel-chair between systems and across teams. This narrow focus of only automating the network change ignores the 80-90% of effort required to complete changes supporting operational processes, pre/post validations, compliance checks, and other multi-domain cross-team tasks.
• Scripts are not agile. They won’t automatically make decisions based on discovered configuration changes because they lack the network intelligence to understand the innerworkings of your network.
• Scripting lends itself to proprietary knowledge of script execution and maintenance being confined to a single person or small group of engineers. This presents a risk of losing this knowledge when faced with organizational changes.

You may be looking at this list thinking that you’ve moved beyond these script-based automation issues by adopting DevOps/NetOps tools like Ansible, Puppet, or SaltStack. These tools ease the pain and provide automation capabilities at a larger scale, but still require an investment of time for learning their own idiosyncrasies, to gain expertise in other languages (such as YAML), and are still verticalized to only address the network change execution ignoring the operational end-to-end procedure. Since network teams cannot afford to have every team member spend time on ramping up their skills to reap the benefits of these tools, let alone rip and replace their existing script-based automations, this lends itself to a single or minimal experts in a team responsible for creating these ‘automations’.

How Do I Survive Without My Scripty-Blanket?

Ultimately, you need to be able to accelerate the learning curve for these new tools and be able to democratize them across entire teams for true end-to-end automations. Luckily, you can accomplish this without having to throw those scripty-blankets in the bin and start anew! At Itential, we’ve lived through these pains and have worked hard to provide a way for your teams to be able to leverage existing investments and learned skills in a modern approach to true end-to-end network automation that doesn’t ignore the other 80-90%. This “Bring Your Own Automation” for harmonizing scripting and new technologies is imperative in order to keep up with growing business demands, adapt to a rapidly changing network ecosystem, safeguard against scripting errors, and reduce operational expenses attached to the repeated work that comes from a lack of automated operational + networking procedures.