Should OpenStack Embrace Amazon AWS?

jfruh writes "Practically since OpenStack was started there has been discussion about whether it should fully support Amazon Web Services' APIs. Doing so would make it easy to port applications between an OpenStack cloud and AWS. It would also let businesses easily build hybrid apps that run internally on an OpenStack cloud and on AWS. Cloudscaling's Randy Bias has been vocal about his support of fidelity with AWS. He argues that there's no hope for OpenStack in the public cloud market so it would do well to support interoperability with AWS and Google Compute Engine if it wants to hold on to the private cloud market. It's true that interoperability with AWS would be good for OpenStack in the private cloud market. But it's easier said than done."

Comments

the importance of dominant designs

[martenmickos]

I believe it is both difficult and important to align with dominant designs. 30 years ago it was a good bet to develop software for the new x86 architecture, 15 years ago it was a good idea to bet on the new world-wide web, 10 years ago on the new LAMP stack. Today, the API layer is where different pieces of software come together and where brilliant software developers congregate. It's about AWS, but it's even more about the new design paradigm that the AWS APIs represent. Of course there will not be just one set of APIs. We know that in addition to AWS, we have OpenStack, Microsoft, VMware and Google are all building theirs. One of them will be dominant. Randy Bias brings forward an important point.

Re:the importance of dominant designs

[cartman]

Hi Martin. How are things. I didn't even realize you were a slashdot reader. (I worked at Eucalyptus until fairly recently).

In my opinion, cloud APIs are different from the other APIs or architectures you mentioned (WWW, x86/windows, LAMP), in that applications are not written for a particular cloud API. The cloud API is exposed to cloud management tools, not to the applications which will run in the cloud. Thus, the same application will run on either an AWS cloud, or a Rackspace cloud. This situation is quite different from (say) the windows API, which had applications written specifically for it.

The big exception is S3, but the S3 API is very simple and can easily be handled by a compatibility layer.

Furthermore, almost nobody interacts with any AWS API (except S3) directly. Sysadmins interact with the AWS API through tools, like command-line tools and web consoles. The AWS API is only truly important to people who write cloud management tools.

The value of AWS compatibility is in two things: 1) familiar cloud management tools, and 2) hybrid clouds.

Perhaps OpenStack should make a suite of command-line tools and a web console, which resemble Amazon as closely as possible. That way, any deployment scripts etc would continue to work. It doesn't matter very much which web service API the tools are communicating with.

Also, OpenStack may need to support hybrid OpenStack/Amazon clouds in the future. This depends upon whether hybrid clouds take off.

Let me know if you think there's something I'm missing here.

Best,
-t

Re:Azure

[gmuslera]

This, you can't defeat a service that ensures 9.999999999999% of uptime.

Re:Azure

[Skapare]

What about the other 90.000000000001% of the time? Is that the maintenance window?

Use it as a starting point

[Natales]

OpenStack has the potential to become the ultimate IaaS multi-vendor glue API, and now that the Foundation is established and a number of large players are committing resources and actual code (VMware, HP, IBM, Rackspace, etc, etc), things are taking shape at an amazing rate.

I'd say yes, embrace the AWS API as a baseline, just to make sure developers can port their applications as seamlessly as possible from AWS to OpenStack and viceversa. Just don't think this has to be all or nothing. Since not every use case can be fulfilled by AWS, I see absolutely nothing wrong with creating brand new APIs and operational models to address the needs of whomever is implementing OpenStack out there, as long as it's clear that using them would make your application incompatible with AWS. For many use cases, that's irrelevant.

Kudos to AWS to having come out with that model, but innovation cannot stop for fear of incompatibilities.