Your browser failed to load CSS style sheets. Your browser or web proxy might not support elliptic-curve TLS

Building network automation solutions

6 week online course

Start now!
back to overview

CLI and API Myths

Greg Ferro published a great blog post explaining why he decided to use node.js to build his cloud automation platform. While I agree with most things he wrote, this one prickled me the wrong way:

In my view, an Application Programmable Interface(API) is the fundamental change that makes Software Defined Networking (SDN) a “thing”. We need to realise that the CLI is a “power tools” for specialist tradespeople and not a “knife and fork” for everyday use.

While I agree with his view on CLI, keep in mind that API is no different.

Device-Level API

Take a closer look at the product and programming documentation (not marketing fluff) of any product with CLI and API interface. What you’ll find in almost all cases is that:

  • Both methods provide a configuration and monitoring (management plane) interface. F5 iRules and similar tools are an obvious exception.
  • The available functionality is usually the same, with the exception of vendors who never understood the concept of feature parity.

Surprised? You shouldn’t be – CLI, API (and Web GUI) are doing the same thing behind the scenes: changing values of configurable variables and data structures. It doesn’t matter which mechanism you use to set a variable value or insert a new data structure in a linked list – no API will save the day if the software you’re interacting with doesn’t support the functionality you need.

Newer platforms commonly use the same API exposed to the end-user to implement their CLI and GUI.

Also keep in mind that no two APIs are identical (or even similar). Almost every device-level API (including whatever-over-NETCONF) is proprietary; the rare exceptions are standard SNMP MIBs and Quantum plug-ins (Did I miss anything? Write a comment!).

The only difference between CLI and API is the target audience. CLI is easier for humans, API is easier for machines. However, any programmer worth his salt should be able to create an abstraction layer offering reasonable entry points to the outside world and dealing with device-specific idiosyncrasies (that’s what Netdev is aiming to do for Puppet) ... and ensuring transactional consistency on a device that doesn’t support the concept (like Cisco IOS) is mission impossible regardless of which configuration method you use.

Network-Level API

I love listening to SDN pundits telling us how it’s too expensive to touch every device in the network to provision a new whatever and how SDN and APIs will solve that problem. Really? Would you mind rereading the previous section?

The way we provision services today is too expensive and cumbersome, there’s no doubt about that, but changing the configuration/programming paradigm from text-over-SSH to JSON-over-SSL is nothing more than eye candy. What we need is a network-level abstraction, at which point it doesn’t matter (yet again) whether we use CLI or API to configure the network-wide services. What matters is the level of abstraction.

Theory or Reality?

There are several tools out there that give you a network-level API: NCS from Tail-f, MATE from Cariden, Network Virtualization Platform (NVP) from Nicira/VMware, and Programmable Flow Controller from NEC, proving it’s possible to solve the problem. However, we’re all aware of networking vendors’ dismal track record when it comes to network management tools. Why should they do any better this time?

6 comments:

  1. Great post. You're correct that APIs and CLIs are doing the same thing behind the scenes. This does mean that as a configuration interface there's not much to choose. However, there is one advantage in APIs relative to CLIs for "show" commands - APIs have the potential to provide more structure in the output compared to traditional screen scraping. In that sense JSON-over-SSL is more than just eye candy.

    ReplyDelete
  2. Agree with Anonymous. But there is a difference also for config; the CLI is often irregular and does not have a formal description of its commands. Furthermore, different vendor's CLIs have different semantics in their commands. With an API the operations are usually well defined, even if vendors have proprietary content (data models).

    ReplyDelete
    Replies
    1. even different versions have different syntax..
      PIX>ASA>FWSM as an example..
      or even asa 8.2> 8.3

      It's easy enough for common procedures to be standardized and have a layer between device and user to "translate" it to commands, but with hardware behavior differences it would be quite challenging to implement on scale that would be useful. And with heterogenous network or operational upgrades and migrations it would be lots of fun (for an observer)..



      Delete
    2. Indeed. great wakeup post ;)

      There is no much deficiency with what you can do southbound (granularity by things like OF is an exception, but has its toll). it's all about (and always has been) looking up, northbound, from the devices to controller and from controller to applications. the vacum there is enormous.

      Delete
  3. The key is, has, and always been hardware; as hardware hits certain price points vendors add value to the equipment.

    Fact is if the big vendors implemented standardized SDN with standardized data structures and standardized protocols, all the little vendors would eat their lunch with specialty equipment. They know this, and thus, they will gladly develop SDN as a feature to make their equipment work better, but will certainly build kinks when making it work with competitors kit which is both good and bad. When all is said and done, you can expect vendors to step in and build middle-ware to support everything except for the bleeding edge, and companies will jump on it as a value-add with caveats.

    ReplyDelete
  4. Lots of stuff to comment on here. The comment thread alone is interesting.

    Why should this be different this time around? I think the problem with network management in the past has been that it is inherently customized to each customer, which means the cost to customize it is quite high. This brings down the margins as cost-per-sale goes up. Which means that the best return on an incremental dollar of investment is spent somewhere other than network management.

    If, however, there is less customization (because the network abstraction is done better), you should see higher ROI, which would mean the cost of sale would be better. This could be a way to help buoy margins when hardware continues to decrease (and would be part of an overall shift to monetizing software).

    Which brings me to the comment about hardware being the thing. I think that is a little bit lazy. The thing has never been hardware - it is sales. As long as solutions are monetized primarily on hardware, you get the behavior described. If monetization shifts more to software, you will see different behavior.

    -Mike (@mbushong)
    Plexxi

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Sidebar