VDI post on Madden: good observations, different conclusions

Last month, I predicted that VDI will be just a niche play as the cloud matures. Yesterday Brian Madden posted a dramatically different perspective about the extent to which VDI will penetrate computing.

This perspective was not his own, but he thought it interesting enough to write about it. The problem though is that although the observations are reasonable, the conclusions are awful.

Let's look at specific examples.

First, the post notes that computing is changing rapidly, and of course I agree. More apps are moving toward the cloud for simplicity and portability reasons. The apps that will be left behind are rich applications that require local execution. The problem with VDI in this scenario is that you get the worst of both worlds: you get neither the simplicity of the cloud app, nor the functionality of a local app. It just doesn’t make sense to take your fat desktop and stick it into the cloud (except in niche scenarios), since VDI will only become more cumbersome as the cloud matures.

A second observation in the post invokes Moore’s law, saying that as servers become better and cheaper, the cost of VDI will drop. This might be true if users continue to use the same applications, but that’s not how computing works. Applications will continue to expand and consume the additional server bandwidth, negating any savings from Moore’s law.

Thirdly, the post goes on to describe deployment models. The primary pain point that desktop virtualization solves is desktop deployment and centralized management. With a client-based solution, IT can provision an additional VM simply by publishing an html link and sending an email. It’s cheaper, faster, and more resilient than provisioning additional boxes in the datacenter, as you do with VDI.

The post also completely ignores some fundamental issues with VDI. For example, a defining characteristic of VDI is the pooling of resources in the datacenter, but the downside to pooling is that you are magnifying the risks and complexity of desktops—the classic “eggs in one basket” problem. With VDI, you are taking inherently resilient, distributed desktops and turning them into a highly concentrated system that is vulnerable to malfunction. With VDI, if the system goes down, all your desktops go down. A related problem is that IT has to over-provision in order to prepare for peak capacity (e.g., 9:00am on Monday morning). But it’s difficult to predict group behavior, and your “over-provisioning” may prove inadequate, anyway.

Finally, the post fails to address Madden’s own Offline Paradox. Offline capability is at the core of VDI’s shortcomings. There are many times when a user finds himself without an Internet connection, such as on a plane or when the connection goes down for whatever reason. With VDI, users without a connection are unable to access their virtual desktops. This is a key area where a client-based approach excels.

What do you think the future holds? Will virtual desktops live in the datacenter or on the host machine?

Purnima Padmanabhan, VP of Products and Marketing

What is the right virtual desktop model for BYOC?

A recent blog post by Brian Madden compares the security differences between Type 1 and Type 2 hypervisors. Brian writes that Type 1 bare-metal hypervisors are “possibly more secure due to the smaller attack surface of the hypervisor.” But he’s quick to point out that neither Type 1 nor Type 2 hypervisors are a one-size-fits-all solution.

After reading Brian’s blog, I thought about MokaFive’s approach to security. The problem with security is that you can’t talk in absolutes: the discussion depends on both the use case and its associated risk profile. If you are completely intolerant of risk, then you have to ignore the benefits of most Internet-based computing and keep your computer offline, locked up in a dark room. But in the real world, you have to support mobile and offline workers so they can be productive, and with that comes some risk. This is true of any computing model, but it’s important to mitigate that risk by choosing the best technology for your needs.

Let’s specifically look at the BYOC model where organizations want to enable computing on employee-owned machines. While there are many models to deliver specific applications from the cloud using technologies such as terminal services or even app streaming, these don’t provide the full usability of the entire desktop environment. So, what are the options for BYOC? There is VDI, but it provides no offline access and contrary to popular belief is not completely secure, either. While the VDI desktop lives in the datacenter, IT has no way to control the endpoint machine accessing the VDI session. Those endpoints could have keyloggers or screenscrapers that can siphon data from the VDI session.

In contrast, with the client-side models, a fully encapsulated VM is delivered to the endpoint, either directly on baremetal (with Type 1 hypervisor), or on top of an existing OS (with Type 2 hypervisor). There is almost unanimous agreement that a Type 1-based model will not work for BYOC, since no user will allow IT to forklift their personal machine. Only when Type 1s are shipped with OEM machines will this model will become viable for BYOC.

Net-net, a Type 2-based client-side model, where a fully managed, encapsulated VM is delivered on top of the user’s existing OS, is ideally suited for BYOC. It provides users access to the corporate environment anytime, online or offline, without impinging on their personal machine environment.

MokaFive supports a Type 2 model today while allowing you to grow to a Type 1 approach in the future. We leverage the MokaFive player residing on the client to provide additional protection against risks associated with BYOC. I have outlined below our approach with seven layers of security that protect against your concerns:

1. Host checker

• Checks for basic performance characteristics of the machine. It can also be extended to check for any other security characteristics of the host (such as configuration and execution status of anti-virus software) prior to the launch of the virtual desktop.

2. VM encapsulation

• Encapsulates a full, locked down OS controlled by IT. This allows IT to completely control the patch level and GPO security settings.

3. VM encryption

• Encrypts image with AES 256, including the base image and all user data. We also intercept all I/O that the hypervisor writes to disk or to memory, and this data is compressed and encrypted.

4. Tamper resistance of both code and policies, and copy protection

• Attempts to alter the executable or configuration will disallow the Player from running. Also, by policy, IT can disallow users from moving images from one machine to another.

5. AD authentication / Two-factor authentication (RSA or PKI)

• Integrates with Active Directory to enforce users’ authentication prior to virtual image access. Optionally, IT can configure RSA SecurID or PKI as a second authentication factor for additional security.

6. SSL

