Numerous open-source scripting approaches to network management are currently available in the market. While promising, they may prove to be a high-risk trap for enterprises looking to automate, remove complexity, and make changes to their networks quickly. While instances of expensive network outages are usually kept under wraps, enterprises must be aware of these hidden issues and look away from traditional scripting to achieve an automated network foundation that ensures business continuity and innovation.
Reducing complexity and improving agility: Drivers for automation
Enterprises are trying to reduce complexity – including lengthy lab testing and implementation cycles – in their networks to improve agility. 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.
These dynamics are beginning to obsolete scripting and home-grown coding because both are still locked into a static model of the network rather than 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 not only can’t keep pace but are actually no longer needed. Rather, enterprises need a dynamic knowledge base of the network 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 fast and efficiently.
Why scripting isn’t the answer
There are several reasons why writing scripts is not the answer for enterprises looking to automate their networks:
- While python scripting is a compelling upgrade to slow, manual processes, unlike telecom protocols, 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.
- 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. At best, home-grown scripts provide a one-off, static network configurator for a fixed point in time. 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 static and must be re-scripted manually and continually. If a user wants to make the network policy-driven, he or she must hire or contract further scarce resources to write, test, and maintain custom software.
- DIY scripting from generic templates or playbooks is another approach that seems promising. However, it 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.
- With scripting, the enterprise user is left to build compliance testing software to minimize enterprise risk. Compliance automation requires ongoing audit and action to validate 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.
- Scripting can be problematic when there are staffing changes in the enterprise. 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.
- Interpreted scripts are slow and inefficient when compared to compiled, optimized code. 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.
To operate a responsive, automated network, the existing model of static scripting, monolithic testing, and training maintenance does not support the type of fast-moving intent-based, networking that is becoming the goal of the modern enterprise. To build a foundation that keeps the business evolving and competitive, enterprises need to move away from traditional scripting and towards more intent-based automation.