In the current IT environment, all components, including the network, are virtualized and software-defined.
In a 2022 Nemertes Research study, 72% of organizations reported they already had or planned to deploy software-defined WAN as part of their WAN architectures. And other software-defined networking technologies, including SDN and software-defined LAN, are on the rise as well.
This shift means network operations (NetOps) is adopting practices and processes that have evolved from software development, particularly Agile methods and DevOps. This approach is commonly referred to as infrastructure as code (IaC), in which NetOps and DevOps concepts converge.
But what does it mean to deliver IaC? At a practical level, it means network feature enhancements and upgrades are handled the same way for network infrastructure as for software. A key element of enabling IaC is network automation, which is increasingly used to deploy and configure virtual switches, routers, load balancers and firewalls.
Network automation -- more than scripting
Network automation is particularly helpful in the context of resolving network problems, like traffic congestion and poor response times. In this context, it replaces traditional network change management. NetOps teams can modify the configuration of network components embodied in the codebase with network automation. Instead of using traditional network change management, the team uses DevOps capabilities, such as bug and request tracking, code management tools and automated testing of modified code, to ensure attempted fixes don't break anything.
Full automation vs. task automation
The distinction between network automation and traditional change management is worth a closer look. First, network automation is more than mere scripting. Scripting is a form of task automation, in which a script may occasionally run to eliminate the need for manual command entry. Network teams have traditionally created scripts to speed up tedious and repetitive tasks. But teams also limit the role scripting plays in their operations, generally relying on human intervention to launch scripts.
Full automation involves setting up a process and letting it execute autonomously. This means the team lets scripts call other scripts and allows scripts to respond to events without human review or intervention. The move to full automation versus task automation is one of the hallmarks of a network organization that is moving to a NetOps model.
Structured coding practices
A key factor in this migration is the shift away from a motley array of homegrown scripts to a more structured set of coding practices and tools from a DevOps-type environment. Trust in homegrown scripts is relatively low and for good reason: IT staffers may not know who developed the scripts and how. Most scripts are not well tested, can be easily broken and are incapable of handling errors gracefully. Tools written by other admins can be difficult to read, even if others understand the programming language in use and impossible if they don't.
NetOps addresses this cluster of challenges by adopting mature coding practices and tools. This includes a common set of coding tools and languages. It should also involve, in the least, minimal coding standards -- for example, naming schemes for variables and for created virtual entities -- that enable people to understand, trust and maintain each other's code more easily.
NetOps teams also manage network scripts in the same way developers oversee a codebase, using both a code-versioning system and code-level change management software that documents what a new version of code is supposed to accomplish.
NetOps requires automated testing. Whenever a revised switch configuration is pushed out, for example, teams must run a suite of automated tests against it to confirm it is performing and is as secure as required.
Benefits of a common tool base
To reap the same benefits DevOps teams get in terms of service stability and agility, network teams running campus networks and WANs have embraced a variety of DevOps concepts and practices and adapted them to the operation of a stable and nimble network.
Given the similarity of their goals and methods, it is natural for DevOps and NetOps teams to work together and share tools. For example, Jenkins and Salt -- two tools used for configuration management within the data center -- can be used for the network and network automation.
Using the same tools and languages can support cross-training efforts and even enable the circulation of staff among teams, strengthening IT overall. A common programming framework also simplifies troubleshooting and emergency response to network problems. Tracking application performance in the campus network can provide useful feedback on behavior and performance to DevOps crews.
Ultimately, the convergence of everything as a service and everything as code is fueling the advent of NetOps. And the fastest and most consistent way for a company to get value from this approach is to harness NetOps for its existing DevOps efforts.