The Open Source private cloud social scene has been in a real brouhaha over the last few weeks. Media attention has focused on partnerships and software re-licensing. There's also been talk of mis-aligned hypervisor support and a couple of EC2 API compatibility debates.
It's time to take a look at exactly what matters when it comes to getting serious platform adoption - making small development team's lives easier.
The primary reason EC2/S3 API compatibility matters is the sheer amount of code which has been written against Amazon's APIs. If a developer has written a ton of code to talk to AWS, it's unlikely they would want to spend the time or effort porting all their calls to support a separate API. This is probably one reason there is such a clamor on the Internets for standardizing cloud APIs.
This is also evidenced in the fairly uniformed EC2/S3 support provided by OpenStack, Eucalyptus and Cloudstack. Providing support for EC2 calls makes it easier to extend infrastructure building calls into a private cloud offering.
The OpenStack wiki has a fairly detailed API compatibility matrix showing support for the main calls to the EC2 APIs. With the exception of Eucalyptus' lack of documentation, both OpenStack's EC2 support and CloudWatch's CloudBridge EC2 support provide all the basic features for launching servers:
| Feature | OpenStack | Eucalyptus | CloudStack |
|---|---|---|---|
| Register/Deregister Images | |||
| Launch/Terminate/Reboot Instances | |||
| Create/Delete/Describe Keypairs | |||
| Allocate/Associate/Release IP Address | |||
| Create/Delete/Describe Snapshot | |||
| Create/Delete/Attach Volume | |||
| Create/Delete/Desc/Auth/Revoke Security Group |
Each project allows you to create OS images, spin up instances, give them keypairs, assign them floating IPs, control their firewall rules, attach volumes, make snapshots, and shut the whole thing down when you are done.
tl;dr; Servers at a click!
Not all EC2 API features are supported by the separate projects, and some are not supported at all. In general, there are some small subtle difference between the support of the EC2 APIs. Let's take a look at who supports what, if at all:
| Feature | OpenStack | Eucalyptus | CloudStack |
|---|---|---|---|
| Paid AMIs | |||
| Spot Instances | |||
| Reserved Instances | |||
| Instance Bundling | |||
| Tagging/Filters | |||
| CloudWatch (monitoring) | |||
| Elastic Load Balancing | |||
| VPC IPSec | |||
| Create Image | |||
| EBS Backed Instances | |||
| Import Keypairs | |||
| Describe Region | |||
| Console Output |
Here's what isn't supported: Paid AMIs (a tasty thought for revenue), spot instances, reserved instances, instance bundling (to AMI), monitoring, and tagging/filter support is, by and large, not supported by anyone. CloudStack has a few filter calls, but they are minimally supported. Someone should really add tagging support.
CloudStack has the upper hand on the load balancing calls. It should be trivial to add load balancing calls to the other projects to support devices like a F5 or Netscaler box though. Citrix, the authors of CloudStack, also owns Netscaler. They do happen to have an image you can launch which contains a load balancer based on HAProxy. I'm not sure if the code for that is publicly available or not. Comments?
CloudStack also support EC2 API equivalent calls for creating IPSec on VPCs. I've never done it, but I hear it's nice. Support for creating images is also provided.
Eucalyptus, for all the press they got with their Amazon press release, actually appears to support the least of all the under-supported EC2 features. The only thing they've got going for them here is the describe-region call that CloudStack doesn't appear to support at all (according to their docs), and the console-output call. Region support in OpenStack is essentially the ‘project' feature they provide. Nice.
CloudStack argues they support the console output call via the GUI, but according to their docs they don't support the EC2 API equivalent calls. I'm pretty sure those are used by RightScale.
OpenStack and CloudStack support starting and stopping EBS backed instances with the EC2 calls, although they aren't really stored on an Elastic Block Storage device. Still, it's cool to be able to pause an instance and then start it back up later. Eucalyptus should support this.
In general, I think most of the calls developers would be using are covered by each of the three projects. The difference in method support seem minor in many ways, and anyone trying to make a big deal of it is probably just splitting hairs at this point. Stop being a tool.
I really like the idea of CloudStack's support for load balancing. I think it's often times overlooked, and difficult to configure correctly. Not having used CloudStack's solution, I can't can for certain if it works well or is easy to set up, but it sounds great! :)
Monitoring is an absolute must have here. CloudWatch provides some simple monitoring (haven't managed to get it running yet, so will report back), but none of the projects do a very good job of it, nor support the EC2 APIs for it. I would imagine this would be a feature most users would want. I wonder how many people actually use the calls for CloudWatch. I hooked it up myself to do simple monitoring a while back, but never ended up using it seriously.
If you have any factual corrections for my post, please feel free to comment below. Be sure to contribute to the OpenStack wiki if you see errors there as well!
In my next post I'll be covering the support for the S3 APIs by each project. All three appear to have support for it, but it's poorly documented on all fronts.