CloudStack vs. OpenStack: My Experience

Before anyone starts to rant or panic, a few disclaimers:

• We love both CloudStack and OpenStack. In fact, we wrote and shared a connector to allow OpenStack Swift to authenticate against CloudStack.
• We are a Citrix CloudAdvisor and have deep expertise with the Citrix CloudPlatform and Cloud Portal Business Manager products, and by extension, CloudStack.
• We want to continue to provide our customers with the best solutions on the market to achieve their business goals as fast as possible.

In this context, here are the results of some of our own experiences experimenting with and comparing CloudStack 4.0.1 and OpenStack Grizzly.

Speed To Production

As discussed above, rapid time-to-value is important for us, and unfortunately OpenStack does not perform well in this respect. Excluding network setup (which is the same for both solutions) and OS installation, my first deployment of a CloudStack cloud with two XenServers took less than two hours. When I first installed OpenStack, I failed a few times. Even with reasonable “how-to” documentation (it’s so hard to find good documentation!), it took me about three days to figure out all the various components and have a working cloud with one KVM-based compute node. I used Quantum; perhaps there is a simpler option using Nova.

Documentation

We all complain about documentation, and CloudStack doc is not perfect. But, at this point in time, I believe that CloudStack documentation is still one step ahead. It is better structured, and you can actually follow it and get something that works. With OpenStack, things are less clear and there is no “step-by-step” installation guide.

Installation Process

The installation process is probably one of the largest drawbacks: to install OpenStack you must install every component individually (Keystone, Nova, Glance, etc.) and you must manually create MySQL databases and users. Quite tedious! There is definitely room for improvement here, and I believe some distributions are trying to address this need. Currently there are packages, but there is still too much manual work to do. There should be a Bash script or a Python script at least — I’ll keep looking. Finally, you must also tweak many different configuration files for each module. In a word: painful.

Community

I think we can agree that OpenStack has the lead here. In fact, when you look at pundits such as Randy Bias advocating OpenStack, the majority of the arguments for OpenStack’s leadership have to do with the size of the community: the number of users, developers, commits, etc. OpenStack is also backed by large industry players so a lot of attention (and money) is driven to the project, mostly by the industry’s fear of AWS.

Still, if you believe that the OpenStack ecosystem is positioning itself against (or at least in contrast to) AWS, then you could also argue that CloudStack benefits from the entire AWS ecosystem, as an increasing number of users recognize the benefits of having resources in public or private cloud environments, as CloudStack and AWS do play nicely together.

Features

Again, at this point in time, the CloudStack feature set is ahead of OpenStack, and CloudStack remains more user friendly. For example, to install a template on OpenStack, you must use Glance’s CLI tool. In CloudStack, you simply use the GUI. For day-to-day use and resource visibility, CloudStack is a step ahead. Additionally some features like VPN and external service providers are not supported in OpenStack yet.

Architecture

While CloudStack’s approach is to have all logic as centralized as possible, OpenStack’s vision is completely different. It uses an enterprise message service (RabbitMQ) and everything is built in separate modules. The good thing about having multiple modules is that you install what you need, and you can easily scale different pieces in an asynchronous manner — and that has been an argument used many times by OpenStack proponents. However, this approach quickly creates a significant level of complexity, both at the operational level (i.e., to deploy, manage, and scale an environment), as well as the development level (i.e., to coordinate the coding efforts of all vendors). What would happen if IBM and HP don’t agree? Yes: the message heard at the recent OpenStack conference was that “we want OpenStack to ‘win’ and we are not in a fight with each other.” But think about this: how will these companies differentiate their offerings?

Bottom line

In the end, both projects have their own issues, and both have rough edges to be addressed. CloudStack is a stable project but it is still going through its adolescence; it was just recently released into the Apache Foundation and is balancing the need to add new features with improving existing functionality.

All this being said, I continue to believe that CloudStack is the more stable of the two today and easier to deploy. If I had to choose one for a production environment, I would go with CloudStack. However, it will be mandatory to keep an eye on OpenStack. I see increased support for OpenStack among industry leaders, which may be enough to put OpenStack in a leadership position.