Why All the Fuss Around Cloud API Standards?

Lately there have been several discussions around cloud API standards, and I am failing to understand why it is a big deal. Lets first identify two type of standards:

1. Syntax Standards
2. Functional Standards

For cloud lot of attention is given to syntax standards, e.g. using same method signatures. E.g. some IaaS enablers are using exact same method signatures in their APIs as Amazon EC2. After integrating with several cloud providers we found API differences (Syntax) may seem annoying but they really don’t matter much, as it is trivial effort to deal with them. E.g. how hard it is to deal with a difference like start.server , or start-server, or s-server all doing the same thing i.e. starting a server on various clouds?

In terms of functional standards, it is ignorant to expect that all cloud providers will provide the exact same set of functionality. Usually the way innovation works is that someone pushes the limit and deliver a new functionality and then other players in the industry try to catch up and implement the same functionality (given there is customer demand for it). Once the new functionality is implemented by all vendors it becomes an standard. The innovation cycle continues as some other vendor in the industry steps up to deliver new functionality and rest of the vendors follow to catch up. This cycle keeps on repeating till the technology becomes obsolete. It would be really stupid for anyone to expect that vendors will stop innovating after they reach some agreed common functionality. After integrating with several cloud APIs (IaaS), we have identified following functionality as the expected “standard” for the cloud (IaaS), and all major cloud players are delivering this (plus more). The method signatures may not be identical,across all the providers, however, the functionality offered by various providers is comparable for following.

Instance Management: Launch, Terminate, Suspend, Resume, Describe, GetIP, List
Image Management: ListImages, DescribeImage, CreateImage
Storage Management: CreateVolume, DeleteVolume, AttachVolume, DetachVolume, ListVolumes, VolumeStatus
Security: CreateKeyPair, DeleteKeyPairs, DescribeKeyPairs
Backup Management: CreateSnapShot, DeleteSnapshots,DescribeSnapshots
IP Address Management: AllocateAddresses, ReleaseAddress, AssociateAddress, DisassociateAddress
Firewall Setups: CreateSecurityGroup, DeleteSecurityGroup, DescribeSecurityGroups

The above list will change as IaaS providers will innovate more and deliver more functionality. E.g. right now the biggest gap is that no cloud providers gives SLAs around network, e.g. guarantee of minimum latency, bandwidth, etc. Some providers are providing additional APIs for creating private networks/VLANs etc and over the period to time the VLAN type functions would become more common across providers.

At Kaavo we took a top down application centric approach because we believe that cloud APIs will be different for different clouds and will evolve and we need to provide a consistent interface for deploying and managing workloads, regardless of the cloud. From the customer perspective two things are important:

1. Ability to deploy, configure, run workloads (custom apps, SaaS, PaaS) securely and automatically on-demand within in minutes on the IaaS layer (regardless of the IaaS provider)
2. Automation to manage run-time service levels

Because of our top down approach anytime a new functionality is added by a cloud provider or API is changed, we are able to handle it easily. For additional reference checkout how we easily handle the differences in server attributes across providers and also the web service API we provide for deploying and managing workloads in the cloud.

Join Us: http://bit.ly/joincloud