My day job is to try and choose and influence Cloud technologies so it’s no surprise when to hear different vendors pitching why their cloud API is more open, standards based, or performant. They have convincing yet irrelevant arguments: the primary measure of a cloud API is the size of its ecosystem.
The API’s ecosystem is the number (and vitality) of the upstream partners, SaaS services, PaaS vendors, and ISVs that have built their business on top of that API. The fundamental truth of this model, like all ad hoc IT standards, is that success is built on business traction, not on technical merit or endorsement by standards bodies.
So which Cloud API will be the winner? We’re just rounding the first turn and Amazon is ahead. Let’s look at the lead fillies
- Amazon EC2/S3 has the clear leadership. Their API is widely copied (without clear license to do so!), includes storage and their billing model is highly innovative.
- Microsoft Azure is making a big push. Windows continues to dominate as a platform and their SQL cloud helps address application porting. In addition, their PaaS integration provides a forward migration.
- VMware vCloud has taken to high road through the official standards bodies. VMware dominates the private cloud space and their vCenter API represents a larger ecosystem than any other virtualization API. This ecosystem guarantees that vCloud will be widely adopted but if they can cross over into public clouds is fuzzier.
- RackSpace has an interesting position by offering both dedicated and shared hosting. Their service and API have been along for a long time. They have just not created the buzz that Amazon gets. They could be a swing vote depending on their future decisions around Cloud APIs.
But maybe we don’t have to pick the winner! Perhaps there’s an option for a trifecta bet where we don’t have to pick a single winner. This scenario of building a multi-API abstraction layer is getting a lot of interest and creating a lot of value. Vendors include RightScale, DeltaCloud (was RedHat, now Apache), and jCloud.
Right now, I’m sitting in the Delta Cloud session at RedHat Summit/JBoss World. One of my concerns about API aggregation is that the API abstraction has to be either least common denominator (LCD) or have strange exceptions. For example, the speaker is saying that approaches to Firewalls are very different or completely missing. This creates a serious aggravation for aggregation: does the API leave a gap, favor one API, or invent yet another way to solve the problem.
I believe the cloud API race is not just a single horse race for the Cloud Computing Cup, it’s more like the Triple Crown. The real winning API will cover compute, network, and storage management.
Then again, accelerating PaaS adoption could make these IaaS Clouds into buggy whip manufacturers.
Disclosure: My employeer, Dell, is a partner with many of the companies listed above.
I’ve argued previously that data portability is one of the most critical aspects to consider when evaluating these new services, and your post relates to it — how portable are the /apps/ among these services. There /are/ some “cloud standards” bodies today, but I haven’t seen much substantive to date, so you’re right that we’ll probably see some de-facto standards emerge; MSFT and AMZN among others already participate in some of those bodies. Time will tell what happens; shipping working code wins, as you suggest.
While AMZN has a strong lead (and a well-deserved one), it’s not the end of the game; the industry is a couple minutes into the first quarter at most. Standards will emerge, but I think I agree more with your point that it’s hard to envision “one true standard to rule them all”. (I agree that the Eucalyptus/Ubuntu work is cool, but won’t be the last entrant for sure.)
For example, I can easily envision scenarios where I need “raw virtuals” on AMZN /today/, but build next-gen software for PaaS services like Windows Azure.
And finally, taking off my MSFT hat for a sec, as always, we as builders all have to do our due diligence as software architects and ops teams to ensure that we’re using the right tool for the problem, not racing off toward arbitrary standards just for appearance’s sake.
Well said. I believe the cloud API wars look very much like the early SQL battles. Even today, there are a lot of small wiggles between SQL dialects that create substantial vendor lock-in in exchange for performance tuning.
One of the challenges with people following ad hoc standards is that it’s very hard for the copier to have a completely true copy.
I wanted to link in this post by James Urquhart about Amazon’s API and it’s adoption by other cloud infrastructure products:
http://news.cnet.com/8301-19413_3-20010072-240.html “Amazon APIs as cloud standards? Not so fast.”
Pingback: Are VMs becoming El Caminos? Containers & Metal provide new choices for DevOps | Rob Hirschfeld