with safety.3D rendering

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 until now with ansible automation. If you have 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 Red Hat Ansible Automation, 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.  

 

Ansible Red Hat

Diagram: Ansible Red Hat: Automation DevOps.

 

 

  • DevOps Tools

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 is out of date, network errors are common, and 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.

 

  • DevOps vs Traditional

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 in 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?

 

Ansible Automation

 

OpenDaylight (ODL)

I spoke to one vendor that was building intent-based API 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.

OpenDaylight (ODL)

Diagram: OpenDaylight (ODL): Network Automation.

 

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 types. This information is then federated into a centralized platform that can provide a single set of APIs 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 CLIs. 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 networking becomes increasingly dynamic and programmable, federated API is a good solution for automation.

 

red hat ansible

Diagram: Red Hat Ansible: Link to YouTube Video.

Comments are closed.