One of my readers left this comment (slightly rephrased) on my Network Automation RFP Requirements blog post:
Given that we look up to our *nix pioneers as standard bearers for system automation, why do we demand an API from network devices? The API requirement would make sense if the vendor OS is a closed system. If an open system vendor creates APIs for applications running on their system (say for BGP configs) - kudos to them, but I no longer think that should be mandated.
He’s right - API is not a mandatory prerequisite for reliable network automation.
Getting started with network automation? My new online course might be just what you need.
It doesn’t matter (from the reliability perspective) whether you make changes to a system configuration by modifying a text file and reloading the configuration, by running a CLI command, or by executing an API call. What does matter is that:
- The change operation returns a well-defined and easy-to-detect OK/FAIL status;
- The FAIL status includes an easy-to-detect error message;
- The changes done through any of the above methods are atomic (all-or-nothing);
- You can change many parts of the configuration in a single atomic transaction.
Anyone who cut himself off a router while configuring an access list should be very familiar with the last requirement.
While Linux or Windows CLI commands usually meet most of these requirements (exit codes, error messages sent to STDERR), many networking devices don’t come even close.
Moving from system configuration to operational data: while it’s not mandatory that the system returns operational data as structured data in easy-to-parse presentation format (XML or JSON), it helps immensely if it does, and Linux CLI is often no better than the stuff we have to deal with on networking devices. Linux forums are littered with arcane pipelines of commands that resemble line noise but produce exactly what you need if you ever master to understand how to tweak them.
APIs have obvious benefits over CLI commands, for example exposing just the functionality you want third parties to consume, but in the context of minimum mandatory requirements API is really just a highly appreciated convenience mechanism. It’s so much easier for a programmer to execute an HTTP(S) GET or POST request than logging into the box via SSH and executing CLI commands or trying to figure out how to spell NETCONF.