I recently read Dell’s post about “10 ways to allocate workloads in the cloud”. Here at VMTurbo, we have daily conversations with cloud providers as well as their customers.
Many IT organizations today not only want to take advantage of public cloud offering out there, but also have to “compete” with the public cloud. AWS continuously reduces prices and so does Azure. Cloud providers have understood for a while that economics are a key driver in their customers’ move to the cloud.
Our customers understand today that running VMTurbo in their private cloud significantly increases efficiency, so you can run more workload on less hardware with better performance. However, as Mr. Horowitz indicated there are still many valid reasons to take advantage of the public cloud. I’ll refer to several points in the article:
Bursting provides flexibility for cloud workloads
True. You don’t need to build a stadium fit for the Super Bowl for a high school football game. If you have a need for that size of stadium once a year, it makes more sense to rent it. While the Idea of bursting to the cloud is a simple idea that makes perfect sense, the practice is much harder.
What workload do you chose to burst?
When do you burst?
Where do you place the new workload?
VMTurbo will recognize when you are out of capacity. Specifically, at what point can you no longer run your existing workload without risking performance issues.
Further, VMTurbo will generate actions that will indicate what workload to burst to the cloud. Those of course, can be automated.
When you need more capacity:
What workload to burst and where:
Split application components
Good point. Unfortunately, this makes our lives much more difficult. The example in the article is keep storage (specifically SAN) in house. The answer to the question of what workload to move to the cloud and what to keep in house is – “It depends”. It actually depends on many things.
One obvious example is the chattiness between the applications components. If you move your Database Server to the cloud and keep its Storage in house, you might trade off the compute of your datacenter with the network latency of accessing the cloud, risking paying a huge price (both literally for the cloud provider and performance wise) on the network utilization between your data center and the cloud. VMTurbo’s Economic scheduling Engine would price cross cloud network traffic higher than traffic inside the data center. As well as between switches, on the same switch and on the same host with our Network Control Module. Helping you make the right decision of what VMs should move the cloud.
Prioritize customer-facing applications
Once again – how do you do that in practice? Do you simply move these applications to the cloud because you can afford to spend more on them?
Within VMTurbo, different applications can get different budgets. Hence, customer facing applications (or any critical workload what so ever) can get the resources they need when they need them. Even if that means trading off the performance of one application with the performance of another.
It is time to evolve. Planes run on autopilot. Google is building a self-driving car. Waze is telling us what routes to take to avoid traffic. Why should our data center be any different?
VMTurbo developed a demand-driven platform that is a control system for the virtualized data center: Understand what a desired state of your data center is, what needs to be done in order to get you there, and take those actions for you.
VMTurbo will control your hybrid cloud environment. When to burst, what to burst, where to burst.
Another important note that IMO is missing from the article: When do I bring my workload back to the data center? VMTurbo will also assist in understanding when workload demand comes down, and it is time to bring the workload back home, where it can run safely, and take advantage of the resources available in house.
Check out more post on virtualization and cloud best practices and emerging trends here.
And start for Free with VMTurbo Operations Manager here.