the service and api supply chain

When we visit a site, start an app, or do just about anything online—what lives behind that one object is 10s, sometimes 100s, of services.

As Mr Krugman notes, the great transport and communication innovations of the past generation did not necessarily reduce shipping costs. Rather, they reduced shipping time while also making international coordination of shipments cheaper and easier. The result has been, in Richard Baldwin's phrase, a "second unbundling". The first unbundling represented globalisation's geographic separation of production and consumption more than a century ago. The second is the geographic separation of stages of production. And one then has to ask how stories of the determinants of international trade apply to each of these various stages.

- Hyperglobalisation and metropolitan gravity, Free exchange @ The Economist [emphasis added] 

We’ve seen a steady unbundling on the web, on our phones, and in our apps. It’s the separation of technological stages of production of apps and services. And it’s turtles all the way down.

When we bought all our software and ran it on our own systems, we controlled the software supply chain underlying the ultimate business apps we used. But if we rely on a SaaS app that relies on other services accessed via APIs which may themselves rely on other services accessed via other APIs—how do we manage this new supply chain? How do we figure out how to manage the risk of our services’ services’ services’ services?

With actual manufacturing, if a supplier stops delivering or goes out of business, you find another maker of the same component or ship your specs off to another manufacturer who can make that very same part you need. 

In the API economy, if the provider of a service goes under or simply stops providing the service, what can we do? 

• Suffer and recode to a new API for a competitive service (if one exists)
• Build an abstraction (maybe our own API) to make that easier
• Use two or more similar services via our own abstraction with some ability to switch if one fails, which still involves building the drivers (as it were) for each service’s API

What we can’t do is ship the API calls to another provider to service, or put a service spec plus API out to bid, or create an ecosystem of multiple suppliers for each service layer. 

Why not?

Where’s the alternate service provider who will service the AWS APIs? Where’s the alternate service provider who will service the Twilio APIs?  Where’s the alternate service provider who will service the Dropbox APIs? 

Added Feb 12th: Where's the communication mechanism to discover services, APIs, nodes and negotiate transactions? More on that question in another post.

There’s an opportunity in there somewhere.