Slashdot Mirror
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."
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.
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, hit the cloud provider. Want 1 app to manage it? AWS has a bunch of 3rd party desktop managers for billing, reporting and maintenance. Openstack could come in and clean up.
Problem I've always had with openstack was its complex design, extra network and view of hardware resources is just fugly. I used puppet/kvm with a few scripts and it was much easier for me to maintain. I deployed almost a thousand VM's from a puppetserver with cobbler on multiple location with hundreds of blades.
I spent most the time in Excel working with devs on hardware requires on cpu/memory/disk usage and node count and network design. This is what I need automated.
I was looking at Openstack to replace the excel spreadsheet that keeps all my configurations. Make it simple. I wanted a vmware like interface on top of well known linux technologies with an configuration import button. But that never happened. No way am I manually typing in configurations, and I dont want another network for openstack management.
So now, I'm using AWS. Still using puppet, but ec2tools work mostly for me. Still dont have a good configuration management tool, EC2 desktop is lacking basics. Could Openstack fill the need? Maybe, but it needs to think of its users needs not its devs fun programing projects.
Why AWS? Azure offers nearly 100% feature parity and is generally easier to use and has more transparent billing.
How many times does this have to go around? You can't copyright interfaces and APIs because they are functional affordances. It's no different than the keyboard commands in a spreadsheet (Lotus vs Borland), or the functionality of a UI (Apple vs Microsoft), or the rules of a game, or an algorithm. Oracle is losing its ass in court over this right now.
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.
If you want AWS compatibility, use Eucalyptus. It's solid, proven, open source. I've never understood the hype around OpenStack.
No.. Jeff Bezos has enough toys.
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.
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.
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).
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, it can manage systems via OpenStack, RHEV, AWS EC2, etc. referred to as Open Hybrid Cloud/. Another aspect of this is that many customers already have significant investments in virtualization infrastructure, asking them to throw it all out for OpenStack (so all the software, training, backup software, etc.) won't always happen (although many are quite happy to add OpenStack to the mix).
So the latest release with the first iteration of the HEAT components don't exist? HEAT provides an interface to write to openstack using AWS Cloud Formations.
The jclouds framework 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.
sigo ergo sum