How does the world consume private clouds?
- August 24, 2016
In my previous blog, why the world needs private clouds, we looked at ten reasons for considering a private cloud. The next logical question is how a company should go about building a private cloud.
In my view, there are four consumption models for OpenStack. Let’s look at each approach and then compare.
In this approach, the user has to grab upstream OpenStack bits, package the right projects, fix bugs or add features as needed, then deploy and manage the OpenStack lifecycle. The user also has to “self-support” their internal IT/OPS team.
This approach requires recruiting and retaining a very strong engineering team that is adept at python, OpenStack, and working with the upstream open-source community. Because of this, I don’t think more than a handful companies can or would want to pursue this approach. In fact, we know of several users who started out on this path, but had to switch to a different approach because they lost engineers to other companies. Net-net, the DIY approach is not for the faint of heart.
In this approach, no upstream engineering is required. Instead, the company is responsible for deploying a known good distribution from a vendor and managing its lifecycle.
Even though this is simpler than DIY, very few companies can manage a complex, distributed and fast moving piece of software such as OpenStack -- a point made by Boris Renski in his recent blog Infrastructure Software is Dead. Therefore, most customers end up utilizing extensive professional services from the distribution vendor.
In this approach, the user is responsible for the hardware, the datacenter, and tenant management; but OpenStack is fully managed by the vendor. Ultimately this may be the most appealing model for a large set of customers.
Which approach you choose should also depend on factors such as the importance of the initiative, relative cost, and so on, such as:
So as a user of an OpenStack private cloud you have four ways to consume the software.
The cost and convenience of each approach vary as per this simplified chart and need to be traded-off with respect to your strategy and requirements.
OK, so we know why you need a private cloud, and how you can consume one. But there's still one burning question: who needs it?
In my view, there are four consumption models for OpenStack. Let’s look at each approach and then compare.
Approach #1: DIY
For the most sophisticated users, where OpenStack is super-strategic to the business, a do-it-yourself approach is appealing. Walmart, PayPal, and so on are examples of this approach.In this approach, the user has to grab upstream OpenStack bits, package the right projects, fix bugs or add features as needed, then deploy and manage the OpenStack lifecycle. The user also has to “self-support” their internal IT/OPS team.
This approach requires recruiting and retaining a very strong engineering team that is adept at python, OpenStack, and working with the upstream open-source community. Because of this, I don’t think more than a handful companies can or would want to pursue this approach. In fact, we know of several users who started out on this path, but had to switch to a different approach because they lost engineers to other companies. Net-net, the DIY approach is not for the faint of heart.
Approach #2: Distro
For large sophisticated users that plan to customize a cloud for their own use and have the skills to manage it, an OpenStack distribution is an attractive approach.In this approach, no upstream engineering is required. Instead, the company is responsible for deploying a known good distribution from a vendor and managing its lifecycle.
Even though this is simpler than DIY, very few companies can manage a complex, distributed and fast moving piece of software such as OpenStack -- a point made by Boris Renski in his recent blog Infrastructure Software is Dead. Therefore, most customers end up utilizing extensive professional services from the distribution vendor.
Approach #3: Managed Services
For customers who don’t want to deal with the hassle of managing OpenStack, but want control over the hardware and datacenter (on-prem or colo), managed services may be a great option.In this approach, the user is responsible for the hardware, the datacenter, and tenant management; but OpenStack is fully managed by the vendor. Ultimately this may be the most appealing model for a large set of customers.
Approach #4: Hosted Private Cloud
This approach is a variation of the Managed Services approach. In this option, not only is the cloud managed, it is also hosted by the vendor. In other words, the user does not even have to purchase any hardware or manage the datacenter. In terms of look and feel, this approach is analogous to purchasing a public cloud, but without the "noisy neighbor" problems that sometimes arise.Which approach is best?
Each approach has its pros and cons, of course. For example, each approach has different requirements in terms of engineering resources:| DIY | Distro | Managed Service | Hosted Private Cloud | |
| Need upstream OpenStack engineering team | Yes | No | No | No |
| Need OpenStack IT architecture team | Yes | Yes | No | No |
| Need OpenStack IT/ OPS team | Yes | Yes | No | No |
| Need hardware & datacenter team | Yes | Yes | Yes | No |
| DIY | Distro | Managed Service | Hosted Private Cloud | |
| How important is the private cloud to the company? | The business depends on private cloud | The cloud is extremely strategic to the business | The cloud is very strategic to the business | The cloud is somewhat strategic to the business |
| Ability to impact the community | Very direct | Somewhat direct | Indirect | Minimal |
| Cost (relative) | Depends on skills & scale | Low | Medium | High |
| Ability to own OpenStack operations | Yes | Yes | Depends if the vendor offers a transfer option | No |
The cost and convenience of each approach vary as per this simplified chart and need to be traded-off with respect to your strategy and requirements.
OK, so we know why you need a private cloud, and how you can consume one. But there's still one burning question: who needs it?
