Thursday, May 6, 2010

Cloud and the Evolution of Client Computing

The headline of Mark Bowker’s article in Network World recently caught my attention: “Will Cloud Lead to the Failure of VDI?”

No equivocations on my part; the answer is a resounding yes. Today, there are multiple deployment models, but fast forward to three to five years from now, when cloud computing becomes much more mature, and we will see only two models survive. And neither will be VDI (Virtual Desktop Infrastructure).

But let’s back up and look at what we have today.

First, there are thick client applications, such as Microsoft Office – rich applications locally executed on a desktop OS to give users a fast, seamless experience. This type of application is not going anywhere and will be around for a long time because it offers a high level of dynamic activity that cannot be rendered for a Web-only interface.

Over the last few years, a new class of applications has emerged that run in the cloud – for example Google apps or Salesforce.com. These apps are fundamentally built for the cloud and built to run on browsers from any computer or mobile device. These aren’t applications built to run locally which are just thrown into the cloud. Google is leading the charge here, with Google Chrome increasingly becoming an operating system itself. IN the near future, these apps will co-exist with thick client apps and end-users will require environments that support both models.

Somewhere in between is the third model today: VDI.

Though its proponents may say otherwise, VDI is not a true cloud-based solution. The apps were not built to run on the Web; they require rich local execution. What VDI does, in the simplest sense, is allow IT managers to put a rich local execution environment on a server and deploy it as a “cloud app,” albeit a crippled one at that. It offers none of the performance and offline use you get with a rich app nor the simplicity of a Web app. At best, VDI is a stopgap solution; it exists because most enterprise apps were not built for the Web.

In five years’ time when apps that need to run in the cloud are in fact purpose-built for the cloud, you can bet that VDI will become obsolete. In the end, we will have only two main types of applications: Rich, locally run applications for end use points and a rich set of applications built for cloud computing. Rich local execution apps will persist because computing will not be 100 percent online (yet) due to connectivity and performance. Some apps, such as PowerPoint (however much you love it or hate it), requires rich interaction, and therefore is best fit as a local, OS-based desktop application.

Interestingly, the motivation for VDI was always about central control. If VDI, as a management layer, is out of the picture, then how do you ‘control’ and centrally manage these two types of apps? We believe for rich endpoints client-side virtualization is the way to go – allowing central management of the desktop while enabling rich interactions and offline use. For the apps in the cloud – existing datacenter management tools solve the problem.

What do you think? What will a mature cloud computing environment mean for VDI?

Purnima Padmanabhan, VP of Products and Marketing

4 comments:

  1. Agree, except your five year timeframe is crazy. (i.e. there will still be a lot of apps that need to be central but that still are Windows only in five years.)

    Change your target to 20 years, and I agree 100%

    ReplyDelete
  2. I agree that Windows-based apps will not go away anytime soon. And a number of these are probably legacy apps that need to run centrally. But for these, companies already use something like Terminal Services or Citrix XenApp. By taking a fully loaded rich desktop and putting it in the data center, you negate any collaboration or performance benefits. It just doesn’t make sense (at least to us).

    We could only think of one corner case that may require VDI. If you have a legacy app that 1) has a rich client which cannot be put on a local laptop due to VPN or network configuration issues; and 2) cannot run on Terminal Services. Only in this situation would you put the app on VDI so the local client on the VM can execute on the same network as the server. Pretty narrow edge case, I would say.

    Purnima

    ReplyDelete
  3. I think there are lots of companies where they would prefer not to use a vpn. And if the app does not fit on terminal services then it's not such an edge case no more. Also, terminal servers are usually locked down. I see vdi used in places where they want desktops where there users have the freedom to install applications and configure the desktop according to their needs. At least in Europe there's lots of companies where the business decided that their users should be able to do that.

    ReplyDelete
  4. I agree VDI is a transition technology over long term. But you miss the real importance of VDI - there is a quiet driver that will manifest in a very disruptive way to pure HTML-like cloud computing - using VDI not as a platform to publish desktops and keep the mess internal, but use the underlying hypervisor model (with Moore's Law finally helping it in a capital way) to publish applications.

    You get the rich applications AND the isolation required for apps to run natively (and not screw with each other's registry entries/DLLs) - proving a rich experience anywhere.

    What? Experience with app has historically been poor? Yes, indeed. But the two road blocks to allowing those services to flourish have recently been removed - app contention (via the hypervisor), and app performance on the WAN (couple of clever new techniques have been spotted)

    I agree a virtualized endpoint is likely a requirement for people consuming services from many places that need the security. You guys will continue to do very well.

    ReplyDelete