APIs Win Because They’re Easy

I went out to Jimmy John’s the other night, to get a sandwich with a good buddy of mine. It was pretty fast. I ordered a standard ham-and-cheese sandwich, and my buddy got an Italian hoagie with banana peppers. They were quite tasty! I guess we were in the store, conducting this transaction, for less than 5 minutes. Pretty fast. And easy.

Easy wins. People will always choose the easier option. People are willing to pay more, or receive less, in order to get something easy. “Fast food” is cheap, but it isn’t the cheapest. Often it’s even less expensive to buy ingredients at the grocery, and prepare a meal.

We paid about $USD 15 for 2 sandwiches. (We didn’t order drinks because soda is toxic sludge and doesn’t belong in the human diet.) Now, I could have gone to the grocery across the parking lot, purchased a pound of ham, a loaf of bread, and some lettuce and tomato for about $20, and had plenty of ingredients to make 5 sandwiches or more. Instead, we paid for the convenience and we were happy to do it.

But fast food does not always deliver the best nutrition. It’s easy, and it might even be “tasty”, but sometimes it’s not good. (and yes, I know that the film “Super Size Me” was criticized for being less than 100% truthful, and less than scientific about the analysis.) In a free economy, for every potential purchase, the consumer decides whether the combination of ease, quality, and the price of the thing on offer represents a good deal. Generally, “easy” is worth good money.

And that makes sense. People have things to do, and for some people, preparing food is not high on the priority list. Likewise, people will pay $50 to get the oil changed in their car, even though they could do it themselves with about $28 worth of supplies. People pay for convenience when maintaining their cars.

And the same is true when managing and operating information systems. People will often sacrifice quality in order to gain some ease. Or they may pay more for greater ease. That’s often the right choice.

The adoption of Windows Server in the enterprise, starting in 1996 or so, was a perfect example of that. People had so-called “Enterprise Grade” Unix-based options available. But Windows was simple to deploy, easy to configure for basic file and printer sharing, and database access. Who can argue with those choices? Sure, there were drawbacks, but even so, the preference for easier solutions continues.

As another example, these days, for interconnecting disparate information systems, REST APIs are much, much more popular than using SOAP. There are numerous indicators of this trend, but one of them is the Google Search Insights data:

(Can you guess which line in the above is “REST” and which represents the search volume on “SOAP”?) The popularity of REST may seem curious, to law-and-order IT professionals. SOAP provides a means to explicitly state the contract for interconnecting systems, in the WSDL document. And WSDL provides a way to rigorously specify the type of the data being sent and received, including the shape of the XML data, the XML namespaces, and so on. SOAP also provides a way to sign documents, as a way to provide non-repudiation. In the REST API model, none of that is available. You’d have to do it all yourself.

But apparently, people don’t want all that capability. Or better, they may want it, but they want ease of development more. When given the choice to opt for greater capability and more strictures (SOAP), versus a simpler, easier way to connect (REST APIs), people have been choosing the easy path, and the trend is strengthening.

APIs are winning because they’re easy.

One billion smart phones, and counting

From C|Net, Strategy Analytics reports that there are now more than 1 billion smartphones in use on the planet. The story has been picked up by other places, too.

One billion is a big number, there’s no question about that. But what people are glossing over is that the number is +46% in one year. That’s is a HUGE jump.

Apple, Samsung and Nokia, with their partners, are obviously making things that people want. Somehow HTC is missing out on the gravy train. While the market is thumping along, HTC has reported their lowest profit since 2006. Time for the board to take action.)

Aside from the mobile handset space, with that kind of scale it is easy to imagine some pretty outsize opportunities in complementary markets. Like, for example, in connecting all those phones to cloud-based resources. I guess there would have to be a way for software programs running on the handsets, to be able to connect with the cloud. Some kind of programmatic interface – an API, perhaps?

And then on the cloud-side – and by cloud I mean anything that is not tethered to the phone, anything that is reached over the internet – there oughtta be some way for cloud-based service providers to manage the deluge of API access, to measure it, to rate-limit, examine it.

Hmmmm, I wonder if there’s a company that could help with that?

“No technology can ever be too arcane…”

From an ironic fictional interview with Linus Torvalds on TypicalProgrammer, via @ckindel.

Q: You released the Git distributed version control system less than ten years ago. Git caught on quickly and seems to be the dominant source code control system, or at least the one people argue about most on Reddit and Hacker News.

A: Git has taken over where Linux left off separating the geeks into know-nothings and know-it-alls. I didn’t really expect anyone to use it because it’s so hard to use, but that turns out to be its big appeal. No technology can ever be too arcane or complicated for the black t-shirt crowd.

Q: I thought Subversion was hard to understand. I haven’t wrapped my head around Git yet.

A: You’ll spend a lot of time trying to get your head around it, and being ridiculed by the experts on github and elsewhere. I’ve learned that no toolchain can be too complicated because the drive for prestige and job security is too strong.

We’ve all seen that phenomenon. On the other hand, some situations demand more complex solutions, unpleasant as that fact may seem. One cannot build a robot without a sophisticated control system. One cannot build an internet-scale social app without some sort of fault-tolerant distributed data storage infrastructure.

The trick is determining to what degree the complexity is necessary, and to what degree the complexity is self-sustaining due to the prestige and job security factors.