Automate the modern network?
Software companies that build automation for network components have an assumption that traditional management platforms don’t apply to what is considered to be the modern network. Networks are complex and consist of many moving parts and ways to be configured. What does it mean to automate the modern network?
Innovation in this area has been lacking for so long. If you have the multi-vendor equipment and you can’t connect to all those devices then it’s hard to break into the automation space and the command line interface (CLI) will live a long life. This has been a natural barrier to entry for innovation in the automation domain. But now we have NETCONF and many other standard modeling structures that allow automation vendors to communicate to all types of networks such as brownfield networks, greenfield, multi-vendor etc.
These data modeling tools and techniques enable an agnostic programmable viewpoint into the network. The network elements still need to move to a NETCONF type infrastructure but we are seeing all the major vendors such as Cisco moving in this direction. Moving off the CLI and building programmable interfaces is a massive move for network programmability.
Generally, you have to use DevOps tools, orchestrators and controllers to do the jobs you have always done yourself. However, customers are struggling with the adoption of these tools. How do I do the jobs that I used to do on the network with these new tools? That’s basically what some software companies are focused on. From a technical perspective, some vendors don’t talk to network elements directly. This is because you could have over 15 tools touching the network and part of the problem is that everyone is talking to the network with their CLI. As a result, inventory out of date, network errors are common, CMD is completely off so the ability to automate is restricted based on all these prebuilt silo legacy applications. For automation, to work, there should be a limited number of elements talking to the network. Basically, with the advent of controllers and orchestrators, we are going to see a transition in the market.
If you look back, when we went from time-division multiplexing (TDM) to Internet Protocol (IP) address, the belief is that network automation will eventually have the same impact. The ability to go from non-programmability to programmability will represent the biggest shift we will see in the networking domain.
On occasion architects design something complicated when it can actually be done is a less complicated manner with an easier handover. The architectural approach is never modeled or in a database. The design process is very uncontrolled, yet the network is an important centerpiece to everything. There is a big use case to automate and control the design process. Automation is an actual use case that needs to be filled and there are various ways vendors have approached this. It’s not a fuzzy buzzword coming out of silicon valley. Intent-based networking? I’m falling victim to this myself too sometimes. Is intent-based networking a new concept?
I spoke to one vendor that was building intent-based API’s on top of OpenDaylight (ODL). There has been an intent-based interface there for the 5 years so to some it’s not a new concept. There are some core requirements for this to work. You have to be federated, programmable and modeled. Some have hijacked intent-based to a very restricted definition and an intent-based network has to consist of highly complex mathematical algorithms. Depending on who you talk to these mathematical algorithms are potentially secondary for intent-based networking.
One example of an automation architectural design is to connect to the northbound interface such as Ansible. These act as the source of truth for the components that are underneath their management. What you can then do is federate the application programming interface (API) and speak NETCONF, JSON, and YAML type. This information is then federated into a centralized platform that can provide a single set of API’s into the I.T infrastructure. So if you are using ServiceNow you can request through a catalog a task and that task will then be patched down into the different subsystems that tie together that service management or device configuration. It’s a combination of API federation data modeling as well as actually performing the automation.
The number one competitor of these automation companies are users that still want to use the CLI or vendors offering an adapter into a system yet these are built on the foundation of CLI’s. These adapters can call a representational state transfer (REST) interface but they can’t federate it. This will eventually end up breaking. You need to make an API call to the subsystem in real-time. As the networking becomes increasingly dynamic and programmable, federated API is a good solution for automation.