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:
- Deployment – How do you install and upgrade an OpenStack cloud?
- Management – How do you perform day-to-day tasks like provisioning cloud resources?
- Support – How do you monitor for and troubleshoot problems in your OpenStack cloud?
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:
- Deployment – While the project does provide some guidance, the user takes ultimate responsibility for testing the OpenStack software with a particular hardware stack and choosing what to deploy. While there are different tools available for deploying OpenStack, the user is responsible for choosing and integrating theses tools. When the OpenStack project release new core code, the user is also responsible for testing the new code with their particular OpenStack environment and determining the best upgrade method to use.
- Management – Here, users assume day-to-day responsibilities for managing and operating their OpenStack cloud. This includes capacity planning, deploying new hardware resources to support OpenStack, and managing the various resources created by the OpenStack platform, such as compute, networking and storage.
- Support – Support for the OpenStack project is provided via the community using channels such as IRC and community forums. However, users are responsible for monitoring their particular OpenStack environment and troubleshooting issues in the infrastructure.
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:
- Deployment – One of the key value-adds of the RPC product is the packaging done by Rackspace to ease software installation issues and to enable rapid deployments at scale. This includes packaging RPC with Chef, an industry leading configuration management tools. In addition, Rackspace provides reference architectures and recommended hardware lists that prescribe a particular way to run OpenStack in production. If a customer chooses to consume RPC strictly as a product and not as service, they are responsible for standing up and upgrading their own OpenStack cloud platform.
- Management – In the OpenStack as a product model, the day-to-day responsibilities for managing their cloud platform continue to reside primarily with the customer. In many cases, Rackspace may assist by providing some recommended practices for how to manage and operate RPC.
- Support – Probably the biggest reason an IT shop would go with an OpenStack-powered product, like RPC, is the convenience of having a single source for support for their cloud platform. Instead of only relying only on the wider OpenStack community for software fixes, a customer can also rely on Rackspace to be their advocate in navigating the open source waters and in writing fixes that are then given back to the project. However, as is the case with management, if a customer chooses to consume RPC strictly as a product and not as service, then they take primary responsibility for monitoring their OpenStack cloud platform. Customers also have the option of purchasing RPC Escalation Support, which provides them with 24x7x365 remote support, similar to what they would receive from other OpenStack vendors that sell software support.
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:
- Deployment – In this model, deployment is primarily the responsibility of Rackspace, working in concert with the customer. If the actual environment is being hosted on customer premises, the customer is generally responsible for facilities and hardware while Rackspace is responsible for deploying RPC. If Rackspace hosts the RPC environment in our data center (which is more common), we assume sole responsibility soup-to-nuts for hardware and software deployment. In addition, Rackspace takes responsibility for all upgrades.
- Management – The day-to-day management and operations of RPC are generally divided between the customer and Rackspace. Typically, Rackspace manages the underlying infrastructure while customers manage the virtual resources created by the platform. Though in some cases, customers choose to offload all the infrastructure management to Rackspace. In both cases, Rackspace will collaborate with our customers on tasks such as capacity planning.
- Support – One of the selling points for vendors that offer OpenStack as a service, such as Rackspace, is that they are not only the single source of support for the customer’s cloud platform, but they actually take responsibility for proactively monitoring and taking action to support that platform, including handling patches and upgrades.In a Rackspace hosted and managed RPC deployment, we also proactively monitor and troubleshoot issues with the underlying hardware.
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.