Enterprises could find themselves dealing with more than they bargained for as they make the move to an automated network. In their desire to reduce complexity and quickly make changes to their networks, they come across many open-source scripting approaches to network management on the market. Though these approaches have their benefits, they are not effective long-term solutions. The variety of vendors, operating systems and hardware platforms used in the networking layer also makes scripting difficult. Such scripts can also lead to costly network downtime. What can enterprises do instead to achieve the results they need to stay ahead of competitors?
RELATED CONTENT: Network automation: To plan or not to plan is the question
Lengthy lab testing and implementation cycles are just two aspects of today’s network complexity. Enterprises are trying to reduce such complexity 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.
Scripting and homegrown coding are still locked into a static model of the network that is being made obsolete by the above shifts. Instead, they 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 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 quickly and efficiently.
The trouble with scripting
Though scripting has traditionally been a useful method, there are multiple reasons for not using this method today. To start with, homegrown 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, homegrown 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.
When organizations use scripting, they must also build compliance testing software to minimize enterprise risk. 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.
It is true that slow, manual processes can be overcome with Python scripting. However, 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.
Some organizations believe that homegrown scripting using generic templates or playbooks is a promising approach. However, this 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.
Code that is compiled and optimized wins out over interpreted scripts, which are slow and inefficient. 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 a thing of the past.
Finally, employee turnover can create issues regarding scripting. As staff changes occur, 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.
Fast-moving, intent-based networking is becoming the goal of the modern enterprise. An automated, responsive network cannot work if it is bogged down by the current framework of monolithic testing, static scripting and training maintenance. The reasons listed above describe why enterprises must abandon traditional scripting for the agility that automation creates.