Forecast: Death of the CLI

Forecast: Death of the CLIEverything in networking is acquiring an API. Here's why that means the demise of the command line interface.

Everything in networking is acquiring an API. Here's why that means the demise of the command line interface.

It seems like everything in IT is gaining an application programming interface, or API, and that's a good thing. We need systems that let us automate repetitive tasks, gain efficiencies, and reduce mistakes. But that begs the question: Will the use of APIs replace the command line interface (CLI) on most IT systems?

A year ago Andrew Lerner, a Gartner research VP, suggested that APIs would indeed replace the CLI, and Marcia Savage, of Network Computing (a No Jitter sister site), followed up with a blog post containing more details. More recently, the GestaltIT Roundtable podcast explored the topic as well.

Here let's look at the subject in more detail so we understand the factors that might (or might not) make this prediction come true. I'm going to attempt to make my point without being specific regarding the functionality of the device in question, as that could be a network device, a UC endpoint, or a UC server.

Understanding the CLI
The CLI comprises multiple components:

User input/output

Command line editing, command history, command completion

Input parsing, argument validation, and command dispatch/execution

Error handling and reporting

Most products have at least two CLI modes, an important point for our analysis:

Interactive mode, for use with commands that query the device for operational data; it's often used to collect data for troubleshooting, and includes the "show" commands as well as commands to view device configuration

Configuration mode, which allows the administrator to change the operation of the device

The CLI has the advantage of relying on a simple telnet or Secure Shell session for communications and a parsing engine for identifying and executing commands. It requires no additional software (ASN.1, JSON, or XML parsers) or protocols (CMIP, SNMP). The CLI's disadvantage is that a human is typically driving it. While using the CLI as an API is possible, the CLI lacks error-specific return codes that allow the controlling system to understand the type of error and take an appropriate action (e.g., retry, argument error, bounds checking error, etc). On occasion, an automation tool must also handle the occasional typo in either the input or the output text; having to fix typos have always created problems for ISPs that have automated much of their operations via the CLI.

Replacing the CLI
We're replacing the CLI because we need to stop configuring single devices at a time and instead begin configuring IT systems as a whole. For example, let's say we want to deploy a consistent quality-of-service (QoS) policy across all enterprise network devices (UC endpoints, switches, routers, firewalls, and load balancers). Ideally, we'd have a common QoS model that the API maps to device-specific configuration. A common model for querying the operation of the QoS implementation would allow us to validate that the IT systems are functioning as we designed (that's where the concept of "intent-based networking," as I discussed in a recent No Jitter post, originates).

Replacing the CLI with an API isn't difficult. In fact, Red Hat's Ansible automation system supports old equipment that only has a CLI interface. Newer equipment supports both a CLI and an API, often via a REST interface that uses either XML or JSON encoding of command elements. In addition, some devices only support an API interface; the CLI is just a module that makes API calls.

In an acmqueue article,"A Plea to Software Vendors from Sysadmins--10 Do's and Don'ts," Thomas Limoncelli, a Google system administrator, raised an interesting set of points about APIs and CLIs. They include:

Don't make the administrative interface a GUI -- in which he suggests a CLI but then goes on to explain what's needed, which may be implemented with an API

Do create an API so that the system can be remotely administered -- this asks for an interface to allow automation

Do have a configuration file that's an ASCII file, not a binary blob -- this requests a text-based configuration file, which facilitates storing in a configuration repository, comparing with other configurations, and easy restoration

I don't think it matters whether the interface to the device uses SSH or HTTPS/REST. What does matter is a concise command language for performing troubleshooting (the "show" commands) and for creating a basic configuration. In fact, for most troubleshooting, I see an API as the more powerful interface. For example, I would prefer a management and troubleshooting interface that quickly provides a view of the QoS configuration across multiple devices, highlighting any differences.

The third point above, "do have a configuration file that's an ASCII file, not a binary blob," is critical. I'm optimistic that representations like JSON and XML will make it easy for software developers to decide to use a text-based configuration file instead of encoding data into binary. While I find JSON and XML more difficult to read than typical configuration files, I don't really expect the industry to decide to use a common configuration language. I expect vendors to make translators to convert between their own configuration languages and a corresponding JSON/XML representation that's typically used by an API. There will be an opportunity for products that provide an abstraction layer that hides the differences between vendors. For example, Tail-f Systems (now part of Cisco) did this and the Apstra AOS product uses vendor-independent models to provide a common interface. The challenge (and opportunity) will be to provide a common output for show commands used for troubleshooting.

What About My Vendor Certification?
Many of the industry certifications are based on an understanding of industry standard protocols and a detailed knowledge of how to configure them using a vendor's configuration syntax. Will this change? I think it will. The old certifications were device-centric. The industry is moving toward system configuration and operation. The certifications will have to adapt to this change. We still need experts who understand how IT systems are designed, built, and operate. Instead of testing knowledge of vendor-specific configuration and troubleshooting statements, certifications will need to test protocol, design, and troubleshooting knowledge.

Summary
Do I think the CLI is dying? The on-the-box CLI is nearing the end of its useful life. I think we'll see a CLI that runs on a central system (desktop, laptop, tablet, or phone) and uses an API to query one or more devices and show how an entire system is configured and operating. We'll have expert systems that run all the time to detect and report potential problems, with a goal of automatically remediating those problems. This mechanism is more scalable and efficient than what we use now.

My perspective is that API-based systems will include servers (which have been using automation for some time), network equipment, and IT systems like UC controllers, media gateways, SBCs, and UC endpoints. I'm interested to see which vendor releases a product that only has an API.

(Note: Terry brings a unique perspective to the discussion of the CLI. He led the team that developed the current Cisco CLI, first released in Cisco's IOS 9.21 in 1992.)

Voice engagement isn't about a simple phone call any longer, but rather a conversational experience that crosses from one channel to the next, as Daniel Hong, a VP and research director with Forrester....

Find out what business considerations are driving the SIP trunking market today, and learn a bit about how satisfied enterprises are with their providers. We talk with John Malone, president of The Ea....

World Vision U.S. is finding lots of goodness in RingCentral's cloud communications service, but as Randy Boyd, infrastructure architect at the global humanitarian nonprofit, tells us, he and his team....

Alicia Gee, director of unified communications at Sutter Physician Services, oversees the technical team supporting a 1,000-agent contact center running on Genesys PureConnect. She catches us up on th....

Andrew Prokop, communications evangelist with Arrow Systems Integration, has lately been working on integrating enterprise communications into Internet of Things ecosystems. He shares examples and off....

Lantre Barr, founder and CEO of Blacc Spot Media, urges any enterprise that's been on the fence about integrating real-time communications into business workflows to jump off and get started. Tune and....

Communications expert Tsahi Levent-Levi, author of the popular BlogGeek.me blog, keeps a running tally and comprehensive overview of communications platform-as-a-service offerings in his "Choosing a W....

Enterprises strategizing on mobility today, including for internal collaboration, don't have the luxury of learning as they go. Tony Rizzo, enterprise mobility specialist with Blue Hill Research, expl....

Tim Banting, of Current Analysis, gives us a peek into what the next three years will bring in advance of his Enterprise Connect session exploring the question: Will there be a new model for enterpris....

Andrew Davis, co-founder of Wainhouse Research and chair of the Video track at Enterprise Connect 2017, sorts through the myriad cloud video service options and shares how to tell if your choice is en....