A couple months ago, I was having a discussion with a customer. The customer was currently using VMware for virtualization and wanted to know why they shouldn’t simply buy into the VMware cloud story and base his internal cloud project on the VMware tool set.
“Well,” I answered, “VMware makes a great hypervisor, vSphere. If you like it, there is no reason to move away from it. ServiceMesh is a VMware technology partner and the Agility Platform works great with VMware. But if you go down the path of buying VMware’s cloud tooling, you’ll have no contestability between clouds. Your workloads will be locked into VMware-based clouds, whether internal or external, and it will be difficult to move those workloads to non-VMware-based clouds. That will make you very dependent on VMware and you’ll have to put up with whatever they throw at you down the line.”
“But aren’t most clouds VMware-based today?” the customer asked.
“Yes, it’s true that many are,” I replied. “Certainly, we see that many or even most internal private clouds are based on VMware. In terms of external clouds, it’s a mixed bag. VMware does have a substantial service provider footprint, but there are some big exceptions. For instance, AWS EC2 is based on Xen and Rackspace is based on OpenStack, which can use either Xen or KVM. If you lock yourself into VMware, you’re going to have problems using those clouds. I realize that VMware is making noises about supporting non-VMware-based clouds and that there are other tools that promise to be able to migrate workloads from one cloud to another, but those solutions are all pretty painful if you have to use them.”
“The alternative,” I continued, “is to use vSphere as you are now, for the virtualization capability, but then to use ServiceMesh to provide a cloud-agnostic, hypervisor-agnostic management framework on top. That way, you’ll get portability and a consistent interface between clouds, whether they are based on VMware, Xen, KVM, or are internal or external. If for whatever reason you want to move away from VMware internally, or utilize a cloud service provider that doesn’t use VMware, you’ll be free to do it. And that will help you lower costs, improve service levels, and ensure you always have the capacity and performance you need. Even if you continue using vSphere internally, you’ll have options later, which will make your VMware contract negotiation a much more pleasant experience.”
In the end, the customer used vSphere to virtualize and ServiceMesh to provide the high-level multi-cloud management.
Well, Tuesday morning, VMware announced a major upgrade to its product suite, including vSphere 5. Also in the announcement was a new pricing and licensing scheme for vSphere 5. I watched the live video stream of the announcement. At the time, it seemed like VMware had simplified certain aspects of its pricing, which I thought would be a good thing for the market. But later on Tuesday, forums and blogs around the Internet started to erupt with fury over the changes. The tech press documented some of the reactions, with CRN saying that customers were “fuming” and ZDNet UK saying they were “wary” of the new scheme. Customers also vented in VMware’s own forums.
The short summary is that vSphere used to be licensed on a socket basis and is now moving to a combined socket + RAM model. vSphere customers who were previously running high memory configurations could be forced to pay for more licenses. For the purpose of this blog, the licensing changes are really irrelevant; if you’re interested in the detail, refer to the licensing document on the VMware site.
The key point is that VMware licensing changed. Some customers are unhappy about that. For others, it may not represent a big deal. But those unhappy customers that bought into an all-VMware story are now stuck. They either have to pay the price demanded by VMware, or they have to develop a painful migration strategy for workloads. Further, given that this change could impact cloud service provider cost structures, and therefore pricing or profitability, you can expect to see some service providers moving away from VMware to less costly alternatives (e.g. OpenStack).
Customers that deliberately created contestability from the get-go, using the ServiceMesh Agility Platform, for instance, are in a much better position, however. They have the ability to migrate away from VMware without too much problem and to utilize non-VMware-based public clouds where that makes sense.
If your cloud strategy doesn’t contemplate contestability and competition between clouds, you need to stop right now and factor this in. As this week’s move by VMware highlighted, if you’re locked into a given technology and the provider decides to change the rules, you’ll be stuck with the consequences. But if you have deliberately structured your cloud strategy to create contestability, you’ll be in far better shape.
Many IT professionals bemoaned the vendor lock-in they suffered with during the 1990s and 2000s. The move to cloud presents an opportunity to change the dynamics in favor of the enterprise. Don’t miss the opportunity. As the old saying goes, “Fool me once, shame on you. Fool me twice, shame on me.”
Latest Tweets