communication in the service and api supply chain

Another thought about “the service and api supply chain” —how do we know what an API provider or servicer can do? It’s unlikely that any given servicer of an API will service the same subset of that API as any other servicer or be able to keep up with all the changes that are introduced by the API originator.

Can you ask an API endpoint:

• Hey, what can you do? 
• What APIs do you originate and provide? 
• What 3rd party APIs do you service? 
• What subset of those APIs? 
• What are your SLAs?
• Etc.

Can the API endpoint tell you:

• I’m running out of capacity to service X?
• There’s a degradation of service Y?
• You can send these calls to these other endpoints I own?
• This is how much I charge per call for Z?
• Etc. 

We could use a (roughly) global language with some basic terms for services that describe what they do, what they service, how they do it, with what kinds of commitments. An analog to Wolfram Language for distributed services. 

We could use a (roughly) global protocol for handshakes and mutual understanding so services can talk to each other, advertise and discover what they can do, what they can service, how they do it, with what kinds of commitments and interrogation mechanisms. An analog to ethernet autonegotiation for distributed services.

Plenty of API providers don't want this to exist. But the competitive advantage that could be generated by programatically dealing with an API should draw a significant ecosystem. So I wonder why this hasn't been done, especially be near-first tier providers like GCE and Azure. I can only guess it's because they haven't figured out how to do ecosystem-based strategic gameplay for cloud services yet. And of course, AWS has no need to do such a thing (yet).

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.

provided vs exposed

If you're offering infrastructure as a service, you have to have infrastructure to offer and it has to be exposed.

But if you're offering something else, then:

The infrastructure doesn't need to be exposed, THUS you don't need to have it.

Examples:

• You offer VMs, so you need to expose VMs, a management console for VMs, and (hopefully) APIs to connect to and operate them
• You offer a runtime, so you may or may not have VMs--but who cares since what you need to expose is the runtime, a management console for that runtime, and (hopefully) APIs to connect to and operate it
• You offer an application, so you may or may not have VMs or a particular runtime--but who cares since what you need to expose is the application, a management console for that application, and (hopefully) APIs to connect to and operate it

It gets a little more complicated when someone wants to build something else on top of what you offer. Then they probably want and/or need more exposure to, and more control knobs for, the underlying stuff.

Basically, this is what makes IaaS (specifically VMaaS) different in kind from anything else. 

What you provide guides what you expose dictates how you can build.

What you've built limits what you can expose dictates what you can provide.