The <Span Class="caps">API</Span> Obsession

Read­ing Time: 4 min­utes

Edi­tor’s Note: Any resem­blance to per­sons liv­ing or dead, known or unknown, read about, heard about, talked about, dreamt about (just once, don’t ask) not intend­ed.  Any offense prob­a­bly intend­ed.  Stan­dard dis­claimers apply.

With all of the recent talk in the net­work­ing com­mu­ni­ty about soft­ware defined this or that, it can be hard to sep­a­rate the mar­ket­ing and spin from the sub­stan­tial and sub­stan­tive. Beyond that, how­ev­er, it can be even hard­er to pull out the tru­ly use­ful ideas from among those that are real­ly, real­ly cool, and prob­a­bly should be done, but aren’t the shiny panacea every­one builds them up to be. Case in point: APIs.

Appli­ca­tion Pro­gram­ming Inter­faces can seem like mag­ic to the unini­ti­at­ed. They are the secret sauce, the keys to the nir­vana inside the shiny box­es in your data cen­ter, and the solu­tion to every prob­lem you imag­ine you have. The prob­lem is, while emi­nent­ly use­ful, APIs are not new, rad­i­cal, or par­tic­u­lar­ly inter­est­ing on their own.

So, in the spir­it of some of my recent “get off my lawn” posts, let’s run through a few points on APIs that I think some­times get missed in the breath­less dis­cus­sions of the data cen­ters in this Brave New World (with apolo­gies to Aldous Hux­ley).

An API is not magic, secret sauce

There. I said it. I think a lot of folks with a non-pro­gram­ming back­ground tend to inflate the poten­tial mag­ic-bean com­po­nent of what exact­ly an API is. So, let’s clear this up first: an API is a file. Well, usu­al­ly it’s a bunch of files, but noth­ing more. These files are a mix of types and usu­al­ly come as part of a soft­ware devel­op­ment library or kit (SDK) from the man­u­fac­tur­er of a prod­uct.

At a very basic lev­el, the files in an SDK con­tain descrip­tions of func­tions or objects that do things. Say you’re writ­ing a pro­gram to cal­cu­late the area of a square. You can write that all your­self, or you can use a func­tion that does this already and might be in a library some­where. Just pass on some infor­ma­tion to the func­tion; it does the cal­cu­la­tion and gives you back some infor­ma­tion.

An API for a device like a stor­age array works the same way. I want to con­nect to the array and retrieve a list of LUNs. So, I have my pro­gram use some pre-built soft­ware code from the man­u­fac­tur­er, and now my lit­tle soft­ware pro­gram is con­nect­ing to the stor­age array and get­ting me a list of LUNs.

That is quite obvi­ous­ly a triv­ial exam­ple, but at a fun­da­men­tal lev­el that is all an API is: a bunch of soft­ware from some­one that allows your soft­ware to talk to their device. The API by itself con­veys noth­ing mag­i­cal or com­plete- remem­ber, you still have to write the code to do some­thing. It just gives you the abil­i­ty to access that device at a low­er lev­el (more direct) than you tend to get with com­mand line inter­faces, script­ing, and oth­er high­er-lev­el and more abstract­ed meth­ods.

An API does not mean the product is “open”

I’ve seen this idea float­ing around out there in some cir­cles. Some folks are con­flat­ing the idea of open source, or oth­er “open” ter­mi­nol­o­gy with the exis­tence of an API. The mere exis­tence of an API does­n’t con­fer any more open­ness than does a com­mand line inter­face.

A com­mand line inter­face allows you to con­trol the device in some way, using pre-built com­mands that do cer­tain things. An API allows you to do the same thing, but with your own soft­ware. So now you can build your own “CLI” off-box. Or you can auto­mate some activities–much like you can today with script­ing. An API is much more ele­gant, to be sure, but more open? No.

As a man­u­fac­tur­er, I can expose a lot of func­tions, meth­ods, 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 con­nect you to the box. How I con­nect you to the box, how­ev­er, might still be com­plete­ly hid­den away from you.

If you trust wizards, you’ll love you some API

How many of us have used the wiz­ards built in to the GUI of a device. Want a VPN from Seat­tle to New York? Here, I’ll ask you a ques­tion or two and then build it. Now, how many times has that actu­al­ly worked, and how many of us use the wiz­ards in most devices at all beyond the ini­tial curi­ous look-see. That’s the fun­da­men­tal prob­lem with this idea that an API allows all sorts of auto-mag­i­cal, auto­mat­ed, secret-sauce, fairy-dust­ed solu­tions to all of our prob­lems.

The man­u­fac­tur­er of a device has, the­o­ret­i­cal­ly, unlim­it­ed access to that device as they’re build­ing and devel­op­ing it. They can build the GUI, the CLI, and the wiz­ards to do any­thing they think the cus­tomer 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 glo­ri­ous. The lev­el of effort involved is dra­mat­i­cal­ly and con­sis­tent­ly under­es­ti­mat­ed by neo­phyte devel­op­ers.

In fact, when I’ve had this con­ver­sa­tion with expe­ri­enced devel­op­ers, this very idea always comes up. APIs, they say, are incred­i­bly use­ful and would be a nice-to-have or must-haves in most cas­es. No pro­gram­mer is going to turn down pro­gram­mat­ic access to a device. But, and there’s always a but in these con­ver­sa­tions, the incred­i­ble amount of effort it takes to get from hav­ing an API and a box to hav­ing a ful­ly inte­grat­ed, auto­mat­ed, reli­able and work­ing sys­tem is dra­mat­i­cal­ly under­es­ti­mat­ed almost uni­ver­sal­ly by non-developers–including most engi­neers and sys­tems folks in IT.

Final thoughts

There is a rea­son why the large-scale sys­tems of the past (the HP Open­views of the world) cost as much as a heli­copter to buy, con­fig­ure, install and actu­al­ly use. There’s a rea­son why both closed and open source projects in this space have hun­dreds and thou­sands of con­trib­u­tors work­ing on source code. It is incred­i­bly dif­fi­cult to devel­op sys­tems of dis­parate sys­tems that can reli­ably man­age any lev­el of automa­tion.

H.L. Menck­en once said, “Expla­na­tions exist; they have exist­ed for all time; there is always a well-known solu­tion to every human prob­lem — neat, plau­si­ble, and wrong.” I don’t think that the desire for an API in every pot is wrong or non-use­ful at all. As a long-time pro­gram­mer myself, I always pre­fer to have a pro­gram­mat­ic way to talk to any device I own- the more the mer­ri­er. How­ev­er, think­ing that just hav­ing every device in your net­work pro­gram­mat­i­cal­ly acces­si­ble some­how solves your automa­tion prob­lems, or reduces com­plex­i­ty, or stitch­es every­thing togeth­er for you is com­plete­ly, unequiv­o­cal­ly, and total­ly wrong.

It actu­al­ly sounds like the stuff of night­mares.