An application-programming interface is one of the key technical facilitators of cloud computing.
Besides the obvious usage of an API to access services like Amazon Simple Storage Service (S3), third-party applications that add graphical user interfaces to cloud services such as Amazon Elastic Compute Cloud (EC2) and Twitter also take advantage of APIs to access the services.
API-hosting provider Mashery makes the claim in a recent blog post that "without APIs, there is no cloud computing." And while that sounds a bit self-serving, it's probably true, at least in the current state of how we interface with cloud providers.
According to Mashery, cloud APIs fall into three general categories:
- Control APIs, which allow cloud infrastructure to be added, reconfigured, or removed in real time, either by human control or programmatically based on traffic, outages, or other factors
- Data APIs, which are the conduits through which data flows in and out of the cloud.
- Application functionality APIs, which enable the functionality with which end users interact, such as shopping carts, wikis, and widgets.
APIs will be forced to evolve as cloud offerings split into ultrasimple services (like S3 image hosting) and more complex services (such as failover from an internal cloud to EC2.) More importantly, APIs will need to support multiple clouds and service provider failures, which are sure to increase.
But, beyond APIs, we need standards to support basic functions, such as portability.
For example, what happens in the case of application portability, as we saw with the recent demise of Coghead? An API might help things along, though providers have little motivation to provide such a "leave now" function. But they should have such motivation, as Phil Wainewright wrote earlier this week:
I believe that it can only enhance the attractiveness of cloud platforms, if customers know they won't be locked in (and therefore can minimize the risk of being locked out when a provider unexpectedly shuts down).
Cloud and platform-as-a-service application portability are sure to be big issues this year, as the economy continues to be a question mark. I highly doubt that Coghead will be the only service provider that fades out, leaving customers to fend for themselves. APIs are nice, and open standards are necessary.
You can follow me on Twitter @daveofdoom
Phil Wainewright writes astutely today on the many degrees of multi-tenant SaaS architecture, highlighting "true" vs. "everything else." Considering that customers and end-users have little to no idea what's running at SaaS companies it's a bit ironic that the technology powering these companies is interesting--I suppose it's only so to technical people and other vendors.
Salesforce.com: First-degree multi-tenancy. In this model, all customers are served from a single infrastructure in which every component is shared, all the way down to the tables in the database.
Intacct: Second-degree multi-tenancy. Like many SaaS pureplays, Intacct uses replication much more broadly than Salesforce.com to distribute its shared-schema instances across large numbers of server clusters.
Oracle and others: Lesser-degree multi-tenancy. There are a lot of terms floating around for these lower levels of multi-tenancy, including isolated tenancy, mega-tenancy or hybrid tenancy.
Link: Many degrees of multi-tenancy
- prev
- 1
- next
