Will we ever go massively to HVD (VDI) ?
Jul
16
Written by:
7/16/2011 4:07 PM
Following a blog post I've made some time ago, Are virtual desktops ready for mass adoption, I wanted to add my contribution to a debate that seems to finally resurge forgetting opposite marketing messages.
Andy Paul (@Andy_Paul_) has made a good overview of the subject in his article published last week To VDI or not VDI, while Stephane Thirion detailed his opinion in a blog post called VDI is overrated.
After reading these two articles, I wanted to write my 2cents on it.
Why not using HVD / VDI for the mainstream? Because of costs !
Even if I love the TVO (True Value of Ownership) concept, I have to say that when I'm designing a solution for task workers, costs are still driving the choice between VDI and Not VDI.
For my customers, this true value of ownership concept does exist, but not for task workers, only for executives and / or VIPs.
Infrastructure costs
Extra costs are bound to infrastructure (storage, hardware ...) but also to management, the one that are the most hidden, the most difficult to estimate but the one that can be the highest.
All major virtual desktops and infrastructure vendors are working on lowering (or trying to lower) infrastructure costs, like Citrix with the implementation of MCS, but it's not enough to make customers massively adopting this model.
Why? Because along with the storage cost, the scalability point has to be mentionned as it is a big disadvantage for HVD / VDI.
Even if you can read incredible ratios between cores and VMs, the reality is not as pretty if you look into the performances of the provided virtual desktops and the memory footprint required for each single Windows 7 instance running in a VM.
HVD / VDI Management costs are underrated
Plus, the management side is still a place where major vendors are not, relying on ecosystem partners, which can do a very good job but are still an extra cost in the model.
My question to VDI / HVD supporters : Do you really think that customers really want to switch from managing thousands of desktops remotely to managing them centrally in the datacenter as thousands (virtual) machines?
In my opinion, it's not solving a management issue, it's just centralizing it ...
And from my own experience : no they do not want to !
Even with shared images tools you still need (for example) antivirus softwares that have a big impact on the infrastructure but you also need to manage these desktops, which can be really expensive (even if every ecosystem vendor is showing its own amazing ROI, the final figures, when all layers costs are added, is still pretty high and can cause a project to be canceled).
HVD / VDI as a tactical solution
Regarding my own experience, working for very small to very large enterprise class environments (50K Desktops project, 278K Desktops Project ...) , Hosted Virtual Desktops (VDI) are used as a tactical solution only, for specific use cases, as a workaround when SBC does not fit, or, more sadly, when the customer fears SBC and does not want to test all his applications.
A Key question : what do users need to do in their virtual desktops ?
And that's the only important point. As an architect / consultant, my point is to design the right desktop for each user group, fitting their needs and having the most improved cost.
Here are some questions we could then ask ourselves :
- Do they really need 3D stunning graphics ?
- Do They really need to synchronize an iPhone ? connect a legacy specific USB device ?
- Do they really need to install their own applications ?
- ...
And then, with these questions among others, we are able to segment users in specific groups / populations according to their desktop use.
And, the conclusions are always the same (there are always some exceptions to the rule ...) : SBC fits 70 to 90% of users, HVD / VDI 10% to 20 % and fat desktops (until technologies like XenClient will be mature enough) take the remaining %.
And that's why I like the Citrix XenDesktop "Flexcast" vision, because you have all solutions in a single license ...