Natural language and network management

Network management has been the problem child of networking for decades. The whole notion of managing a heterogeneous set of devices and software from a single tool was going to be difficult at best. The companies that tried to rise to the challenge quickly learned that staying current with other vendor commands and configuration was nigh impossible, never mind the fact that no vendor wants to cede control to someone else.
The industry basically decided that we would collectively pursue more open solutions. But while we all debated what the open solution would like, it seems the rest of the world went and changed the user interface on us. 
Pinpoint control
Perhaps there biggest bane for most things management-oriented is the fact that the practice of networking has evolved such that operators manage through pinpoint control. To make a network function correctly, network engineers have to specify thousands of knobs across thousands of devices. 
While it is true that every bit of configuration and functionality that we have added over the years was justified in isolation, we have inadvertently created a discipline that requires a PhD in the Dark Arts. I am not saying that certifications are not worthy pursuits, but how much of certification is dedicated to rote learning? To be fair, based on the configuration and management burden, is there much other choice?
Industry thought leaders basically conceded a while back that this wasn’t going to be a viable future for networking as a whole. We started to see various efforts to abstract network configuration. The early Puppet integrations, for example, included abstractions for edge policy constructs (like VLANs, for instance). Those abstractions were extended to other similar tools and built on as configuration templating tools became all the rage for a few years.
But the industry wanted more.
There were promises that things like Group-based Policy (or OpFlex, depending on who you believe) might introduce standard edge policy abstractions that would simplify networking for everyone. Well intentioned, no doubt, but I suspect you would be hard-pressed to find a lot of network engineers among the unwashed masses who have heard of these, much less actively use them in production.
And then of course, we saw the Controller Wars in the post-SDN world. But even here, the emphasis has been more about serving as an API broker, translating in and out of NETCONF. A useful role for sure, but still not really solving the industry-wide edge policy abstraction problem. 
Open as an impediment
It’s a bit sacrilegious to say this, but part of the problem with stuff like this is that open becomes an impediment to progress at times. Now, before I get taken to task as anti-open, I will say unequivocally that all things being equal, open is better than closed. 
But when progress is left to a group of people, each with their own personal and corporate interests to protect, we move forward at the pace of…well, a group of people. We have known this for years in networking circles. Many of the standards bodies move at a glacial pace (or slower, if you consider the effects of climate change!). It turns out that building consensus is hard. And for things like protocols, where interoperability depends on this stuff, that slowness is the price you pay for an Internet that works. 
But for policy expression? Workflow expression? It seems an unnecessary tax.
The cloud agrees
For what it’s worth, the cloud companies basically agree. While we all sat and talked about this, they just went and made it work in their environments. We have seen things like gRPC and OpenConfig emerge from the cloud side first, forcing vendors to snap to what their customers want.
Of course, not all the cloud companies agree on what the answer should be. But they are in a dominant position as high-volume consumers of equipment. They can dictate their individual terms without a consensus. And the vendors have to play a game of chicken if they want to stare down the CSPs. Frankly, it’s a terrifying position.
Semantic separation
It seems obvious that the industry is kind of done waiting for standard abstractions. What’s more valuable at this point is using tools to create semantic separation between the workflows and the devices. It doesn’t matter so much what the policy expression looks like so long as how a policy is expressed does not require specific configuration or command syntax on the device. 
We see this in things like ChatOps already, where a tool like Slack or HipChat basically funnels commands to a workflow engine responsible for translating those commands into whatever device imperatives are required. The important bit here is that the translation is not vendor-driven. 
When users take control of policy and command expression, they can decide how they want to initiate workflows. This allows for things like natural language. What ends up emerging is a bit like networking pidgin. You get a mashup of networking terms and common expressions. It’s a bit like Spanglish, but for IT.
Of course, for anyone who has looked at how natural language is used in other interfaces, it’s pretty disappointing. Basically, you just map a bunch of phrases to commands on the back end. But if the industry cannot settle on what those mappings ought to be, then users will eventually take it on themselves. 
The bottom line
It will be interesting to see how a change in dominant interface will shift how we think about all of this. Despite the efforts to make APIs the primary means of interacting with the network, the dominant interface is still the CLI for all the non-DevOps shops. The rise of controller-based management has brought some stronger GUI support, though primarily to service providers. And technologies like SD-WAN are proliferating cloud-managed systems, which will tend towards GUI as well. 
If the next era in interfaces shifts to voice as some predict, it will force an acceleration of natural language mappings. While I doubt that would make a meaningful difference in the speed of standardizing on abstractions, I do think it will lead to a different set of tools that emerges for mainstream networking. And that just might bring the step-function improvement in managing networks that has been desperately missing for decades.

Top Kudoed Authors
User Kudos Count