How Would Split DaaS Work?

In a previous article, I suggested that splitting DaaS into separate parts for the broker and the desktops would address some of the challenges of DaaS. Today, I’d like to take a closer look at how this might work.

Split DaaS

The first objective is to have desktops close to the data, in your data center. The second objective is to have someone else manage the VDI access infrastructure. Use a DaaS broker to access desktops inside your data center. Let the DaaS provider manage the VDI infrastructure, and you have only the desktops to manage on-premises. Now your VDI is split into two parts. There is a web service that authenticates users and offers them their desktops. There are 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.

On-Premises

You will still need to deploy a VDI appliance into your data center. This appliance is downloaded from the DaaS provider and deployed into your data center. It provides the bridge between your on-premises infrastructure and the DaaS provider. The appliance will manage the linking of your Active Directory (AD) to the web service, thus keeping your authentication on-premises. User access should be controlled by group membership within your AD. The appliance will also drive the provisioning of new desktops by linking to your VM management platform—VMware vCenter, Microsoft SC-VMM, Nutanix Acropolis, OpenStack, or whatever else you have. Naturally, the DaaS vendor would need to support your hypervisor management platform. Desktops should be provisioned on demand when new users connect to the portal. Even better, desktops could be provisioned when users are added to the AD group, so the desktop will be ready when they first log in. I would like to see the appliance also do a network gateway, like the old Citrix Secure Gateway or the AirWatch secure browser proxy. This would remove the need for a separate VPN. It could be more secure than a VPN, since only VDI traffic would pass: no need for devices on the internet having a route into the center of your network. Another nice feature here would be an HTML5 client service from the appliance, removing the need for a VDI client. The appliance needs to be managed though the web service, and it should be very firewall friendly so it can be deployed on a DMZ. I expect that the desktops would be full clones and persistent. Then the desktop could be maintained using the same tools as physical desktops, since we never seem to eliminate all of those with VDI.

Of course, there is no reason why these resources need to be in your own data center. You might have your desktops running in a colocation center. You might deploy the whole lot on an IaaS platform like Azure or AWS. Ideally, you would be able to aggregate desktops from multiple sources into a single user portal. The key thing is that the desktop VMs need to be close to the data that they access.

In the Cloud

The cloud service is the multi-tenant part, using the same infrastructure for multiple clients. There will be a couple of tenant portals, one for administration and another for user access. The administration portal is where the on-premises appliance is linked to the tenant portal. Desktop provisioning policies are defined, and AD groups are associated with pools of desktops. The admin portal should also have usage reporting and should be able to export that data into internal accounting systems. In addition, it should allow branding of each client’s user portal. This user portal is where users will log on to access their desktops. The user portal part could be fairly simple, just offering a desktop, or it could be much more sophisticated, providing a full user workspace where desktops are just one type of resource. The user’s session with their desktop should not pass through the portal. The portal is just a launch mechanism. The desktop session should go direct to the desktop in your data center, or it should pass through the connector appliance in your data center. Either way, the user portal is just for authenticating and launching the session.

Split DaaS

One of the top reasons for DaaS is that VDI brokers are complex. Having a group of tenants share the cost of this complexity is a core value of DaaS. Keeping the desktop VMs close to the data removes one of the key risks with DaaS. Applications will remain responsive because their data is available with minimal latency. Splitting DaaS into a shared broker and dedicated desktops close to the data looks like a great solution.