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.
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, including NCS from Tail-f (now Cisco), VMware NSX-T and Cisco ACI, and a plethora of intent-based systems. 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?
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)..
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.
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.
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