Charles Babcock, an editor-at-large for the well-known publication InformationWeek, recently wrote an article explaining why you shouldn’t “Count VMware Out In Rough Seas.”
Charles’ point, which I’m oversimplifying here (you should read his whole article) is that even though public cloud is growing there will be many workloads that are perfectly suited to running in-house on existing virtualized infrastructure.
Apparently the market agrees, also, rewarding VMware’s 11% revenue increase for their recently reported quarter with a jump in their share price. At this point in the market adoption of public cloud, because of the new use cases that it opens up, workload placement is not a zero-sum game. There is room for growth in one, without requiring a contraction in the other.
Managing virtual resources, public or private, has to be done in the context of your larger landscape of hybrid or federated clouds. Many companies force operations teams to follow a different process or look at a different console to onboard, deploy, or manage applications in their public and private clouds. As application complexity increases and choice of public/private cloud grows, managing critical workloads from two separate consoles is a non-sustainable practice that will erode the benefits of an automated, orchestrated cloud.
1) Manage any edition of VMware (Standard, Enterprise, and Enterprise Plus). Enterprise, and Enterprise+ customers who use VMware DRS (Distributed Resource Scheduler) and DVS (Distributed Virtual Switch) will be happy to see us take advantage of those services right out of the box, with no extra configuration required.
2) Fine grained control of VM placement. Thanks to our improved support for VMware, the CliQr CloudBlade now allows users to manage VM placement with finer granularity. Depending on their role and permissions, users can deploy VMs to specific clusters, resource pools, data stores, and network port groups.
3) Support for linked-clone. When deploying applications, we see quite a bit of time (depends on the cloud, of course) spent just waiting for the required worker VM to be provisioned. This may be of little consequence when you’re running a 5000 node-hour job. However, if you’re dynamically scaling up a Web Application in response to heavy transaction volume, the wait time may be unacceptable. CliQr can now take advantage of VMware’s “linked-clone” capability for virtual disks, which allows virtual machine provisioning time to be reduced significantly.
One of our more interesting capabilities is our automated benchmarking (which we write about here, and here). Without our cloud-portable application orchestration engine, it would simply not be possible to benchmark apps in such an easy and automated manner.
We’ve always allowed benchmarking performance across all clouds, but as part of our new release, organizations that have calculated their fully burdened cost of compute on a per VM instance type basis can now plug that information into CliQr. This allows them to benchmark their workloads against both private and public clouds to automatically determine the price, performance and price-performance leader among the various instances sizes they have available in their catalog. This transparent benchmarking process provides you the ability to validate (or, not) your decision to keep workloads in your private cloud. Regardless of what you find out, your bottom line will benefit.
Charles nails it when he says states, “The cloud will grow and many workloads will migrate there, but many will remain inside the data center.”
Another important question to answer is “which ones should remain and which ones should go—and to which cloud?!”