Should OpenStack Embrace Amazon AWS? 27
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."
Nobody cares (Score:1)
Nobody cares. This is Randy just being Randy and making noise to stay relevant.
Most people just use a library not the raw API anyhow, and at this stage both APIs work.
Duh (Score:2)
Always wanted to make an application called cloud burst, that lets you move all cloud providers, move your resources with a touch of a button.
Amazon throws tons of money in the shorter term to own cloud computing in the long term. Openstack is still green and needs support. If they embraced AWS/Rackspace they might get more support and become a perfect fit those times when AWS isn't the best option. Want to run a lab? A 1500 dollar blade is works just fine. Want to run a few heavy duty load balancers,
Re: (Score:2)
You know, OpenStack is more like a framework you can use to build your own cloud.
I think it will get some reference implementations soon that will make it easier to deploy it.
Because then they'll can make more ready made scripts to deploy certain implementations.
Re:Azure (Score:4, Funny)
Re: (Score:3)
What about the other 90.000000000001% of the time? Is that the maintenance window?
Re: (Score:2)
Re: (Score:2)
Rebooting after installing bug fixes. For the bug fixes.
Re: (Score:2)
Well, the lawyers haven't seen enough convincing case rulings, yet. And we know lawyers screw up everything.
the importance of dominant designs (Score:3)
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: (Score:2)
We would have had a better architecture that was more green, had people not followed the lemming principle in making their choices.
Re:the importance of dominant designs (Score:4, Interesting)
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: (Score:2)
You bring up an interesting and relevant point about how various APIs are used by the applications. But when I think about how the world of software is evolving, it seems that those management APIs are becoming more important, because a software application of today must know not just how to run, but also how to be deployed.
Use Eucalyptus (Score:1)
If you want AWS compatibility, use Eucalyptus. It's solid, proven, open source. I've never understood the hype around OpenStack.
Re: (Score:2)
I can't stand either API design. I want a cloud provider that lets me design my own API.
Re: (Score:1)
Then opennebula [opennebula.org] may be more useful to you, if only in that its designed to be easily extendable in that manner.
Use it as a starting point (Score:3)
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.
That's why we're using Eucalyptus. (Score:1)
Given the goals of OpenStack I'd prefer using it, but running a cloud provisioning student learning instances in an academic institution with the academic discounts from Amazon makes it a no-brainer to run a system that allows our cloud to peak into AWS. Repeated discussions with Rackspace about meeting/beating this deal make it clear that they can't even begin to do that. And we have to get the most bang for our buck to ensure our students have optimal systems for their learning.
Wrong questions, management tools already do it (Score:2)
Disclaimer: I work for Red Hat on the Security Response Team and I'm one of the cloud guys so I'm biased (but I also work with OpenStack upstream). I'm also the CVE guy (plug: remember kids, get your CVEs early and life is better for everyone! http://people.redhat.com/kseifrie/CVE-OpenSource-Request-HOWTO.html [redhat.com]).
Adding support for this into OpenStack for AWS EC2 is really the wrong layer, this makes a lot more sense in the Orchestration layer. We already have a product that supports this: CloudForms [redhat.com], it can
Re: (Score:2)
I think Heat will be even more awesome than AWS Cloud Formations, because they are working on supporting a second, easier, syntax.
jclouds abstraction (Score:1)
The jclouds framework [apache.org] enables abstraction of your cloud (read: IaaS) layer. I don't work for these guys but I've seen it used in several tools. Using tools based on jclouds makes it easy to shift your deployments from one cloud to another, be it public or private. There are other concerns when doing that, such as synchronizing the data that needs to be available in each specific deployment, but there are tools for that as well.
Here is a quote from their "What is jclouds?" page:
jclouds is an open source library that helps you get started in the cloud and utilizes your Java or Clojure development skills. The jclouds API gives you the freedom to use portable abstractions or cloud-specific features.
jclouds tests support of 30 cloud providers and cloud software stacks including Amazon, Azure, GoGrid, Ninefold, OpenStack, Rackspace, and vCloud...jclouds offers several API abstractions as Java and Clojure libraries. The most mature of these are BlobStore and ComputeService.
Re: (Score:2)
The point of supporting the AWS API is to support existing running code from people that didn't have the foresight to pick an abstraction layer.