Everybody is well aware of VMware’s flagship new product, VMware on AWS. It’s the jewel in VMware’s new crown, and a cornerstone of its recent VMworld. VMware, having given up its intention to be a fully fledged public cloud provider, ran to the arms of those it had attempted to usurp. However, VMware has another partnership that has not received as much of the spotlight. Its Cinderella product, hidden in the background—its DaaS, or to be more precise, its Horizon Cloud product—is now available on Azure.
This is effectively, but not entirely, VMware Horizon View (View is still well and truly tied to vSphere as a platform) running on Azure. This partnership means that Microsoft’s public cloud now has working DaaS offerings from both of the biggest providers of virtual desktop infrastructure, Citrix and VMware. This is a coup for Microsoft in its battle against Amazon WorkSpaces. Arguably, it is a bigger coup for VMware. XenDesktop on Azure was to be expected, given the close relationship Microsoft and Citrix have had over the last twenty-five years or so. The Microsoft/VMware relationship has not been so chummy; this would never have happened in the Balmer/Greshler years.
Why has Microsoft opened up Azure to Horizon View? Because it is just good business; it is a win on multiple levels. Microsoft gets Azure usage revenue from VMware for hosting the Horizon Cloud infrastructure, and it gets Microsoft license revenue for the rolled-out RDS farms that are providing VMware customers with their desktop experience. I say “RDS farms” because there is no Services Provider License Agreement (SPLA) for desktop VDAs. Finally, this revenue comes in without a dedicated Microsoft sales team to drive the process.
This is utility cloud at its best.
What exactly do you get for your money with Horizon Cloud on Azure?
First, this is not Horizon View. There are no connection brokers or composer instances; it is effectively VMware’s Desktone purchase. This means that it has a small number of limitations over a locally hosted Horizon View implementation. For example, there is no GPU support for Windows 2016. This isn’t a showstopper: you could always drop to 2012 R2 with Desktop Experience.
What it does is give enterprises an extra choice, for a DR-based desktop environment or remote site deployment. Using Cloud Pod federation and site affinity for your users, you could effectively have a local on-site View deployment automatically connect to Azure cloud on outage, while Azure AD Connect can give local Active Directory authentication for seamless access. Horizon Cloud deployed on Azure can participate in UEM to provide a unified desktop experience between pods, too. It supports the Blast Extreme protocol if you have HTML5 goodness. It also allows SMBs a more cost-effective method of deploying a VDI environment.
AWS has WorkSpaces, so if you are utilizing AWS for your compute needs, you can easily integrate WorkSpaces into a holistic full stack environment. Now, Azure has Horizon Cloud on Azure (yes, it already has Citrix Cloud on Azure, but that is not the point of this article).
With two valid desktop delivery methods, Microsoft can argue that it is more inclusive. By supporting both leading providers of virtual desktops and remote application, it has a potentially larger audience. Yes, AWS can argue that it can deliver native Horizon View to its customers via VMware on AWS, but I really would not like to see that bill.
It’s VMware that gains the most. Since it offloaded vCloud Air, it has been moving up from a single cloud story to a multicloud story. This makes sense. It is the first truly cross-cloud service from VMware Horizon Cloud that integrates with locally installed Horizon View deployment by becoming a site in a federated environment. However, and this is the important part, Horizon Cloud on Azure is not running on vSphere, but on Azure. This way, it is more akin to a PaaS environment.
This can be done because the desktop devices are deployed locally to whichever site is being utilized, and user identity and application stacks are hypervisor agnostic.
VMware is starting to deliver on its multicloud message. It still has a long way to travel. True multicloud should mean cross-cloud migration, and not just like-to-like, but like-to-unlike with real-time format conversion between hypervisors and seamless network identity changes. These are difficult challenges, especially if the migrated machine carries state information or traditional layer 2 spanning hacks. To make those kinds of transitions work, as well as trans-cloud level migrations, you need to control the interconnects—but that is another story for a later conversation.