Posts Tagged Persistence
There was a good discussion at VMworld this year between persistent and non-persistent VDI proponents. The debate spawned from discussions on twitter surrounding a blog post by Andre Leibovici entitled “Open letter to non-persistent VDI fanboys…”. Representing the persistent side of the debate was Andre Leibovici and Shawn Bass. Non-persistent fanboys were represented by Jason Langone and Jason Mattox. Overall, this is a good discussion with both sides pointing out some strengths and weaknesses of each position:
So which is the better VDI management model, persistent or non-persistent? Personally I think Andre nailed it near the end of the debate, it’s all about use case! I know that’s the typical IT answer to most questions but it really is the best answer in many of these “best tech” debates. What matters to most customers is not which is the “best” but which is the “right fit”. A Ferrari may be the best car in the world but it’s clearly not the right fit for a family of four on a budget. So while it may be fun and entertaining to discuss which is the best, in the real-world, the most relevant question is ‘which is the right fit given a particular use case?’. If you have a call center with a small application portfolio, then this is an obvious use case for non-persistent desktops (though certainly not the only use case). I agree with the persistence crowd in regards to larger environments that have extensive application portfolios. The time it takes to virtualize and package all these applications and the impossibly large amount of software required to go non-persistent for all desktops in such an environment (UEM, app publishing, app streaming, etc.) makes persistence a much more viable option. This is why many VDI environments will usually have a mixture of persistent and non-persistent desktops. These are extreme examples but it’s clear that no one model is perfect for every situation.
Other random thoughts from this discussion:
—Throughout the debate and in most discussions surrounding persistent desktops, the persistent desktop crowd often points to new technology advances that make persistent desktops a viable option. Flash-based arrays, inline de-duplication, etc. are all cited as examples. The only problem with this is that while this technology exists today, many customers still don’t have it and aren’t willing to make the additional investment in a new array or other technology on top of the VDI software investment. So the technology exists and we can have very high-level, academic discussions on running persistent desktops with this technology but for many customers it’s still not a reality.
—Here again, like most times this discussion crops up, the non-persistent crowd makes a point of trumpeting the ease of managing non-persistent desktops while glossing over how difficult it can be to actually deploy this desktop type when organizations are seeking a high percentage of VDI users. Even if we ignore the technical challenges around application delivery, users still have to like the desktop…and most companies will have more users than they know that will require/demand persistent desktops.
—About midway through the debate there is talk about how non-persistence is limiting the user and installing apps is what users want, but earlier in the debate the panel all agreed that just allowing users to install whatever app they want is a security and support nightmare. I found this dichotomy interesting in that it illuminates this truth – whichever desktop model you choose the user is limited in some way. Whatever marketing you may hear to the contrary, remember that.
And last but certainly not least…
—In this debate Shawn delivers an argument I hear a lot in IT that I disagree with and maybe this deserves a separate post. He talks about the “duality” of operational expense when you are managing non-persistent desktops using image-based management in an environment where you still have physical endpoints being managed by Altiris/SCCM. He says you actually “double” your operational expence managing these desktops in different ways. The logic undergirding this argument is the assumption that ‘double the procedure equals double the operational cost’. To me this is not necessarily true and for many environments, definitely false. The only way having two procedures “doubles” your operational cost is if both procedures require an equal amount of time/effort/training/etc. to implement and maintain. And for many customers (who implement VDI at least partly for easier desktop managment) it’s clear that image-based management is viewed as the easier and faster solution to maintain desktops. I see this same logic applied to multi-hypervisor environments as well and simply disagree that having multiple procedures is always going to mean you double or even increase your operational cost.
Any other thoughts, comments or disagreements are welcome in the comment section!