How Workspot Made VDI 10x Simpler

Author: Amitabh Sinha

Publish on: Jun 30, 2016 6:00:00 AM

I was VP of Product Management for XenDesktop from 2009 to 2012. After that, I was the General Manager for XenApp and XenDesktop. Our CTO, Puneet Chawla, was the founding engineer for VMware View. A few years ago, we got together with the goal of simplifying VDI so that it could fulfill its potential.

In thinking about how to simplify VDI, we looked to John Maeda for inspiration. An esteemed designer and technologist currently serving as Design Partner at the VC firm Kleiner Perkins Caufield & Byers, Maeda's first law of Simplicity is reduction/elimination. As a result, our goal was to eliminate as much as possible from the typical VDI architecture. Let me show you how we did it.

Built as on-premises solutions in 2007-2010, Citrix XenDesktop and VMware Horizon are very similar architecturally. In order to show you how we made VDI 10x simpler, I'm going to breakdown XenDesktop into its components and then explain how we were able to eliminate them. (Keep in mind that the same concepts can be applied to Horizon.)

XenDesktop Components

For every site, a typical XenDesktop deployment needs each of the following in pairs (for HA):

  1. Netscaler
  2. StoreFront
  3. Desktop Delivery Controller
  4. SQL Server
  5. Citrix Licensing Server
  6. Provisioning Services (PVS)

XenDesktop components we axed

We eliminated XenDesktop Netscaler

Nearly 80% of customers already have an SSL-VPN from Cisco, F5, Pulse Secure, or Fortinet. We wanted to enable them to leverage their investment in their existing SSL-VPN. In order to do this, we added code to our clients so that they could integrate with each of these gateways. We did not do this by integrating with their VPN clients. Rather, we embedded the networking logic to connect with their gateways directly into our client. If a customer has one of those gateways, they don’t need to install anything from Workspot in their DMZ, and their users continue to work with a single client. This is infinitely simpler than convincing your networking team to deploy new appliances!

We eliminated Storefront

StoreFront serves multiple funtions. Besides authentication, it supplies users with the resources they're entitled to and it aggregates resource entitlements across farms. To begin with, we built the equivalent of StoreFront for a multi-tenant cloud-native service. However, we went much further in order to simplify the underlying process.

A typical Citrix user request goes through 10+ steps in order to get access to a resource:

  1. (a) netscaler - storefront - controller - sql server - licensing server to get entitlements
  2. (b) netscaler - storefront - controller - sql server  to get ica file
  3. (c) netscaler - storefront - controller - sql server  to connect to a resource.

Our cloud not only resolves which users get what resources in real-time, it also pushes those changes to the client in real-time. This means that when a user opens their Workspot client, not only do they immediately see what resources they can access (without even talking to the cloud), they also have the information needed to connect to those resources. Thus, Workspot reduces Citrix's 10+ steps to a single step. See? 10x simpler. 

This architecture also delivers better reliability and scalability. In XenDesktop, if one of those handshakes fails, the user cannot get any desktop or app. In our case, the StoreFront authentication component lives on the device. Even if the cloud is unavailable, the user can connect to the resource as long as the resource is available. Because we don't have each connection request going through multiple components multiple times, the solution is even more scalable.

We eliminated Desktop Delivery Controller

The delivery controller is a broker and a single point of failure. If you have a large set of desktops/apps behind a single broker and it fails, then users cannot connect. To eliminate this problem, we built a multi-tenant cloud-native controller in the cloud.

Taking it a step further, we made the clients much smarter because we didn't want the cloud to be a single point of failure. Instead, we push and cache connectivity information on the clients directly. Even if the broker is not available, clients can connect to their resources so you don't have to worry about deploying controllers in high availability, or load balancers for load balancing, or SQL servers.... Again, 10x simpler. 

We eliminated Licensing Server

We eliminated the licensing server, of course. Our solution runs in the cloud, and it knows whether you are licensed or not. Infinitely simpler for you not to have to worry about high availability, etc.

We eliminated PVS

In the early days of VDI, PVS was an extremely useful tool to provision desktops. At that time, the hypervisors did not have the proper tools to thin-provision. Storage did not have the ability to de-duplicate. As a result, PVS was essential for reducing the cost and improving the performance of storage. Seven years later, though, storage and virtualization have evolved dramatically. This means you no longer needed an external tool to optimize desktop provisioning. We built a stateless connector that sits on the infrastructure layer (VMware, KVM, OpenStack, Hyper-V, etc.) and can provision desktops. The connectors are configured from the cloud and run in high availability mode (Active-Active). Net result: 10x simpler.


VDI 2.0 is 10x simpler

Simplified VDI benefits customers in so many ways. Simplification results in signficantly lower TCO - 95% lower CAPEX, 50-90% lower OPEX. Simplification also opens up the possibility that VDI can be more scalable and more reliable. Why? Because simple + cloud = infinite scalability. I'll talk all about that my next blog post.

In the meantime, if total cost of ownership is something you're interested in, I invite you download our whitepaper below.

Comparing TCO: VDI 1.0 versus VDI 2.0

Subscribe To Our Blog

Recent Posts