Scripting Can’t Keep Up with Today’s Automated Networks

Large organizations looking to make quick changes to their networks are in a tight spot. They want to prevent the expensive outages that occur due to unforeseen issues, but they need to move at market speed. Though the market offers many open-source scripting approaches to network management, these quick fixes are not reliable over time; a longer-term solution is needed. In addition, these options can be risky because of the possibility of downtime. To ensure business continuity and competitiveness, enterprises want a better way to automate, remove complexity from, and make changes to their networks.

Agility, Complexity, and the Need for Automation

With the goal of improving agility, enterprises are on a mission to reduce complexity — including lengthy lab testing and implementation cycles. The end goal is a platform for competitive business innovation with policy-driven, intent-based principles. In addition, network virtualization, SD-WAN, and other new shifts in networking mean the Network-as-a-Service is no longer predictable.

Technology fluctuations like these are making DIY coding and scripting obsolete, since both are still locked into a static model of the network. Instead, coding and scripting should be maintaining the stability of core business while evolving the network as new initiatives are added dynamically. It’s the network itself that represents the living, evolving business — not the static-scripted or manually configured model. Months of learning, customizing, and testing can’t keep pace — even more so, they’re no longer even needed.

What enterprises need instead is a network knowledge base that can deliver automated remedies, updates, and alerts for configuration and ongoing maintenance and management. This is why intent-based networking is resonating in the industry; validation of business intent, automated implementation, awareness of network state, assurance, optimization, and remediation are all required for the modern network. The question is how to get there quickly and efficiently.

Say Goodbye to Scripting

It’s clear why enterprises would want to automate their networks. There are many reasons why writing scripts is, ultimately, not the solution.

Unlike telecom protocols, Python scripts are not standardized and typically don’t use best practices nor scale in a multi-vendor network. As business intent evolves from new initiatives or acquisitions, scaling the network becomes critical. Scripts are notoriously difficult to adapt to new vendor systems and may inhibit cost-savings.

At best, home-grown scripts provide a one-off, static network configurator for a fixed point in time. Home-grown scripting, unlike code, cannot self-adapt to new environments, be programmed to interact with network state, nor operate as a machine-learning platform. As the network changes, the scripts must be updated and re-tested to manage any underlying knowledge base while polling the changing state of network resources. Even without the training, script testing, bug fixing and maintenance, the user is left with an approach that is stagnant and must be re-scripted manually and continually. If a user wants to make the network policy-driven, they must hire or contract further scarce resources to write, test, and maintain custom software.

Some enterprises have tried DIY scripting from generic playbooks or templates. However, that approach requires customizing integrity tests, introduces the same high-risk maintenance issues and testing delays, is unresponsive to policy change, and still requires trained skills and customization. Unlike open source web platforms, these templates are not backed by massive communities and have the potential to damage the enterprise operation.

To reduce risk, enterprises that use scripting must create their own compliance testing software. Compliance automation requires ongoing audit and action to validate the actual network state, ensuring compliance to policy. Even after updating and re-testing scripts, there is no guarantee that problems have been fixed — or that new problems haven’t been introduced.

Personnel changes add additional complexity when using scripting. As staff change, the cost of either repeated training or poorly documented scripts creates a cycle of re-creation. Scripts not well understood by new staff tend to be disposable and are replaced, introducing additional testing and, ultimately, more risk.

Stacked up against compiled, optimized code, interpreted scripts are plodding and clunky. In large configurations, this can impact availability and maintenance periods as the scripts update networks and are subsequently tested. Enterprises are looking to speed operations, and dynamic, automated changes may make the concept of large-scale network maintenance almost disappear.

The Switch

Enterprises need to move at the speed of innovation. This requires a new kind of network, one that is responsive and automated. That means the standard operating procedure of relying solely on scripts, lengthy testing, and re-testing just won’t work anymore. It cannot support the intent-based, rapidly moving, and changing network that enterprises are shooting for. Adaptability and flexibility are the goals, necessitating a switch from traditional scripting.

Olivier Huynh Van is the CTO and Co-founder of Gluware and leads the Gluware R&D team. Olivier has spent 20+ years designing and managing mission-critical global networks for such organizations as ADM Investor Services, Groupe ODDO & Cie, Natixis, Oxoid and Deutsche Bank. He holds a Master’s Degree in Electronics, Robotics, and Information Technology from ESIEA in Paris, France.