…and there are probably another 30 restaurant analogies you could use to describe interactions between app owners and the operations or capacity teams. "I'm sending this back. I requested 16 vCPUs, not 4!"
When talking with customers about their onboarding strategies, there are typically two types of scenarios for bringing in new workloads to the datacenter for which you have to be prepared. The workloads you know about (and are lucky enough to plan for)...and the requests that pop up last minute. In a world where both exist, it's a challenge to be accommodating for all of your guests.
I was recently talking with an organization about their upcoming VDI project and their plans to support around 1000 users. They will be deploying 1000 workstations over the next 6 months and are asking themselves if they have enough resources. Because they will be rolling out the project in waves, they have some lead-time when it comes to ensuring there is enough hardware to support the project.
The biggest problem this customer faced was knowing how to accommodate the current workload utilization while also supporting the next wave of VDI instances that had yet to be deployed. If the current workload was starting to demand more resources, then their plan for adding another 150 instances could not be accomplished with their current capacity. And of course, they only realized this bottleneck once they had started to deploy the next batch - resulting in a last minute purchase of hardware to squeeze it all in.
Ideally, we'd like to know when the current workload has grown to the point where we can't support the next batch of workloads. Without hurting our brains everyday crunching numbers, we need to know when and how much capacity is needed in real-time to support current and future demand.
Perhaps the best analogy would be something like an advanced reservation system. Let's use our restaurant analogy again.
Imagine you're taking dinner reservations for the upcoming weekend - jotting down reservations, your tables are filling up quickly. Inevitably, Saturday comes along - there are some stragglers still hanging around from a late lunch and walk-ins that were hoping to grab a table without making a reservation. How do you accommodate all the demand?
To make room for more guests, it might be convenient to start moving the tables around for a more efficient configuration, grab smaller tables for smaller parties and larger tables for larger parties, or better yet, be able to provision new tables, or more floor space before you fill up and have to start turning customers away! Naturally, in a restaurant you don't have the same agility you are afforded in virtual environments - but we're talking about virtualization anyway so this can absolutely be applied to our demand problem!
So now imagine you've got an intelligent workload reservation system - one that’s tied directly into your real-time management system. You figuratively "call" into your data center and setup a reservation for 1000 VDI workstations to be deployed over the next 6 months.
You have effectively deployed 1000 “placeholder VMs” that are now living across your infrastructure. From here, you start to bring those workloads live. As the first 50 workstations get built and utilized, your reservation system is continuously calculating whether you can still support the rest of your 950 placeholder workstations – and making real-time resource management decisions to maximize your headroom capacity.
Figure 2 highlights the next two deployments that can be supported based on the available capacity. Once you hit the point where your current workload demand and reserved workload demand no longer have enough capacity to support them, your reservation system places those VMs on the “waiting list” (Figure 3) and then lets you know exactly how much hardware to provision to support them (Figure 4).
So instead of finding out you've run out of resources when you try to deploy the next batch of workloads, let your reservation system prepare you much earlier.
(Just remember: A gratuity of 18% is included on reservations of 50 VMs or more.)
This article is about efficiency. Read more like it at the Performance, Efficiency, Agility series.