“Workloads” and the private cloud
We’ve written several articles on this blog differentiating between virtualized-only and private cloud infrastructures, so I won’t detail those differences again, but in this post, I wanted to address the topic of “workloads,” how it’s likely that not all of the workloads in your environment will be a fit for your private infrastructure as a service (IaaS) offering, and how OK it is if not all do. For this post, a “workload” equates to some software that runs on an operating system.
Consider a public IaaS provider such as Microsoft Windows Azure Virtual Machines. While always subject to change, as of the writing of this post, there are five “sizes” of virtual machine (VM) that you can utilize. These VMs vary in the amount of processors, memory, disks, and network bandwidth that they provide, but the amount of each resource for each size is standardized. The service level agreement (SLA) metrics for all of them is standardized.
Different public providers of IaaS might offer different VM sizes, or have different SLA metrics, but all public providers have one thing in common --they’ve standardized what they offer, and made their consumers aware of what standardized options they provide. This standardization is one key factor in how they’re able to provide the service they offer at scale, and (generally) offer it at relatively low cost to their consumers.
This allows the consumers of the service to make a few decisions when determining which applications they may want to run on that public IaaS offering:
- Does the service offer VM sizes that meet the requirements of my applications?
- Does the service offer the SLA metrics that my application requires and my users expect?
Of course, there are many other questions you likely ask when evaluating the viability of moving a specific workload to a particular public IaaS service, but if the answer to either of the above questions is “No,” then you simply don’t move your application to the public IaaS provider. You don’t call up that provider and say “Hey, my application has some unique requirements that your service doesn’t support, can you create some custom infrastructure for me to run it on?”
If you did, they’d of course, tell you “No, but there are a variety of custom hosting providers who can do that for you.” Indeed -- many custom hosting providers would happily create a custom physical or virtual hosting infrastructure for you to run your applications on. Generally, they would do so for you at a relatively higher cost than an IaaS provider, because the costs to host custom infrastructure are generally higher than the costs to host standardized infrastructure. But you already know that, because you probably have a lot of custom infrastructure in your own organization today, and are well aware of what it costs you to operate it.
So, if you’ve made the decision to provide a private IaaS offering within your organization, then be sure to accept the fact that it likely won’t support every application in your organization. Whether your IaaS infrastructure supports 20% or 80% of your applications will require you to find the right balance in your organization between cost-effectively delivering your standardized IaaS and the number of applications it can support.
For the applications that can’t run on your standardized IaaS offering, that’s OK, just keep running them the way you do today…whether they continue running on custom physical or virtual machines. You’ll likely find that the cost of hosting those applications is higher than the cost of hosting those that can run on your standardized IaaS offering, and that can help inform future application purchasing decisions.
If you have a standardized, private IaaS infrastructure, then we’d be interested in knowing what percentage of the applications in your environment are able to run on it. Please let us know in the comments section, and let us know if you’ve standardized your VM sizes (and if so, how many sizes you offer).
Jim Dial
SCD iX Solutions Group