I am frequently asked by analysts, users, the media and even other vendors about the production readiness of OpenStack, to which I affirm in the positive. There are also often questions about the differences between the various OpenStack distributions and offerings. I answer whenever possible by drawing the distinction between OpenStack as the open source project and as the products and services available to help make it a production-ready cloud platform. If you are unclear about the difference between an open source project and a product, I hope this blog post serves as a useful primer. I will highlight the concept of OpenStack as a service offering (yes, Cloud-as-a Service is a thing) to the concepts of project and product, using our Rackspace Private Cloud (RPC) as the canonical example for both a product and a service. To help illustrate the distinctions, I will discuss the differences between the three offerings by examining three categories:
I recognize that at least two of the above categories could be subsumed under cloud operations; however, I want to call them out because they are handled differently depending whether you consume OpenStack as the project, as a product or as a service.
By the way, I am indebted to Aaron Delp from Citrix and fellow Racker Dale Bracey for informing my thoughts on this subject. Aaron wrote an excellent article last year on the topic of “Comparing Open Source Projects To Products” and Dale addressed the topic in the Rackspace Community Forum in response to a question regarding Xen support in OpenStack and the Rackspace Private Cloud.
The OpenStack Project
Like other open source software projects, the OpenStack source code is freely available to download and to use. Released under the Apache 2.0 license, the OpenStack cloud platform software can be deployed by anyone without having to purchase the software or pay a right-to-use license. In fact, anyone can modify the OpenStack code and distribute it with or without submitting back enhancements or fixes; in the latter case, this is considered forking the code. Typically, however, changes to the source code are submitted back to the project and reviewed to determine if it should become part of the core code. With the number of sub-projects within the OpenStack project, code changes happen frequently with major releases occurring every six months. This can be bewildering to users who are unfamiliar with this cadence and are not sure how to go about properly consuming OpenStack.
For many users, trying to deploy and run OpenStack using the core code is akin to being handed a giant bucket of LEGO blocks and told to build a model city. This is particularly true, I find, for businesses that are used to having software that is neatly packaged; having a single number to call for support; and often having a technical account manager assigned to them and who they can turn to when there are issues.
When an IT shop chooses to deploy directly from the OpenStack project code, they essentially assume 100 percent of the responsibilities for deployment, management and support:
Typically, I advise customers to choose an OpenStack-powered product or service, like our Rackspace Private Cloud, when they are considering production deployments, unless they have developers and engineers who have both the proclivity and the time to do OpenStack development, packaging and support.
Rackspace Private Cloud: The OpenStack-Powered Product
Given some of the challenges with deploying a complex platform such as OpenStack, a large ecosystem of vendors have formed to meet that challenge by productizing the OpenStack software. This is a typical revenue model for vendors that can charge for the value-add they may bring to open source software, though they are not allowed to charge for the OpenStack software itself. Products that exemplify this include Mirantis OpenStack, Piston OpenStack, Rackspace Private Cloud and Red Hat Enterprise Linux OpenStack Platform, among others. In each case, these vendors have taken the core OpenStack code, packaged it with a strong opinion on how to best deploy the software in production, and added supporting software to fill in perceived gaps in the software.
When an IT shop chooses to deploy a packaged cloud platform, built using OpenStack code, they offload some portion of the deployment and support to their vendor of choice while retaining most, if not all, of the day-to-day management:
My advice to customers who take this approach has been to choose vendors that provide value with their products without forking the core code. Otherwise, they run the danger of being locked into a specific vendor and losing much of the benefits of open source software. For example, Rackspace has chosen to stay with the core code in our RPC product.
Rackspace Private Cloud: The OpenStack-Powered Service
Another way to consume OpenStack, and the way that Rackspace believes provides customers the fastest time to value, is as a service. The most obvious way to do this is to leverage an OpenStack-powered public cloud such as the HP Public Cloud and our Rackspace Public Cloud. However, there are also hosting providers, including Blue Box and Rackspace, that use OpenStack as the underlying platform for a private cloud as a service offering. Rackspace, in fact, pioneered this and is the clear leader in offering OpenStack as a service through Rackspace Private Cloud (also RPC) managed service. The value proposition here is that an IT shop can gain many of the benefits of the public cloud in a dedicated single-tenant cloud environment. The tradeoff is that RPC as a managed service has an more definitive opinion on how to deploy OpenStack than an OpenStack-powered product does and therefore a smaller subset of supported options and features is made available. This is typically the case because offering private cloud as a service to multiple customers requires a high degree of standardization on a particular set of supportable features. The more variation, the more difficult it would be to provide the level of support required for a managed service. But the benefits are similar to those of our public cloud – RPC enables customers to focus on application development and business processes instead of managing and proactively supporting the underlying cloud platform and infrastructure. The burden of management and proactive support is taken on by Rackspace, which leverages our experience running the world’s largest OpenStack-powered public cloud and applying it to our private cloud as a service offering.
As mentioned, when an IT shop chooses a managed private cloud service like RPC, it is able to offload deployment and support and much of the day-to-day management:
As analysts, the media and users try to discern the viability of OpenStack and understand the different offerings available in the market, I hope this post is a helpful guide. In particular, I encourage OpenStack observers to pay more attention to the different ways that OpenStack can be consumed as they evaluate the different vendors and their offerings. If you are an end-user and considering your OpenStack deployment options, I encourage you to look at the different offerings and consider the value that Rackspace Private Cloud can offer.