What I’ve been finding over the past nine months since we virtualized our physical infrastructure and moved it to Rackspace’s private cloud solution, is that we’re not really getting a lot of the benefits that you think of from the cloud. Our private cloud is essentially a hosted virtual environment. Virtualization by itself brings some real benefits, and it’s clearly a step on the continuum towards cloud computing but it feels like a smaller step than I expected.
I’ve spent a lot of hours on support calls, monitoring, troubleshooting, and otherwise managing our private cloud environment. Other than the fact that our servers are virtual, those activities are indistinguishable from the types of activities we were engaged in with our traditional hosted physical infrastructure. This got me thinking about what a private cloud is and what my expectations should be.
There’s no shortage of variants and nuanced definitions of what a cloud is, but there are some familiar themes. The simplest definition: the dynamic provisioning of IT capabilities (hardware, software, or services) from third parties over a network , while simple, it isn’t really descriptive enough to evaluate our private cloud against. Instead I’ll use the, perhaps imperfect, five defining characteristics described within The NIST Definition of Cloud Computing.
Does our private cloud demonstrate these characteristics?
1. On-Demand self-service – With our private cloud we only have on-demand self-service in a very limited sense. We can allocate and de-allocate resources for a VM (CPU, Memory, and disk) via the portal. We can create additional VM’s and even clone existing ones via the portal, but network configuration, adding VM’s to the load balancer, joining the new VM with cluster software, and other application configurations will need to be done manually. In all cases we’re only playing with a finite set of resources.
2. Broad network access – We can access the private cloud portal via the web and mobile devices, so we pass in that regard.
3. Resource pooling – With our private cloud, resource pooling is extremely limited. Our resources are only pooled within our physical infrastructure, in one datacenter. VMs may move based on resource demand from one physical host to another dynamically using vMotion, but they don’t go very far and the pool isn’t very big.
4. Rapid elasticity – Our private cloud elasticity is limited to the resources available on our physical hosts, and while CPU and memory can be reallocated to existing VM’s fairly rapidly, we cannot quickly add additional VMs, nor would there necessarily be great advantage in doing so because they’d only be competing for the same underlying physical resources.
5. Measured service – A private cloud certainly isn’t pay as you go; we don’t get credit for un-used CPU and memory. We do get a measure of optimization of resource usage across physical hosts with vMotion. But it’s up to us to make sure resource utilization is optimized. We can under-allocate resources leaving infrastructure idle so that we have the capacity to scale up at peak, or we can over-allocate to make sure we’re maximizing our infrastructure but then have no wiggle room to burst. Sound familiar?
According to these defining characteristics it doesn’t sound like a private cloud is actually a cloud, at least ours doesn’t.
The things I’ve seen
Rather than split hairs over definitions of cloud terms, I’ll enumerate some of my experiences with our private cloud.
- We experienced performance issues that eventually boiled down to misconfigured duplexing on NIC’s.
- Acquiring more physical disk space took weeks.
- Increasing physical RAM took weeks.
- Spinning up new VM’s took days.
- The Rackspace best practice is to maintain a 1.5:1 ratio between virtual resources and hypervisors. That means that with 16 CPUs you can only create 24 CPUs worth of VMs even if the majority of these VMs are generally underutilized.
- While troubleshooting one particular outage, Rackspace recommended that we maintain a 1:1 ratio between virtual and physical, which further illustrates my point.
- During routine maintenance we’ve had to coordinate calls with Rackspace to remove and re-add nodes to the load balancer.
- We’ve had a series of network instability support issues.
- A recent disruption required upgrading firewall firmware.
- Windows updates are for us to manage.
Maybe some of this can be chalked up to our architecture not being particularly cloud ready, our inexperience with the environment, or Rackspace’s VMware version of a private cloud and their support could be lacking. Despite those possibilities I think there are real reasons not to call a private cloud a cloud at all.
Virtually the same
I don’t mean to suggest that virtualization doesn’t have advantages over our previous physical hardware incarnation, because it most definitely does. Nevertheless, considering the amount of configuration, troubleshooting, and management we have to do, coupled with the CPU, memory, and disk space constraints it still feels more akin to traditional hosting than it does to the cloud. It doesn’t give us the “ability to increase capacity or add capabilities on the fly without investing in new infrastructure, training new personnel, or licensing new software“, and for that reason it must not be a cloud in my eyes.