How NetOps differs from traditional network operations
When comparing NetOps and conventional network operations, network teams focus on automating repeatable tasks that correct problems rather than introducing new ones manually.
The language of IT shifted in the last few years. Previously, NetOps was primarily used as a simple abbreviation of network operations. Now, its meaning has advanced to mean network operations as reimagined in the age of DevOps, and it is a topic of rapidly increasing interest to network administrators, managers and engineers.
At first, the term NetOps 2.0 was used to distinguish NetOps from the traditional, older meaning. Adding to the confusion, NetOps is also sometimes referred to as NetDevOps or DevNetOps, in order to focus on application development use cases and its ties to DevOps. Now, NetOps is simply shorthand for the rising new paradigm in network operations.
The problems with conventional network operations
Traditional network operations are too manual, change-averse and reactive, and the results are too fragile. The main goal of NetOps is to address these persistent problems.
Too manual. Network operations are too manual because most networking teams use minimal automation in deploying and maintaining switches, routers and other gear.
Too change-averse. Conventional network operations are too change-averse, in that current change control practices have the intended effect of making it difficult to modify the environment. For example, in a recent Nemertes research project, one participant said a configuration change could push out to all the switches in the network in less than 10 minutes, but change control could take months.
Too reactive. Finally, network operations are too reactive, in that most networking staff effort goes into dealing with problems -- often the result of a mistake in a manual configuration change -- rather than advancing strategic initiatives.
Legacy network operations practices evolved with the goal of minimizing interruptions to network services. This evolution is in the context of slowly changing service portfolios because the networks that grow out of these environments are too fragile to accommodate rapid evolution in services. As a result, making a change frequently means something breaks, which leads to long change management review processes, an aversion to change in general and the reactive nature of so much work.
How NetOps optimizes the network for change
NetOps aims to invert the problems with conventional network operations. Ideally, it helps NetOps teams more successfully accomplish the following:
make operations more automated;
be agile and iterative, not change-averse;
be anticipatory, not reactive; and
make the network resilient rather than fragile.
NetOps seeks to use more types of automation in network management. In some cases, it is the straightforward, ad hoc automation of scripting, with a new focus on scripting responsibly by using code management and setting tool and practice standards. In other cases, NetOps incorporates platform-based automation, such as intent-based networking (IBN). With IBN, declarative-style tools define the state a device should be in, while the automation platform does the work to reach that state.
In a true NetOps environment, network teams expect frequent changes in the environment and focus their attention on minimizing the possible side effects of change. They expect to use automation to launch new services in production after having refined that automation in test deployments and to continue to use automation to rapidly correct problems not encountered earlier.
NetOps makes the network more resilient by using automation to make deployments and updates to the environment more consistent and correct. It also enables iterative approaches when launching new services into production.
Despite the changes taking shape, two things are certain: The network is central to all aspects of operations, and network emergencies will still occur.
NetOps vs. the NOC: Either/or or both/and?
Will NetOps displace existing network operations centers and make them obsolete, or will it reshape NOCs to better serve current and emerging needs? Surely, it will be the latter.
Despite the changes taking shape, two things are certain: The network is central to all aspects of operations, and network emergencies will still occur. Without network services, business rapidly grinds to a halt for most organizations. Equipment and services will still fail, bad actors will still attack and unforeseen new problems will still emerge. Therefore, a role for full-time, rapid-response operations support -- in other words, a NOC -- will continue to be necessary.
But, with NetOps reshaping practices, NOCs will also evolve, mainly to become more automated. An old-style NOC will have a high-level playbook that staff can follow in the event of something like a ransomware attack. Those steps could include the following:
"When directed to by the security operations center, stop cross-talk among virtual LANs by changing these configuration items."
"Prevent access to central file stores by removing these web front-end servers from the load-balancer resource group."
A NetOps NOC will have detailed automation at the ready to enact playbook directives. Those directives can act as a wall of "little red buttons" for teams to implement changes as quickly as possible, in tested and repeatable ways -- with no fat-finger mistakes to make things worse rather than better. Teams might also enable a single "big red button" that can trigger execution of the whole playbook.
Ultimately, in a world of overburdened network teams, automation at the highest level is increasingly likely. In response to detected problems, tools monitoring the network will simply trigger the appropriate automated responses, while alerting the staff.
While most network teams are a long way from that fully automated response scenario, the rapid rise of NetOps is making its eventual implementation steadily more likely.
