Why VDI in a SASE world?

Recently, we have seen an increase in customers who are reevaluating their current VDI environments and whether that technology is still the best choice for their business. Some of this activity has been generated by recent events in the VDI space such as the acquisition of Citrix by Cloud Software Group and the spinoff of the former VMware EUC division into a new company named Omnissa. Many changes have accompanied these large shifts, not all viewed as positive by customers and partners alike, which have encouraged companies large and small to consider potential alternatives. There is appropriate due diligence in that effort as use cases for any technology should be regularly evaluated for "fit for purpose."

Another driver for reevaluating VDI use cases comes from the rise of technologies that fall into the categories of SASE (Secure Access Service Edge) and SSE (Security Service Edge). Very frequently these products market themselves as "VDI alternatives" with eye-catching statements such as… (real quotes, names redacted):

"VDI is slow, complex and expensive. Ready to explore <company name>'s secure alternative?"

"<company name> makes VDI headaches go away."

"<product name> is engineered to eliminate the cost and complexity of traditional VDI solutions while fortifying your cybersecurity posture."

"… <company name> is demonstrating value in VDI replacement at a time when many organizations are moving away from traditional VDI environments—which are often viewed as legacy systems."

These statements all share similar presumptions - that VDI is complex, expensive and painful. A trite response to that may be to say that complex and painful are wildly subjective and a function of the quality of the design and architecture effort expended… and that SASE/SSE products are very far from free. However, a more informed response would illustrate that these statements indicate a distinct lack of knowledge about the true value of VDI in today's IT landscape.

What would you say… ya do here?

First, it is important to understand the scope of the different solutions. SASE/SSE products are focused on securing and managing browser-based applications and network traffic. For use cases where users do all their work within a browser using HTML-delivered SaaS (Software-as-a-Service) applications, these offer tremendous value. But, in spite of the growth of SaaS application availability, in companies large and small and across all verticals, we continue to see the truth in the following statement (I think the genesis of this came from either Shawn Bass or Brian Madden years ago, but this is my current version):

"Three things will survive the apocalypse - cockroaches, Twinkies and Win32 apps". 
I guess I should include Linux and macOS apps now as well.

App refactoring is an arduous process, and while many predicted that SaaS apps delivered via a browser would be the majority by this time, that hasn't happened. There is still a critical need to use desktop OS applications to "get business done," and in some cases, users vastly prefer the "fat client" versions of applications over their SaaS-ified cousins (MS Office/O365/Teams, I'm looking at you). VDI's capability to deliver all these apps in a secure and high-performance manner is still essential.

Location, location, location 

Additionally, it is important to consider the localities of execution that the different solutions embrace. For SASE/SSE, the user's endpoint device is where everything executes - apps run within the context of the CPU and memory of the endpoint and use its local storage and network connectivity. Since that is where the apps are running, and the source of the associated network traffic, managing that traffic is crucial and where SASE/SSE shines. However, in VDI, the locality of execution is within the data center and/or cloud which is hosting the virtual desktops. The client endpoint is largely unimportant and really only needs to serve a couple of functions - get a routable IP address and connect to the VDI brokering environment. The applications execute within the context of the hosting infrastructure and are disaggregated from whatever device the user happens to have in their hands. No application data is transmitted between the virtual desktop and the endpoint - just pixel changes, keyboard strokes, and mouse position via a display protocol. The application data remains in the data center/cloud and benefits from all the associated services such as backup/recovery, encryption, proxy, replication, etc. No data exists on the endpoint at all (for the pedantic, yes you can have the potential of data existing on the endpoint if you enable features such as client drive redirection… but that is a result of your decisions, not the technology). 

The locality of the application and user data and resources have tremendous performance implications as well. In a SASE/SSE environment with applications executing at the edge on the client endpoint but needing to access and interact with data residing in the data center/cloud, factors such as available bandwidth, latency, packet loss, etc. all contribute to the user's perception of how the app performs. As users now work from more places than just the corporate LAN, these and other "last-mile" issues can be incredibly impactful to their productivity. Conversely, in a VDI environment where the apps are executing within the same data center/cloud as where the data and other resources reside (potentially even within the same rack), these issues are negated and the applications have the high-performance access they need to run optimally. 

Keep the bits to yourself

From a security perspective, this disaggregation offers important benefits. If someone were to compromise a SASE-managed endpoint or intercept/MITM (Man-in-the-Middle), they would see endpoint traffic and have access to installed applications and their data. If a VDI endpoint (such as a thin/zero client) was compromised, there would be no data for the attacker to harvest or exploit. Furthermore, if the display protocol traffic was intercepted/MITM, they would see pixel and keyboard/mouse input change requests absent of any context as there would be no connection to the application currently being run within the VDI session. You may see that the user typed "I love VDI" but you would not know into which application that was being entered, nor which part of that application or any context on how the data may be used. 

The nirvana of "any"

This disaggregation also leads to another core value proposition of VDI - the ability to access any data, from any application, on any endpoint, from anywhere, at any time. This is a core enabler of the modern work mantra that "Work is an activity, not a location." Since there is no requirement on an endpoint device to be managed, joined to a domain, have appropriate agents and apps installed, etc. to access a VDI session, a user can truly be productive regardless of time, place or available device. For SASE/SSE, the endpoint is an important asset to manage and protect, and the level of effort to recover from a damaged or lost/stolen device is significant (even with Autopilot/drop-ship provisioning). However, for VDI, it can be disposable, and user productivity is restored by a simple trip to Best Buy, wherever they are at the time.

Which to choose?

There is much more value that VDI brings as well, but in the interest of this being a blog post and not an encyclopedia set (for the younger readers, encyclopedias were the Internet before the Internet was the Internet), we will pause here. Am I saying SASE/SSE has no value? Absolutely not. Am I saying that VDI is the best solution for all use cases? Definitely not. Deciding how to best empower the users and serve their needs requires a deep understanding of the use cases and desired/required outcomes as well as the true value offered by the available options. As we recently told one of our awesome customers, the technologies are not necessarily either/or, and there are great use cases and reasons in which to use both together. That, however, is another blog…