top of page

Network Abstraction Is The Way Forward, Not Automation

Updated: 5 days ago



In our previous blog, Intent-based Infrastructure, we discussed the need to automate the entire infrastructure by translating the user intent into the desired configuration and abstracting the underlying infrastructure complexities. 


In this blog, we dive into Network Automation and discuss why most of the initiatives around network automation do not deliver the intended results. We also propose the right approach for managing networks, introducing concepts of network abstraction rather than the traditional automation approach. 


More than 70% of DIY in-house network automation projects fail. 

Source: FUTURENet World 


Introduction 

Network Automation objectives vary from organization to organization. For some, it is a means of doing things faster, while for some, it may be avoiding configuration mistakes. 


The N.1 cause of network outages is human error. 95% of network changes are done manually.  

Source: Cisco/McKinsey 


Command Line Interface (CLI) is still a very well-known and preferred method of configuring network devices by network administrators. CLI commands are passed over a persistent SSH connection to a network device; the device then interprets them and responds with text that is viewable by a network engineer on a terminal.  


Efforts have been made to script the CLI-based network configurations. However, since CLI does not return structured data, instead, it generates a raw text format; it is then the responsibility of the individual writing the script to parse that text to extract attributes. The script would break if any changes were introduced in the next version, forcing the parsing rules to be rewritten. Since SSH does not use structured, encoded data such as XML or JSON over the wire, the automation engineer has challenges with automation. 


Many vendors do offer an API that eliminates the need to parse raw text, as structured data is returned from a network device, significantly reducing the time it takes to write a script. Rather than parsing through text to find an attribute, an object is returned, providing exactly what is needed. Not only does it reduce the time to write a script, but it also provides a cleaner interface to test new topologies, certify network features, validate network configurations, and more. Unfortunately, all these are done manually today and are time-consuming and error-prone. 


The challenge is that the network device APIs are not extensively used in automation, and these APIs vary from vendor to vendor such as Arista uses eAPI, an HTTP-based API that uses JSON-encoded data, Cisco has Nexus NX-API, and Juniper uses NETCONF interface extensively. 

MetalSoft Network Abstraction 

Our approach towards automation has always been intent-driven. The intent of the network would be high-level service creation and not the individual tasks or commands that need to be executed on devices. End users or network admins should not be burdened with learning the syntax of each device and executing the same commands repeatedly.  

We first decouple the inputs (configuration parameters) from the configuration's underlying vendor-proprietary syntax (CLI). We provide an easy-to-use interface to capture the intent, abstracting the configuration parameters such as hostnames, interfaces, routing, and everything else from the users/admins. We then push the configuration onto the devices in a pre-validated logical sequence of API calls. 


MetalSoft Network Abstraction Approach 


With MetalSoft unified API, all the network topologies can be abstracted without the need to track the underlying device APIs, avoiding any configuration conflicts if done manually. 


MetalSoft Network Abstraction Advantages 

MetalSoft’s unified API can quickly aid in the day-to-day operations of managing networks. Rather than connecting to multiple switches and running CLI commands, network abstraction simplifies this process. MetalSoft platform hides the bottom infrastructure layers and exposes a task-oriented API facilitating the creation of services. 


Network misconfigurations cost businesses 9% of revenue. 

-Source: Titania Research 

Simplified Architectures 

Today, most network devices are configured as unique snowflakes (having many one-off non-standard configurations) , resulting in networks that are not only harder to maintain and manage but also harder to automate. MetalSoft network abstraction avoids snowflakes and enables desired network configuration with zero-touch. 


Deterministic Outcomes 

Using MetalSoft network abstraction to make network changes helps in achieving more predictable behavior than making changes manually, ensuring that the task will get done right the first time without human error.  


Business Agility 

By adopting network abstraction, the network engineering and operations teams have a single source of truth, facilitating quick application deployment. More importantly, it enhances the business's agility. 


Vendor agnostic 

With network abstraction, the network team is relieved from tracking vendor-specific changes in each release and avoids the need to relearn whenever a new device type is introduced into the network. 


Migrations 

Migrations may involve platforms from the same vendor or from different vendors. Abstraction can help in generating configuration files for all vendors giving a defined and common set of inputs. 


Having this type of flexibility helps with not only migrations but also disaster recovery (DR), as it’s very common to have different switch models in the production and DR data centers and even different vendors. If a device fails for any reason, and its replacement has to be a different platform, the MetalSoft platform can be leveraged to apply configuration immediately.  

Additionally, leveraging MetalSoft abstraction leads to a more predictable and uniform network. Abstracting the creation of configuration files, automating the creation of VLAN, or any other user intent streamlines the process for all users supporting a given environment instead of having each network administrator have their own best practices. 


Comments


bottom of page