The Paradox of Today’s Networks & Why It’s Time to Commodify Network Interfaces

The state of Network Automation today is a paradox. While extreme innovation has occurred within the network device interface space from the use of programmable constructs like NETCONF, RESTCONF, and REST APIs, many network domains continue to require manual intervention.

A successful network automation architecture

Historically, network automation has been thought of in silos with a heavy focus on scripting tools. These tools focus on a very specific set of capabilities that allow a Network Engineer to perform their job efficiently. As a result, this has allowed individual Network Engineers to create helpful automation scripts while creating many issues around standards or best practices as a side effect. Hence, today’s networks contain many automation ‘snowflakes’ which don’t align with industry or organizational standards, making it hard to consume and maintain as part of a comprehensive automation vision. A successful network automation approach allows for standards adherence and solution agility. The four core components of any network automation architecture should include:

1. Network Facing Interfaces – how we communicate with the network through a machine interface.

2. Network Context – metadata which allows automation platforms to make decisions regarding the network (Topology, Telemetry, Resource Manager, IPAM, etc.).

3. Automation Lifecycle – how we version control the automation system and the network focused on Infrastructure as Code.

4. Network API/Self Service Portal – intent-based interface which provides abstracted network concepts which can be requested by application owners or customers.

Network automation inefficiencies, evolution and innovation

It is essential that NetOps teams consider these components when creating a network automation strategy. However, the vendor ecosystem continues to be plagued by the need to connect to the library of device types and device interfaces produced by the industry. While we have advanced beyond SNMP to YANG and streaming telemetry, many configuration changes are still made via Command Line Interface (CLI). Vendors who maintain these librnetcaries spend a disproportionate amount of R&D in expanding and maintaining non-modern interfaces while passing the costs onto customers. When customers purchase such products that communicate with network devices they are paying for this R&D multiple times over, while also dealing with security and operational considerations of several similar systems talking to a single network element. Not only is this manual siloed approach inefficient, it is also complex and error prone.

One critical area of innovation has been the advent of the OpenAPI specification also known as Swagger. This specification was not born from a standards organization or planned for years by a set of networking vendors but evolved organically via user-community contribution. As we have moved from SOA and Web Services to general REST interfaces, the need to document and describe these interfaces generated the need for the OpenAPI specification. Conforming to the OpenAPI Spec is simple enough that most enterprise software and network equipment vendors are publishing their REST interfaces to ease consumption efforts for their customers.

Today’s modern networks are multi-domain which requires an automation strategy that would comprise of multiple programmable constructs and interfaces (YANG, TOSCA, YAML, NETCONF, REST, etc). Without combining automation with new innovations, organizations will find themselves paralyzed by the complexity of implementing and maintaining these technologies via CLI. By commoditizing the interfaces, operators can collectively focus on innovations and automations that drive towards an agile, modern network.

Thanks to the details provided in an OpenAPI specification, it is possible to generate an integration to any system with a published swagger interface. While it does require heavy lifting to augment the interface with robust capabilities around authentication, throttling, buffering, etc. (which is expected in Enterprise networks and application ecosystems), it pays dividends in the long-run for automating even the most complex of multi-domain networks. For organizations to achieve success with network automation, they must consider an automation platform that minimizes the effort of integrations and provides a self-service venue for anyone to build their own integrations within their multi-domain network.

Article originally published on The Fast Mode.