Kin Lane has started tracking what he calls API Brokers over at API Evangelist. This quote illustrates the promise of API brokerage:
I envision other new API brokers emerging, in niche areas like images, video or messaging. Imagine if you could use Twilio, Tropo or other SMS API provider, but use through a broker who will give you the best availability and costs based upon various needs. This type of API aggregation is not meant for providing users with access to multiple cloud silos via APIs, it is more about brokering API resources and establishing a marketplace.
This really resonated with me, as it is similar to something we’ve been talking about for a while: IT as a Cloud Service Brokerage, which is an emerging specialization of API management. As SaaS, Consumerization, and the general bring-your-own trends continue to accelerate, IT shops are looking to bundle new functionality into their applications while ensuring that they still deliver the expected levels of service. Consumerization/BYO has expanded from handheld devices and ultrabooks to include cloud services like Dropbox, Evernote, and Google Docs. APIs will be the next wave in consumerization. As is the case with many cloud services, APIs with equivalent functionality can be available from multiple sources, but the longevity of the providers (or, as is often the political reality, the contract with the providers) may be uncertain. In addition to the services Kin mentions,
- Translation / localization services — remember when Google temporarily pulled the plug on the Translate API? Fortunately they changed their mind, but what if they hadn’t?
- Location / Mapping services
- Push notifications
- … One could spend weeks browsing ProgrammableWeb and uncover dozens of domains with two or more functionally-equivalent providers
What is an IT shop to do, then, when incorporating cutting-edge functionality into applications when the only providers are fledgling startups (or even hobbies within multi-billion dollar corporations)? It seems like a few options exist:
- Bet on the current leader when the app is being developed; rip & replace if conditions change
- Code multiple providers’ APIs into the app, embedding some prioritization and fall-back logic
- Use an aggregator
Clearly the aggregation layer (whether embedded in the app or as a cloud service) offers more agility and resilience than hard-coding. The additional indirection provides protection against service outages – whether they are due to an operational issue with an API provider, an infrastructure issue with their cloud service provider, or an untimely end-of-life for the service. However, given that this domain is just emerging, most of the aggregators are likely early-stage startups themselves. Their availability and longevity may not be any better than the APIs they are proxying — in fact, it may be less.
An enterprise IT shop has another option here: acting as its own Cloud Service Brokerage. An API gateway is already acting as a proxy between clients and APIs. By adding some additional logic to the API management workflow, the gateway can offer a fallback path to a different provider. By placing the API management & brokerage layer inside the enterprise cloud (whether public, private, or virtual private), the brokered APIs will have the same availability as the rest of the enterprise infrastructure. The gateway already has remediation capabilities built in — JSON or XML fields can be renamed and reordered, omitted, or populated with default values. An enterprise could even define its own API structure that is then redirected in the format expected by the services it is brokering. If necessary, this logic can be combined with format-preserving encryption or tokenization to ensure that sensitive corporate data isn’t transmitted to a third party.
This on-prem brokerage approach is not without tradeoffs, however. First, an API management solution is not likely to be as dynamic as a specialized brokerage service. This means that market forces are less likely to be factored into the runtime routing decision. While contracts and other external forces can be incorporated at configuration time and reviewed on a regular basis, the multi-provider API management policy is most likely going to be implemented as a favored provider with fallback providers utilized for availability, not cost (on the other hand, a brokerage service’s profit margin may offset much of cost savings due to market efficiency). Also, by using a brokerage (whether internal or external), there may be functional tradeoffs: the application may be restricted to the greatest common denominator of all available APIs to allow for aggregation and avoid vendor lock-in. I find these tradeoffs to be fairly standard in Enterprise IT, however, and are widely accepted as part of the cost of providing a stable, predictable IT environment.