Augmented Operations
Increasing the productivity of network operations
The old saying in tech, and perhaps all of life, is if you have a big problem, break it down into a bunch of smaller problems.
In a sense, we are seeing this play out in network automation/autonomy. If anyone comes to you and tells you they can automate and/or autonomize (is that a word?) your entire network, you should probably tell them to take their snake oil and go back to where they came from. If you want to be really polite, you can invite them to a POC where they can demonstrate their claims, and then you can send them packing.
Figure 1. Constraining the problem / breaking it down into smaller pieces.
There are at least three dimensions along which the automation/autonomy problem is being broken down/constrained:
Scope of network
Scope of capabilities
Scope of vendor neutrality / abstraction
There is a fourth important dimension, which is scale, but putting that aside for now…
Scope of Network
Constraining the problem to a single domain is one popular strategy.
There has been, for example, some interesting achievements in the wireless LAN area. Starting with the cloud-managed service era, now moving into the autonomous fault identification and resolution/escalation era. I am excited for what comes next here, across both networking and security. In a sense, SD-WAN has always had these achievements as goals, but as SD-LAN, SD-WAN, SD-Branch begin to merge, and SASE becomes more prominent, it will be interesting to see how this all plays out.
I have spoken to multiple companies that are focusing on data center as another domain. The variation and change to topology is often constrained, as are the scope of product types and suppliers. There is also, today, not a distinct optical networking layer. Scaling these solutions can be a challenge, however, scaling is something that tends to happen over time, when success follows success.
Scope of Automation / Autonomy
Even if we fall back on the old FCAPS paradigm, we realize there are many parts to running a network: fault, configuration, accounting, performance, and security. There is of course more in a modern NetOps world, not the least of which is running the automation/autonomy/CD/CI systems - the more automated/autonomous they are themselves, the better.
There will be vendors who say they are doing everything but are just AI washing. There will be vendors that are genuinely trying to tackle the breadth of the problem holistically. There will also be, I suspect, vendors that specialize in only slices of this problem for some time to come. Those vendors may well become best of breed in those slices.
Proportion of Solution which is vendor-neutral
I’ve seen many manager of managers/uber management platforms come and go in my time, so, with all my grey hairs, and occasional covid grey beard, I can sometimes slip into a little skepticism about multivendor aspirations.
The issues around business model I will leave for another blog.
Two multivendor by design issues that have emerged though are:
Constraining the vendor-specific stuff to as little of the software footprint as possible.
Constraining the solution to open, standards-based approaches.
Augmented Operations
I’ve written in the past about the entanglement between the network, operations, outcomes, and constraints. I’ve also written about augmented routing. What is clearly emerging, IMO, is a view of augmented operations. Just like the network itself, the journey to fully autonomous operations will not be overnight, and certainly not across the entire Internet.
Figure 2. Autonomous operations will mature along side autonomous routing
I am currently learning a programming language that is new to me, for a most likely hobby project. When you make the decision on what programming language to use, there are many considerations. Is there something about the language which is unique that strongly supports the core value proposition you are aiming for? Another is the vitality of the community supporting that language.
In my hobby project, I’ve had to ramp on the idiosyncrasies of the language and paradigm (this one having UI specific state as well as general application state), work through many gnarly design/architecture issues, and generally solve a lot of problems by myself. OTOH, the hobby project has progressed so fast to interesting functionality because of a) the base capabilities and b) the packages created by the community.
The thing about software is there is never really any end to it. The best software simply creates shoulders for someone else to stand on and survey a new landscape with new problems and opportunities. I have a feeling that augmented operations will be of a similar nature. I have no proof of this, there are not that many facts about the future known to me, it is just a gut feeling; a gut feeling that I believe to have some merit until at least 2025.
Conclusion
The industry is in the process of developing and applying workflows as well as learning about (machine) learning. It will be a while before the Internet is autonomous end to end. In between now and then, routing will be augmented, and operations will be as well.