Now, the question is: how do you choose? Of course, there is no single answer. But from our experience working with Enterprise IT deploying Private Clouds, there are definitely a few things you should bear in mind when making your decision.
So here we go: what are the questions you need to ask to decide on your Private Cloud Platform? In the end, we’ll see that your choice should be dictated by the level of involvement you want with your Private Cloud, and the level of risk you’re ready to accept.
#1: Do you want a project or a product?
OpenStack differentiates from CloudStack and Eucalyptus in the sense that it’s not really a self-contained piece of software, or product. Instead, OpenStack is a project.
Need proof? Navigate to OpenStack’s Github account, and look for an “OpenStack” repo. It’s not there. Why? Because OpenStack is not code. Instead, OpenStack is an umbrella organization, a constellation of subprojects projects small and large that let you build your own Cloud Platform.
As such, OpenStack gives you a lot more control over the components you choose and how you configure them: as one of Scalr’s customers — an OpenStack user — put it: “got a problem with OpenStack? There’s a subproject for it!”
OpenStack’s Flexibility has a price
Unfortunately, this flexibility means that it’s a lot more work to get OpenStack up and running, and as such, OpenStack is the riskier option for your Cloud.
As a matter of fact, our experience with Enterprises deploying OpenStack has shown that the rate of first-time success with OpenStack is quite low when compared to the alternatives.
So before you decide on your platform, you need to ask: will you commit resources to take advantage of OpenStack’s unparalleled flexibility, and truly benefit from your choice of platform? Or would you rather install your Cloud Platform and move on to something else?
Update: What about OpenStack distributions?
Reuven Cohen pointed out on twitter that this article initially didn’t mention the fact that there are numerous “productized” OpenStack distributions out there, which are supported by integrators.
A distribution is of course easier to install and maintain, and you can get commercial support for it. As such, using a distribution constitutes a less risky option, technology-wise.
However, bear in mind that there is a large — and growing! — number of competing OpenStack distributions, so you’ll have to choose an integrator that you trust will keep their distribution up to date. Ultimately, opting for a distribution is a tradeoff between technology risk and supplier risk.
So — haven’t made up your mind yet? Let’s move on to our next differentiator.
#2: AWS Compatibility
AWS is the elephant in the Cloud room: although we’re talking about Private Clouds here, we all know your engineers are going to want to use AWS too.
Compatibility with AWS happens to be the other big differentiator between our Cloud Platforms.
OpenStack is the odd one out on AWS compatibility
On the one hand, Eucalyptus has support for most of the AWS APIs (including EC2, S3, EBS, IAM, AutoScaling, CloudWatch, and ELB!); it is, as they say, “like having your own AZ”. And although CloudStack isn’t anywhere near Eucalyptus in that regard, it does reasonably well with a compatibility mode for the AWS APIs.
On the other hand, OpenStack doesn’t have any level of AWS compatibility. And according to Cloudscaling CTO Randy Bias, OpenStack may even face "irrelevance and death" if it does not eventually converge to use the AWS APIs, which he considers are the de-facto standard for Cloud (you might want to read this rebuttal from Robert Scoble of Rackspace).
But should you rule out OpenStack on incompatibility? There are really two things at play here.
Does OpenStack need AWS compatibility to survive?
Of course, you certainly don’t want to bet on a dying horse. But does OpenStack need AWS compatibility to survive?
It’s still early to tell; but with the largest contributor and user base of all three Cloud Platforms, and impressive corporate support, OpenStack definitely has muscle of its own.
In the end, the key deciding factor here should be your own needs.
Do you need AWS compatibility?
There are three reasons why you might.
The first one is the ability to cloudburst, that is, to run your baseline infrastructure on a Private Cloud, and expand to a Public Cloud to face traffic spikes. Well, bear in mind that although cloudbursting is very attractive, it’s oftentimes impractical, if only for network reasons.
The second one is the ability to develop your applications on one platform and deploy them on another. This lets you minimize your time to market, and get better control over your infrastructure costs. This may be a reasonable reason to rule out OpenStack, but definitely make sure that you would actually be doing it if you had the ability.
The third and last one is the ability to reuse the AWS tooling that you built — or purchased — with your private cloud. Of course, before you make a decision based on this criteria, bear in mind that there is also tooling to abstract incompatibilities away — that’s the goal of the Apache Deltacloud project —, and that a lot of tooling is cloud-agnostic, that’s of course the case with Scalr.
#3 Do you want to make running a Cloud a core competency?
OpenStack is obviously the most polarizing option out there. It’s very configurable, but it’s hard to get right. It has the most momentum, but it’s not compatible with the Public Cloud your developers want to use.
Ultimately, the best question to ask is this one: how involved do you want to be with your Cloud? Are you going to dedicate engineers to take advantage of OpenStack’s flexibility? Are you going to dedicate resources to acquire the tooling you’ll need to make your software multi-cloud in spite of API incompatibilities?
In other words, do you see Cloud as a strategic, core, competency that you want to develop to gain a competitive advantage? If yes, and if you’re ready to accept the inherent risk, then OpenStack may very well be your best option. If not, then you should probably be looking at CloudStack and Eucalyptus instead.