Editor’s Note: Any resemblance to persons living or dead, known or unknown, read about, heard about, talked about, dreamt about (just once, don’t ask) not intended. Any offense probably intended. Standard disclaimers apply.
With all of the recent talk in the networking community about software defined this or that, it can be hard to separate the marketing and spin from the substantial and substantive. Beyond that, however, it can be even harder to pull out the truly useful ideas from among those that are really, really cool, and probably should be done, but aren’t the shiny panacea everyone builds them up to be. Case in point: APIs.
Application Programming Interfaces can seem like magic to the uninitiated. They are the secret sauce, the keys to the nirvana inside the shiny boxes in your data center, and the solution to every problem you imagine you have. The problem is, while eminently useful, APIs are not new, radical, or particularly interesting on their own.
So, in the spirit of some of my recent “get off my lawn” posts, let’s run through a few points on APIs that I think sometimes get missed in the breathless discussions of the data centers in this Brave New World (with apologies to Aldous Huxley).
An API is not magic, secret sauce
There. I said it. I think a lot of folks with a non-programming background tend to inflate the potential magic-bean component of what exactly an API is. So, let’s clear this up first: an API is a file. Well, usually it’s a bunch of files, but nothing more. These files are a mix of types and usually come as part of a software development library or kit (SDK) from the manufacturer of a product.
At a very basic level, the files in an SDK contain descriptions of functions or objects that do things. Say you’re writing a program to calculate the area of a square. You can write that all yourself, or you can use a function that does this already and might be in a library somewhere. Just pass on some information to the function; it does the calculation and gives you back some information.
An API for a device like a storage array works the same way. I want to connect to the array and retrieve a list of LUNs. So, I have my program use some pre-built software code from the manufacturer, and now my little software program is connecting to the storage array and getting me a list of LUNs.
That is quite obviously a trivial example, but at a fundamental level that is all an API is: a bunch of software from someone that allows your software to talk to their device. The API by itself conveys nothing magical or complete- remember, you still have to write the code to do something. It just gives you the ability to access that device at a lower level (more direct) than you tend to get with command line interfaces, scripting, and other higher-level and more abstracted methods.
An API does not mean the product is “open”
I’ve seen this idea floating around out there in some circles. Some folks are conflating the idea of open source, or other “open” terminology with the existence of an API. The mere existence of an API doesn’t confer any more openness than does a command line interface.
A command line interface allows you to control the device in some way, using pre-built commands that do certain things. An API allows you to do the same thing, but with your own software. So now you can build your own “CLI” off-box. Or you can automate some activities–much like you can today with scripting. An API is much more elegant, to be sure, but more open? No.
As a manufacturer, I can expose a lot of functions, methods, etc. to you in an API, but still hide the details of what’s going on. I can say, for instance, you give me a name and IP address, and I’ll connect you to the box. How I connect you to the box, however, might still be completely hidden away from you.
If you trust wizards, you’ll love you some API
How many of us have used the wizards built in to the GUI of a device. Want a VPN from Seattle to New York? Here, I’ll ask you a question or two and then build it. Now, how many times has that actually worked, and how many of us use the wizards in most devices at all beyond the initial curious look-see. That’s the fundamental problem with this idea that an API allows all sorts of auto-magical, automated, secret-sauce, fairy-dusted solutions to all of our problems.
The manufacturer of a device has, theoretically, unlimited access to that device as they’re building and developing it. They can build the GUI, the CLI, and the wizards to do anything they think the customer might want. Now you come along and say, no, don’t build me any of that because I’ll just do it myself and it will be glorious. The level of effort involved is dramatically and consistently underestimated by neophyte developers.
In fact, when I’ve had this conversation with experienced developers, this very idea always comes up. APIs, they say, are incredibly useful and would be a nice-to-have or must-haves in most cases. No programmer is going to turn down programmatic access to a device. But, and there’s always a but in these conversations, the incredible amount of effort it takes to get from having an API and a box to having a fully integrated, automated, reliable and working system is dramatically underestimated almost universally by non-developers–including most engineers and systems folks in IT.
There is a reason why the large-scale systems of the past (the HP Openviews of the world) cost as much as a helicopter to buy, configure, install and actually use. There’s a reason why both closed and open source projects in this space have hundreds and thousands of contributors working on source code. It is incredibly difficult to develop systems of disparate systems that can reliably manage any level of automation.
H.L. Mencken once said, “Explanations exist; they have existed for all time; there is always a well-known solution to every human problem — neat, plausible, and wrong.” I don’t think that the desire for an API in every pot is wrong or non-useful at all. As a long-time programmer myself, I always prefer to have a programmatic way to talk to any device I own- the more the merrier. However, thinking that just having every device in your network programmatically accessible somehow solves your automation problems, or reduces complexity, or stitches everything together for you is completely, unequivocally, and totally wrong.
It actually sounds like the stuff of nightmares.