VMware Cloud on AWS…what?
OK, first off, I’ll admit I totally called it wrong: when I read that a VMware-AWS partnership was in the works, the only thing I could think of was a new product that could replicate some AWS functionality, but with VMware at its core. To some extent this already exists in OpenStack, but AWS could have worked with VMWare to make a product that had the same look and feel as public cloud AWS but ran on private infrastructure, with full VMware support for the actual plumbing. AWS could have finally had an answer to Azure Stack, which addresses customers’ desire to use the Azure tools with their own infrastructure (and is, in my opinion, a serious competitive advantage to Azure).
What emerged was…something else entirely. AWS is apparently facilitating VMware running in AWS, which almost the exact opposite of my prediction — rather than AWS on VMware, it’s VMware on AWS. In my defense, I never thought VMware would go for this, which leads me to one question:
VMware, what are you thinking?
VMware seems to be missing the point entirely; in my experience working with customers on VMware, there are two main reasons that customers run workloads on VMware vs AWS:
- They want to keep the workload on their own hardware. This could be because it’s cheaper (which, to be perfectly honest, it often is for a static workload), or more commonly because customers want to be in control of their own data and uptime as much as possible. AWS has (smartly) been attacking the second reason from day 1, encouraging business to focus on their core competencies and to delegate the care and feeding of infrastructure to AWS.
- They don’t want to deal with migrating their workloads to AWS. Complex and unknown interdependencies, binaries for which the source was lost a long time ago, specialized application requirements like shared CIFS storage or multicast, appliances that don’t have a drop-in AWS equivalent, and a host of other roadblocks are still preventing the majority of companies from migrating VMware-based applications to AWS.
From AWS’s perspective, I can see the appeal of this new offering: enabling customers to easily port their workloads from VMware on-prem to VMware on AWS gets those workloads one step closer to being entirely on AWS. Financially and strategically, it’s a huge win for AWS; AWS gets paid when the customer migrates the workload to VMware on AWS, then when the customer balks at the cost (they are, after all, getting the worst of both worlds when it comes to pricing), AWS can start helping the customer migrate those workloads out of VMware and into plain old Xen-based AWS, and the customer marvels at just how much they’re now saving compared to the VMware offering.
So…what does VMware get out of it? As far as I can tell, the only thing VMware gets is a temporary stay of execution. Let’s take the case of your typical mid-sized customer with an overworked IT department. The CIO has just read an article about how CIOs who don’t migrate to AWS will be out of a job in the next few years, and has dictated that “we need to move to AWS”. The overworked IT department now has an easy way to technically fulfill that directive with minimal time investment or disruption to legacy processes. It all sounds great until they review their spend that year, at which point the customer has a choice: assuming that continuing the current course is unsustainable, do we buy new servers and hardware, then migrate the workloads back from AWS, or do we look to refactor to native AWS? The key difference from before is that the customer can now migrate one piece at a time, in the same network, or they can build cloud-native replacements with much less friction. I wouldn’t be surprised to see lots of improvements on AWS’s Application Discovery Service and VM Import / Export to facilitate the migration pattern of VMware on-prem to VMware on AWS to native AWS. Kinda brilliant on AWS’s part, but seriously…VMware, what were you thinking?
