DaaS with On-Premises Desktops


One of the trends in virtual desktops is Desktop as a Service (DaaS). The premise here is that a cloud provider can run a massive multi-tenant VDI environment well, better than most medium organizations can run their VDI on-premises. The medium or smaller organizations just rent the desktops they need. The assumption here is that desktops are a commodity and any desktop anywhere is just fine. The problem comes with those DaaS desktops accessing data—in particular, desktops at a cloud provider accessing data inside the client’s network. The desktop may run just fine, but if every application accessing corporate data slows to a crawl, there won’t be many happy users.

What Do Your Users Do?

What applications do your users actually use? This is a fundamental question in any VDI discovery project. Another is “What data do your users access?” or, more particularly, “Where is that data?” Mail could be on-premises Exchange, or it could be Office 365 or Gmail. Office documents could be on-premises file servers, or SharePoint Online, or Google Docs. Your line-of-business application might be Salesforce, or it might be on-premises SAP. If you are looking at VDI or DaaS, then I doubt that everything is cloud based, because cloud apps shouldn’t need VDI. More likely, you still have some holdout applications that date from a past age of IT. These applications are why you need Windows desktops and are looking at where to run them. These are the very applications that assume data is close by, rapidly accessible.

Latency: “I can’t change the laws of physics”

One of the fundamental constants in physics is the speed of light. Nothing can go faster, including data. This means that the minimum possible amount of time it takes to retrieve a piece of data depends on how far away the data resides. “Latency” is what we call the amount of time that elapses from the moment data is requested until that data starts to arrive. Within a corporate office, data is usually within a thousand feet. But the nearest cloud data center might be 50 miles away: 250 times as far and up to 250 times as much latency. Data latency, and therefore application latency, might be hundreds of times higher after moving to the cloud.

Some applications tolerate latency very well. In particular, many web applications are designed to accommodate latency. However, many legacy applications do not like latency. A lot of applications expect data to be available in a few milliseconds. A nearby cloud might add tens of milliseconds in latency. If you are farther away from the cloud data center, it could be a lot more.

Split DaaS

How do we get low-latency data access without managing our own VDI infrastructure? One way is to separate the two. Use a DaaS broker to access desktops inside your data center. Let the DaaS provider manage the VDI infrastructure. You have only the desktops to manage on-premises. Now, your VDI is split into two parts:

  1. A web service that authenticates users and offers them their desktops
  2. Desktops inside your data center where the user’s applications run

This isn’t a split that conventional VDI or DaaS products expect, but it makes a lot of sense.

Fast and Secure Data

Keeping the desktops inside your data center gives you low-latency access to your data. Applications respond as fast as they always did, and maybe even faster, since they are a little closer to the data. This translates to fewer user complaints about performance when they move to DaaS. As an added bonus, your data doesn’t need to traverse a WAN or internet connection to get to the desktops. This simplifies your compliance and security processes, keeping the same processes as those for on-premises desktops.


The point of separating the broker and the desktops is to enable flexibility with regard to where the desktops run. You might have some desktops in an on-premises data center and some in a colocated data center. Ideally, the DaaS broker should also support other DaaS platforms like AWS WorkSpaces, which doesn’t do much brokering. Then, a single portal can broker connections for permanent desktops and more transient workloads as well.

Splitting DaaS into a VDI infrastructure layer and a desktop execution layer has definite value. The complex VDI infrastructure is managed by the DaaS provider. The cost of running infrastructure is shared by all the tenants. Each tenant’s data remains in its own data center and close to its data for best application performance. DaaS becomes simply a way to access desktops, rather than a place where desktops reside.

As far as I am aware, only one vendor offers this solution. Workspot is a Workspace as a Service vendor that has expanded into VDI Broker as a Service. I have used its product for access to desktops on Nutanix Acropolis Hypervisor. Recently, Workspot and HPE have been showing off integration into vSphere and the HPE HC 380.

Share this Article:

The following two tabs change content below.
Alastair Cooke
Alastair Cooke is an independent analyst and consultant working with virtualization and datacenter technologies. Alastair spent eight years delivering training for HP and VMware as well as providing implementation services for their technologies. Alastair is able to create a storied communication that helps partners and customers understand complex technologies. Alastair is known in the VMware community for contributions to the vBrownBag podcast and for the AutoLab, which automates the deployment of a nested vSphere training lab.
Alastair Cooke

Latest posts by Alastair Cooke (see all)

Related Posts:

Leave a Reply

Be the First to Comment!