Tuesday, January 20, 2009

Cloud API Propagation and the Race to Zero (Cloud Interoperability)

The Mountain View cloud interoperability discussion has finished and based on the amount of activity in the twitter dialogs, I would conclude it was a complete success. Because I wasn't able to attend in person, watching the various twitter feeds was my only real insight, but in that process a few thoughts came to mind.

When thinking about what Cloud Interoperability truly means, for me it's all about the API. There is much talk of ID / Authentication, storage, networking, system management and so forth. The one problem that all these various aspects share is that point of programmatic access / control. What seems to have happened over the last year is what I've started calling "cloud API propagation". Every new cloud service provider puts there own spin on how a user or cloud application interacts with "their cloud".

The problem I see is each cloud appears to be a silo upon itself. By each new cloud providing their own new API, which effectively means that your only real option is to go with the largest player, not the best. API propagation is killing the cloud ecosystem by limiting cloud choice and portability. In order to use Amazon, I am being forced to choose their way of cloud interaction / control over any others including the ability to use my existing data center resources seamlessly. One of my driving factors toward the creation of a unified cloud interface is not only to enable portability (which is nice), but enabling singularity between existing "legacy" environments into the cloud and back again. From what I see of those who are building their entire infrastructure in the cloud, if given the option to move to another cloud provider, chances are they probably wouldn't. Just because you give someone the ability to leave doesn't mean they will.

Benson Schliesser from Savvis raises a very good point in a recent twitter dialog. He says I'm pro-API. But it may also accelerate commoditization. Are prices exposed via the API? Does that make it a race to zero? He goes on to say "that means there will be niche players and everybody else is just LCD. Enabled by an app that finds lowest price via API."

So the question is who does cloud interoperability really benefit? I would say legacy businesses who have existing data centers as well emerging cloud providers who are looking to compete not based on a unique API but rather on other unique service components they offer.

Sure, there will always be the value focused customers, who choose the lowest cost option. But there will also be cloud consumers who are looking for specific answers to their particular problems. Those are where the true opportunities are.

Being a cloud provider shouldn't be about your API. It should be about the applications they enable. I'm going choose to use the Savvis or GoGrid or Amazon cloud because they provide better Support, SLA's, QoS, geographic capabilities or possibly something I've never even imagined. Those are the ways you can differentiate your cloud. Saying "our API is better" is a poor marketing strategy. I believe saying your cloud is compatible or can work with what you already have is a better one.

#DigitalNibbles Podcast Sponsored by Intel

If you would like to be a guest on the show, please get in touch.

Instagram