Resource Pools versus Virtual Machine Pools

#virtualization #cloud On the importance of recognizing that what we have today is not a pool of resources, but a pool of virtual  machines.

This post is following up on last week's post, "The Inevitability of Idle Resources", in which I mentioned the importance of ensuring not only that resources are available when you need to provision a new service to scale but that the resources available match the needs of the service.

So let's continue that by assuming you can find some idle (available) resources to use when you need them. Two questions need to be asked before you hit the easy button:

1. Are there enough resources to support this service? After all, different services require different resource profiles. Some need more storage, others more RAM, others many CPUs.
2. What's the possible impact of provisioning this service on this resource? In other words, what else is currently using these resources? How many other virtual instances are on the same hardware and what are their resource consumption profiles? What will happen if I provision two network-hungry services on the same hardware (especially in cloud environments that share a physical network interface)?

Marketing makes it sound so simple. Just grab some resources and provision away. But the reality that IT professionals know is that different services require different resources and contention for those resources is a primary cause of poor application performance and network congestion. Which is one of the arguments for specialized resources, but let's not muddy the waters with that discussion today.

What happens if you don't have the appropriate resources? Well, it's going to throw your math off and that will throw your capacity planning off.

Let's say you know you need X RAM and Y CPU and Z network in order to support 1000 CPS (connections per second) for your load balancing service. Your capacity planning exercises, then, are based on this assumption. If you set up your systems to auto-scale based on that assumption and then, for some reason, you scale your load balancing service by provisioning it with a resource profile capable of only supporting 600 or 700 CPS without significant degradation of performance, well.. you can imagine what happens. Users become frustrated, your phone starts ringing and there goes your quarterly bonus along with big chunks of your hair because the system won't kick off another instance of the service until you near that 1000 CPS threshold. (This is a good time to point out that a more adaptable load balancing algorithm might be helpful though not a panacea). 

This is true for just about everything you want to run. Applications, network services, application services. It doesn't matter. Each one is going to have its unique resource requirement profile and if you start ignoring that your systems are going to begin to acting wonky.

Until we reach the real data center nirvana, where hardware resources really are a single pool from which the appropriate combination of memory, CPU and network capacity can be provisioned for a specific application or service, we have virtualization and pools of pre-determined resource sets. We don't  have a pool of resources, we have a pool of virtual machines. While advances have been made in terms of growing and shrinking virtual machine resource allocations, it's far from nirvana and it's far from perfect (and rarely on-demand).

That means when you're chopping up resources into virtual machines you're still going to have to indulge in sizing exercises and capacity planning. At least until we have true pools of resources and not pools of virtual machines.