The command line interface, or CLI, has been the primary method of interacting with the network for many years. Most network practitioners have become proficient at one, and probably more, CLI “syntaxes” over their career. It has been the “native tongue” of the network devices they manage, and they speak it fluently and often.
CLI syntax can be different from vendor to vendor, and even change within the same vendor. Sometimes these changes to the syntax are minor, slight variations, and sometimes they are radically different than what is considered standard CLI syntax. Over the years, network practitioners have risen to the challenge and learned to master any new CLI iterations in order to configure, troubleshoot, and manage their network.
While the CLI itself has been the primary way of manually managing network devices, it isn’t ideal to use for complex automation that you can trust. This is due to the fact that the CLI is an interface that is designed to be human-centric, which means that CLI inputs and outputs are designed and intended to work with a person, not a machine. One of the goals of effective automation is to allow machines to do a subset of the work more efficiently, and free a person’s time to do higher order priorities that are not simple to automate.
The Shift from Human-Centric to Machine-Centric Automation
In today’s exploded network environment, automation has become a necessity. This new world requires network practitioners to learn how to use APIs, or Application Programming Interfaces, instead of solely relying on CLI to interact with their full network ecosystem. APIs provide a machine-centric way of interacting with the network and because of this, they offer a better interface for building network automations. As APIs are designed with machine integration in mind, they offer several advantages over CLI for network automation.
Documentation
While not all API documentation is created equal, those that conform to a standard like Swagger or OpenAPI make it very easy to understand what methods and capabilities are available in the API. Fortunately, the network industry as a whole is getting better at documenting APIs, adopting standards, and generally making it fairly easy for a person to browse and quickly understand how an API can be used.
Standardization
Most API calls have a clearly defined and formatted method of passing input to it so that it can complete the command as intended by the user. Perhaps more importantly, when the API call is completed, it should provide a clearly defined and formatted output back to the program or system. This output should be formatted in a way that easily identifies the success or failure state of the command, and any additional metadata that might be needed, especially if there was a failure in executing the command. Standardization prevents problems with undue overhead in parsing the returned output and risks in interpreting the result incorrectly.
Integration
Automations become more efficient when they can be integrated with more systems, services, and tools. Automation platforms should have the ability to take a properly documented API and automatically create an integration to that API’s system, because they are designed to be easily understood by machines. By enabling network teams to quickly integrate using APIs into their automation platform, they are not constrained by a vendor to develop the integrations they need for their IT solutions and can quickly build automations across domains and systems.
With the new and exploded network landscape, APIs have become a critical component for automation across every IT domain, and groups aligned with DevOps and cloud already use APIs day-to-day, similar to how network teams use CLI day today. While APIs may seem strange at first, network practitioners have a proven track record of learning new technologies, systems, and tools when they needed to adopt a new technology. Just recall the transition from separate PBX and Telephony Solutions to IP Telephony and VoIP as one example. Network automation should be another valuable and necessary tool in their toolbox, and I have no doubt that network practitioners have the capability to become as fluent in APIs as they already are in CLIs. And they will need to be, because APIs are the “native tongue” for network automation in today’s modern network environment.
Rich Martin
Director of Technical Marketing ‐ Itential
Rich Martin is the Director of Technical Marketing at Itential. Previously, Rich has worked at several networking vendors as a both a Pre-Sales Systems Engineer and Systems Engineering Manager but started his career with a background in software development and Linux. He has a passion for automation in the networking domain, and at Itential he helps networking teams to get started quickly and move forward successfully on their network automation journey.
