Way back in 2014, Gabe Knuth and I wrote a book called "Desktops as a Service". Five years later, people often ask, “How relevant is that DaaS book still today?” They also joke that, “now that 'cloud desktops' are a thing, you need to rewrite, update, and re-title your DaaS book!"
In this post, I’m going to look at how the DaaS market has evolved over the years, what’s the same, what’s different, and why the term “cloud desktop” is replacing “DaaS."
First, some definitions
Before we jump into the details, let’s make sure we’re all on the same page in terms of what DaaS is. For the purpose of this article, let’s define “DaaS” as the scenario where a customer pays for Windows desktops and/or Windows apps which are running someone else (e.g. “off premises”), with the user interface being delivered via some form of remoting protocol (VMware Blast, Citrix HDX, Microsoft RDP, etc.)
This is a board definition of DaaS, meaning any of the following is “DaaS” as far as I’m concerned:
- Windows Server / RDSH-based (“session per user”)
- Windows client-based / Win 7 / Win 10 (“VM per user”)
- Windows 10 multisession (like RDSH, but based on Win10 and not Windows Server). This has been announced by Microsoft but is not available yet as of this writing (Dec 2018).
Each of these three options could be used to deliver full published desktops or individual seamless published apps. Each of these also could be persistent or non-persistent.
The key, (again for the sake of this article only), is that “DaaS” is Windows remoting technology where the Windows instances are running off premises.
What was DaaS in 2014?
When we wrote that DaaS book five years ago, most DaaS providers owned and managed their own hardware which was either in their own datacenter or in some kind of colocation facility.
Typically the customer entered into some kind of long-term contract with the DaaS provider, something along the lines of “$50 per user, per month” (or whatever the price worked out to be.) Once the deal was signed, the provider would physically procure the hardware needed to run the environment, then they’d install the VMware or Citrix or VDI/RDSH software to run it, they’d work with the customer to migrate the users and data, and then they'd be off and running.
The contracts were typically long-term since the DaaS provider had to go out and physically procure (and pay for up front) all the hardware they needed for each customer environment with the idea that they’d recoup their initial costs over the life of the contract.
In many ways, DaaS providers of 2014 were essentially MSPs (managed service providers) where they were just building and providing custom VDI/RDSH environments that they hosted.
From a customer standpoint, the DaaS of 2014 didn’t offer a lot of flexibility. Want to get out of your contract early? You’d need to pony up for some hefty termination fees since your provider has to cover the costs of the hardware they bought for you. Customers also didn’t have a lot of flexibility to scale or change the DaaS environment once it was built. If you decided half-way through your contract that you want GPUs in your servers, but the physical servers your provider bought don’t have the room for them, you’re out of luck. No GPUs for you! If you decide that your initial specs per user are too big, that’s too bad. You can’d cut the amount of memory per user since your DaaS provider already paid for it and has to recoup the costs.
Clearly, the DaaS of 2014 was not the uber-flexible cloud computing environment of today.
Really what you were paying for back then was for someone else to build and run your VDI/RDSH infrastructure. It was not a cloud offering in the truest sense of the word, though it had many cloud-like characteristics, such as the fact that customers didn’t have to think about or worry about the hardware, the infrastructure layer, etc.
The other unfortunate reality of DaaS in 2014 was that since the DaaS environment, once built, would be used for several years, it was crucial that customers did proper sizing and testing, just like a traditional on-prem VDI environment. (Again, this was necessary because once the environment was built, it was difficult to change, so it’s important to get it right the first time and to incorporate thoughts and planning for future growth.) This meant that DaaS projects of the ERA were complex and long, as the teams thought about and performed server sizing tests, load testing, network testing, etc. Back then, moving to DaaS wasn’t really any faster than moving to traditional on-prem VDI.
What is DaaS in 2019?
What’s changed in the past five years? Simple: Now we have the cloud. :)
Actually that’s not even a joke. Over the past five years, we’ve seen the phrase “X-as-a-Service” evolve into by “cloud X.” For example, Microsoft describes Windows 10 management-as-a-service as "Windows 10 cloud management” now. “SaaS” is becoming “cloud software.” So I guess it makes sense that “Desktops-as-a-Service” has evolved into “cloud desktops.”
Most people leveraging cloud desktops in 2019 are doing so on existing public clouds, like Azure and AWS. This allows customers to leverage the true cloud “promise” of scaling up, scaling down, changing hardware specs, and not paying for VMs when they’re powered down. The raw infrastructure services that cloud platforms offer are augmented by VDI/RDSH platforms from vendors like VMware and Citrix. This means that customers can use the same delivery and management infrastructure for their
DaaS cloud desktops as they do for their on-prem desktops.
For example, one of VMware’s offerings in this space is Horizon Cloud on Azure. Desktop VMs (RDSH or VDI) run on Azure, and customers pay Microsoft directly for that VM consumption. Horizon is then used for the protocol, management, broker services, control plane, etc., which customers pay VMware for. This is similar to a traditional VDI/RDSH environment where you pay for the Horizon licenses separately from your delivery hardware, but in this case your hardware is monthly VM rentals from Azure instead of a rack full of servers that were delivered to your loading dock.
The value is that you get the same Horizon experience (Blast protocol, management tools, etc.) but you only actually pay for the consumption of the VMs as you use them. In other words, if you want to change a particular user's VM (bigger or smaller) during your term, you can just login to your Azure control panel and do that. (You don’t need to talk to VMware.) If you want to power down some VMs at night to save money, you can do that. (You don’t need to talk to VMware.) As Azure pricing drops (or as Azure VMs get increased capabilities for the same price), you get those benefits too, as soon as they’re available, even “mid-contract.” It truly is the power (and promise) of the cloud, delivered in desktop form.
There’s a similar story on the AWS side, where you can use “VMware Cloud on AWS” to essentially “extend” your on-prem VMware environment into AWS locations, which appear in your VMware management consoles just like any vSphere host. From there you can install and build whatever you want, including Horizon 7, which you can then hook into your existing Horizon environment (or keep standalone).
Even though the infrastructure is a bit different on AWS than Azure, many of the benefits are the same (when compared to old-school 2014 DaaS). With VMware Cloud on AWS, the customer is in control of the vSphere node they’re renting. They can slice-and-dice it however they want, change VM sizes, etc., while still being able to add or remove capacity at any time and getting the current price as costs and offerings come down.
The bottom line
Cloud desktops in 2019 are the logical evolution of DaaS from 2014. Most of the benefits (and challenges) of designing DaaS in 2014 still apply to cloud desktops in 2019. But 2019 cloud desktops are clearly better for most use cases. Customers have the benefits of paying someone else to run the infrastructure that powers their VDI/RDSH environment while having the flexibility to change and evolve over time.
This flexibility makes things like onboarding much easier. In 2014, you had to spend months figuring out the “best” desktop VM size for each user class. In 2019, meh, just give every user 2 vCPUs and 4GB RAM. If anyone complains, bump them up. Done! If a user suddenly needs a GPU, switch them to a VM with a GPU. Done!
I’m not suggesting that VDI/RDSH are better than all desktops, and I’m not saying that cloud-hosted desktops are better than on-prem. Instead I’m saying that for the subset of your Windows desktops where VDI/RDSH makes sense, and for the subset of them where it makes sense to have them run off-prem, the cloud desktop options of 2019 are typically more flexible than the more static DaaS environments of 2014. (Though certainly the “traditional” DaaS providers will still have a use moving forward for more customized environments that Azure and AWS don’t offer.)
The theme of EUC in 2019 is “flexibility”, and cloud-based desktops can play a part of that for many customers.