Go back

Scripting Doesn’t Scale for Network Automation

June 28, 2017

Network automation has been the talk of town since my college days. In our CS research projects we were pressed to create automation scripts for the majority of the network tasks. Every test in the test plan designed to assess the software stability would end with, “Is this automated?”

In the last decade, networks have evolved and are more sophisticated – faster, smarter, and offer a wider range of services. Network automation becomes more of a necessity as the network grows.  But, in my humble opinion, the pace of automation has been slow, as many organizations are primarily using newer versions of the same old tools that are actually meant for exhaustion. There is a dire need to conduct faster diagnosis and isolate network issues more quickly, as well as to accelerate troubleshooting for specific applications or topology.

Scripting Doesn't Scale for Network Automation

As we know, enterprises today have overwhelming dependencies on their networks with many critical applications running on them. These networks, therefore, need to have amazing flexibility in the deployment of applications and should be more tuned to these applications than ever before. Indeed a lot has and can be done with the still prevalent network automation scripts including the use of PERL and TCL, but in a very controlled ecosystem.

Network engineers create scripts that typically run in their environment. These engineers write some scripts to automate network tasks and then a few more building a huge repository. The cost of maintaining these scripts rises as the resources needed to manage and store them grows.

Additionally, these scripts are not portable across multiple operating systems, CLIs, and distributed applications. For the most part, the shelf life of these scripts is limited, which means as long as the author or tribal leader stays within the organization or someone understands them well enough to take the ownership and maintenance. The bottom line is that the traditional scripts do not scale well for automating enterprise networks and come with significant costs.  Additionally, most DevOps tools (like Puppet, Chef) focus on configuration management, and, more importantly, the tools we use today for network automation were actually born out of the requirements for server automation.

Network automation today is approached from modest perspectives either because of the limitations imposed by the toolkit or a lack of desire to automate more advanced scenarios because of the complexities of programming for a network operator.

Writing clever regular expressions (regex) in Python, Perl, or Ruby is old-fashioned considering how sophisticated our networks have become and the traffic that runs on them. NetBrain has set out to make automation universal. Its vendor-agnostic adaptive network automation platform provides instant visualization and analysis of critical network data through programmable CLI automation and API integration. NetBrain employs a Dynamic Network Map as the single pane of glass for data correlation & analysis and Executable Runbook technology to digitize tribal knowledge, making it sharable and executable. Runbooks are fully programmable without scripts or the need to write regex. In addition, these Runbooks are self-documenting, meaning that all data captured during execution is stored inside the Runbook for easy playback and sharing.

To summarize, we just cannot afford to select any tool to automate the management of an enterprise grade network without having a deep understanding of its fundamental strengthens and integration capabilities with other tools in the network. Instead first take stock of your existing network components, scale and anticipated growth, and demands on your network. Then have a clear understanding of the service level requirements, such as, lower MTTR, five 9s of availability, and so on. This duo along with a sense of the budget will help you decide and consider making changes.

Related Content