Portable APIs, the APIs that allow you to write the code once and run on multiple clouds, doesn’t get the same kind of attention like the platform abstractions like Red Hat OpenShift and Pivotal CloudFoundry receive among the media and pundits. But it plays a very important role in the multi cloud future we are entering now. In this blog post, we will take a look at different approaches to Portable APIs and why it reduces friction in the multi cloud world. Let us be clear here. We are not talking about API management tools like Apigee but rather tools that allow developers to write code to an API which then translates to (multiple) cloud specific APIs.
Portable APIs are nothing new. Even in Circa 2010 timeframe, we had APIs like Apache JClouds, Apache libcloud, etc. providing an API abstraction over multiple cloud providers. Based on our observations, we see three distinct patterns in the evolution of portable APIs.
- Platform Abstractions: Platform abstractions go beyond the basic resources and encapsulates elastic infrastructure components along with libraries, runtime and middleware needed for applications to be deployed. These abstractions go beyond interface for resources to give an end to end abstraction over multiple components of application deployment lifecycle. Pivotal CloudFoundry, Red Hat OpenShift, Apprenda, etc fall into this category. These platform abstractions allow complete resource independence (thereby, complete independence from vendor lock-in) but they are opinionated limiting developers on what they can do with their application code.
- Common Feature Set Abstractions: There are various toolkits like Apache JClouds, Apache libcloud, pkgcloud, etc. that abstracts away the common set of features among various cloud providers and allows developers to write to cloud specific APIs for features that are not common to different cloud providers. This is the scenario where vendor lock-in is limited and any move from one cloud to another may not require a complete rewrite. If you are using a more Microservices based architecture, you can isolate the lock-in to a smaller set of services and keep the flexibility to move across clouds. These multi cloud toolkits average out the features across compute, network and storage.
- Resource Specific “Standards” Based APIs: There is a third class of abstraction that focusses on depth than abstracting away the common set of features. They are specifically focussed on infrastructure resources like compute, storage or network but they focus on depth in functionality over a common set of features. These tools pick a specific standard, either an OSS standard or a tool with significant market momentum, and build an abstraction that has depth but can be used on top of multiple cloud providers. Minio is one such abstraction that offers S3 like API but can be deployed on top of any cloud storage. So applications written for S3 API can work on multiple cloud providers without having a rewrite. For example, you could use Minio to have an S3 like storage on top of Google cloud storage or Azure storage. These APIs don’t compromise on depth or feature sets but expect you to align your strategy towards an industry standard.
- Standardized Specifications: Another approach, this one for application services, is focussed on developing a standard specification for API so that ISVs and SaaS vendors can use it for their APIs, thereby, helping portability of applications not just across cloud providers but also across platforms. Open Service Broker API, a Linux Foundation project, is focussed on this philosophy.
However, it should be noted that even with portable APIs, you get locked into a specific API but the advantage you get lies in the ease with which you can move your applications from one provider to another. Therein lies the strength of portable APIs.
How Does It Matter?
Decision makers in some of the bleeding edge companies will argue that they made a decision to go with a single cloud provider and the flexibility offered by portable APIs doesn’t impact them because they are quite happy with what the cloud providers offer today. Well, if you are running a large monolithic app on a single cloud provider, it does make sense to stick with a single cloud provider. If you use a Microservices architecture or bite sized functions (as in Serverless/FaaS), having the flexibility to use services in multiple cloud providers becomes critical. In such a scenario, abstracting away the resource specific APIs will come handy for rapid innovation as you spend less time rewriting the app/microservice/function as you migrate to take advantage of a newer service or feature in another cloud provider. This flexibility offered by portable APIs becomes all the more important when you want to retain the flexibility to innovate rapidly.
IT decision makers of today are faced with adapt or perish kind of scenarios every single day. It is critical for them to have the flexibility to innovate rapidly. Multi cloud strategy along with the heavy use of portable APIs will help them maintain their innovation edge.
Disclaimer: Minio is Rishidot Research Client