Introduction
Recently, my Rackspace colleague, Cody Bunch, and I had the opportunity to sit with Dave Vellante, from Wikibon, to discuss OpenStack in the Enterprise. During the interview, Dave asked about the readiness of OpenStack for production deployment; we answered in the affirmative but also took time to draw the distinction between OpenStack as an open source project and the products that have sprung up to help make it a production-ready Cloud platform.
This distinction is one that I and others in the OpenStack community have endeavored to make clear to analysts, users, the media, and even other vendors. The subject comes up often when I am asked about the readiness of OpenStack for production and about the differences between the various OpenStack distributions. If you are one of those who may be unclear on the difference between a project and a product, I hope this blog post will serve as a useful primer. Note that in this post, I will be adding the concept of OpenStack as a service offering (yes, Cloud-as-a Service is a thing) in addition to the concepts of project and product. To help draw out the distinctions, I will talk about the differences between the three offerings in relation to three areas:
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 areas could be subsumed under Cloud operations; however, I want to call them out because they are handled differently depending on if you are consuming OpenStack as the project, as a product, or as a service.
Also, 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 product.
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 6 months. This can be bewildering to users who are unfamiliar with this cadence and am not sure how to go about 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 and told to build a city. This is particularly true, I find, for businesses that are used to having software that is neatly packaged, a single number to call for support, and often a technical account manager assigned to them that they can turn to.
When an IT shop chooses to deploy directly from the OpenStack project code, they essentially assume 100% 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 resource 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 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. I suggest they get involved in the project to learn the technology and to get involved with the community.
OpenStack Powered Products
Given some of the challenges with deploying a complex platform such as OpenStack, a large ecosystem of vendors have arisen to meet that challenge by productizing the OpenStack software. This is a typical revenue model for vendors who can charge for the value-add they may bring to open source software. 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 to a product is the packaging done by the vendor to ease software deployment issues. This includes integrating their OpenStack powered product with configuration management tools such as Chef and Puppet. Often the vendor provides reference architectures and hardware compatibility lists that prescribe a particular way to run their product. Unless an It shop also contracts that vendor’s Professional Services organization to do the deployment, users are responsible for standing up and upgrading their own Cloud platform.
Management – While vendors may package management software with the OpenStack code as part of their product offering, the day-to-day responsibilities for managing the Cloud platform continue to reside primarily with the customer. In many cases, the vendor may assist by providing some recommended practices for how to manage and operate their product.
Support – Probably the biggest reason an IT shop would go with OpenStack powered product is the convenience of having a single source for support of their Cloud platform. Instead of only relying on the OpenStack community for software fixes, a customer can put the onus on their vendor of choice to be their advocate. In some cases, the vendor can submit code back upstream to the project; Typically, the vendor also takes responsibility for integration testing on behalf of the customer.
As more IT shops look to deploy OpenStack in production, many if not most will choose to go the OpenStack as a product route. My advice to customers has been to choose vendors who are providing 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. Thankfully, most vendors have chosen to stay with the core code in their products.
OpenStack Powered Services
Another way to consume OpenStack is as a service offering. The most obvious way to do so is to leverage an OpenStack powered Public Cloud such as the HP Public Cloud and the Rackspace Public Cloud. However, there are vendors who are also offering to use OpenStack as the platform for a Private Cloud as a service offering. Service offering that exemplify this include the Blue Box Hosted Private Cloud and the Rackspace Private Cloud (note that the Rackspace Private Cloud can be consumed either as a product or as a service). The value proposition here is that an It shop can gain the benefits of the Public Cloud but in dedicated single tenant Cloud environment. The argument is that like with the Public Cloud, users can focus on application development and business processes instead of managing and supporting the underlying Cloud platform and infrastructure.
When an IT shop, or more likely a business unit, chooses a managed Private Cloud service, they are able to offload deployment and support and much of the day-to-day management:
Deployment – In this model, deployment is primarily or solely the responsibility of the vendor. If the actual environment is being hosted on customer premises, the customer is generally responsible for facilities and hardware while the vendor is responsible for deploying the software. In a vendor hosted solution (which is more common), the vendor has sole responsibility soup-to-nuts for hardware and software deployment. The vendor also takes responsibility for all upgrades.
Management – The day-to-day management and operations of the Cloud platform is generally divided between user and vendor. Typically, the vendor manages the underlying infrastructure while customers manage the virtual resources created by the platform. Often the vendor and their customers will collaborate on tasks such as capacity planning.
Support – One of the selling points for vendors who offer OpenStack as a service 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. In some cases, a vendor could offer additional services such as supporting the applications that are running on the customer’s Cloud.
The advantage of consuming OpenStack as a service has already been outlined. The potential pitfalls is that this probably provides the least amount of options in terms of available OpenStack features. This is typically the case because for a vendor to be able to offer 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. There may also be the issue of data gravity if the Cloud platform and all the user data resides in a vendor’s data center; moving it out may not be a trivial process. Here, it is the responsibility of IT, working in collaboration with the Business, to determine if the advantage of not having to worry about the infrastructure so they can focus on the applications outweigh any perceived disadvantages.
Conclusion
As analysts, the media, and users try to discern the viability of OpenStack and to understand the different offerings available in the market, I hope this post can be a helpful guide. In particular, I would 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.
Finally, if you are interested in reading about the SiliconANGLE interview I reference in the beginning, you can access an article about the interview on their website. You can also watch the actual interview below:
Filed under: Cloud, Cloud Computing, IaaS, IT-as-a-Service, OpenStack, Private Cloud Tagged: Blue Box, Cloud, Cloud computing, IaaS, Mirantis, OpenStack, Piston Cloud, Private Cloud, Rackspace, Red Hat, SilionANGLE