• Communicates with the server over SSL. Clients validate the server’s SSL certificates against a Certificate Authority.

7. Policies

• Enables administrators to have fine grained, centralized control of operational and security polices, such as peripheral access, and ability to drag and drop files from host to guest or vice versa.

Simply put, MokaFive is one of the few vendors that provides a secure, fully managed virtual desktop model for a BYOC model. Stay tuned: in an upcoming blog, we will talk about BYOC best practices.

Purnima Padmanabhan, VP of Products and Marketing

To centralize, or not to centralize

You wouldn't do this with eggs. Why would you do it with your company's desktops?

Desktop virtualization holds great promise to dramatically reduce IT support costs, while allowing end users unprecedented access and flexibility. There are now dozens of offerings to choose from. But beware – your approach matters. A lot.

Picture the last time your PC crashed. Now imagine it happening to everyone in your company. All at the same time.

It makes complete sense to centralize certain aspects of desktop management. Access and policy control, reporting and image updating, definitely. And certain compute-intensive applications. But it makes little sense to centralize execution.

Desktop execution should (almost) always be decentralized.

A decentralized system is inherently more resilient than a centralized one. No single incident can bring down the productivity of the whole. This has been a truism in computer science, and it’s proven itself in many other systems, not least of which is the Internet itself. On the Internet, no single router or gateway failure can bring down the connectivity of all the endpoints. Instead, in the case of a failure, packets are rerouted around the downed node and transmissions successfully proceed.

Similarly in a decentralized desktop environment, a single PC failure, or even the failure of the management server itself, does not stop the productivity of the whole. Sure, a single user may be inconvenienced (and we all know that certain users are more important than others :) ), but there is no chance that the entire system can come down. When we say “no chance," we don’t actually mean “low probability,” or “five 9s,” etc. With decentralization, there is *no* chance of systemic failure. Nada.

Moreover, a decentralized desktop system is usually lower cost because consumer CPU and storage is much cheaper in aggregate than the equivalent resources in the datacenter. And decentralized execution provides the best user experience, since the user can be online or offline, does not have to worry about bandwidth, and local CPU provides better performance than a centralized remote one.

Now, certain narrow use cases do warrant centralization. But the vast majority of desktops should remain decentralized.

Something to chew on

Even with 14 years of experience and a bazillion dollars, Google’s search services went down last May. What’s the likelihood that your VDI will fare better?





Caveat VDI

Your existing physical desktop environment is already an inherently resilient system. Your company (and your career) can easily survive the occasional user hard drive crash or network issue. But now you’re thinking about scrapping that beautiful architecture, and replacing it at enormous upfront and ongoing costs with an inherently more fragile and risky one. There may be a legitimate cost-risk-benefit reason for you to do this – just be sure you’ve done the analysis.

A better way

Distributed Virtual Desktops (DVDs), a term coined by IDC, represent the low cost, highly flexible world of the New Desktop (capitalization intended). In this model, like your physical desktop solution, DVDs are controlled centrally, so access control, policies, reporting and image management happen efficiently by a single team. But desktops are virtualized so the same golden image can run on any platform, and any hardware configuration. This makes it better than your current physical desktop solution.

And, in stark contrast to VDI, DVDs execute in a decentralized fashion. This means that issues (and we all know issues can happen) are isolated to a single user. As with VDI, there are multiple offerings in the DVD space—MokaFive is one. At MokaFive, the tenet of decentralized execution has been imbued from the very beginning and throughout every aspect of our product design. We believe it’s the only way to go.

Burt Toma, Director of Products

Deploying XenApp Within a Virtual Desktop: The Why's & How's

We posted recently about the possibilities of creating a flexible, yet secure virtual desktop - with the right management tools. If you're familiar with the benefits of virtualization and have already invested in application virtualization technology, now you can go a step further to get security and centralized management of the entire desktop image. Deploying a well-managed virtual desktop will secure your user's operating system and simplify management of the entire environment, without sacrificing the ability to let users customize, run offline or on the go. The secret with virtual desktops is to "manage centrally, execute locally."

Deploying a flexible virtual desktop management solution is a relatively quick and simple process (a few hours to set things up), but can save IT administrators an impressive 60% on desktop support and management costs. Support costs drop as users can simply restart their virtual desktop to "rejuvenate" the original clean-state image with all of its applications and settings, wiping away any malware picked up along the way.

For instance - if you're already using XenApp, here are the basic steps:

1) Make sure your XenApp Server is configured to talk to your Domain Controller - this is important because you will be targeting apps based on users

2) Use MokaFive’s Creator to build a base LivePC image

3) Now that you have created a base image, you can install other applications, including XenApp applications, on top of it

4) From MokaFive's management console, target this LivePC to any users you choose to receive it

5) In the XenApp Access Management Console, set a number of policies for how you want XenApp to launch and run (from the server, locally, online/offline, etc.).

For step-by-step instructions, check out this document.

MokaFiveTV is Live

Curious to know more about desktop virtualization? The concept of managing virtual desktops with layers? Want to learn the backstory on how MokaFive came to be?

To satisfy your curiousity and learn about innovations in desktop computing, we invite you to check out the MokaFiveTV channel on YouTube. Our co-founder and CTO John Whaley, along with co-founder and current Stanford CS professor Monica Lam as well as other experts from the team will give you an inside look at what it's all about.

For starters, you'll find the following video episodes:
MokaFive: A brief background
Virtual Layers - Inside View
At the Whiteboard - Layering
Virtual Layers - Application Management

For an even more intimate view, follow "Joe Whaley" and MokaFive on Twitter.