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:
Most products have at least two CLI modes, an important point for our analysis:
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:
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.)
