The Increasing Importance of Using APIs for Network Orchestration and Automation

Blog #1 in a Series on APIs from the ONUG O&A Working Group

We have all clamored for programmatic control and more intelligence in our networks and applications for years. We want to automate high-value repeatable tasks to eliminate toil in our programming world. In response, software developers released Application Programming Interfaces or APIs, essentially, more code to control their original code or application. The good news is we have programmatic control for automation! The bad news is there are almost as many ways to go about implementing an API as there are software developers (okay, this may be a bit of an exaggeration). In this blog, we will look at common API uses, why automation is becoming so beneficial, and outline some of the opportunities and challenges of implementing API-driven automation.

Let us take a look at a practical use of automation that many of us have already experimented with – home automation systems or devices. The interaction with Alexa in our house is a prime example of consuming an API. We say “Alexa turn on bedroom lights,” and the smart lights in our bedroom turn on. Wait, I think we just used about five different sets of APIs. We have the device, Alexa, who takes our voice and sends API commands to somewhere in the cloud. These, in turn, invoke commands on our smart hub, which then changes the state of our hardware to turn on the lights. When provided for us as a packaged service, this automation seems fairly easy to implement, but what if you had to write this automation all on your own?

Prior to the release of infrastructure hardware that had API interfaces, engineers relied on configuring features of devices such as network switches and routers by hand, via a Command Line Interface (CLI) or a web-based user-interface (UI). These interfaces required tediously creating configurations one line at a time, which has been the norm for the last 20 years! Experience, however, has shown us that doing things by hand was extremely time-consuming, not to mention prone to human error and configuration inconsistencies between devices. These issues highlight the key benefits of creating code that controls code, aka APIs. By contrast, API-driven automation can configure thousands of devices in minutes without introducing errors or configuration inconsistencies.

Automation for application development was adopted by software engineers back in the late 1990s, in the form of DevOps CI/CD (continuous integration / continuous development) when development moved away from the mainframe and became distributed. This led to the creation of many different purpose-built software automation tools in the marketplace to help application developers. However, it has only been in the last five years that network developers have begun to utilize automation tools, mimicking the application developer’s software, to automate their network infrastructure. Terms like Infrastructure as Code (IaC) are becoming popular with network teams as they begin to emulate some of the practices that software engineers have used for years. The network teams are also beginning to evaluate and select network infrastructure hardware, in part, based on how easily it can be programmatically configured via an API.

Many organizations are building centers of excellence teams or automation teams made up of network, server, and security team members to accelerate the adoption of automation. These teams are typically responsible for designing and implementing the overall automation strategy for the organization, across many different technologies and manufacturers, as well as educating network engineering and operations on how to use this newly designed automation. Whether IT infrastructure teams are part of a company’s “digital transformation” efforts or just under a mandate to “do more with less,” infrastructure automation has become a goal (sometimes a dream) for many enterprise organizations. One of the biggest challenges companies continue to face is finding individuals with the correct skill set to drive the development of automation for network engineering and operations.

To combat the challenges in dealing with complicated networks and difficult programming languages, several low-code / no-code software options have become available for creating automation utilizing API features found in modern network infrastructures. This software provides network and operations automation teams with a means to automate infrastructure in a way that is similar to the application CI/CD pipelines without requiring an extensive background in development. The software enables operations and engineering personnel to create Infrastructure as Code without having to learn a programming language first, accelerating a company’s digital transformation efforts and satisfying the “get-more-done-with-less” demands. These low-code / no-code applications also help normalize a somewhat chaotic framework of different manufacturers’ APIs, allowing seamless integration across different infrastructure such as routing, switching, firewalls, wireless, servers, storage, etc., as well as across different manufacturers of the infrastructure.

Implementing API-driven automation has proven to be extremely beneficial for boosting productivity but not without facing some challenges. As we have learned, automation has come a long way since the early days of CLI or simple Web user-interface (UI) and can dramatically reduce the amount of human error and network inconsistencies that happen with manual configurations and maintenance. Networking teams are beginning to automate their network infrastructure to eliminate errors and save time using the APIs provided and now have software that can help them quickly realize their goals.

Part 2 of the blog series will take a deeper dive into APIs including some of the integration challenges.

Contributing authors and editors from the O&A Working Group include:

David Hegenbarth, Pliant

Michael Haugh, Gluware

Rich Martin, Itential

Author's Bio

David Hegenbarth, Pliant; Michael Haugh, Gluware; Rich Martin, Itential

Pliant, Gluware, Itential