Response to the "Open letter to non-persistent VDI fan-boys"

Recently I wrote an article exploring new ways of implementing non-persistent VDI and wondered why not leapfrog traditional PC management? This resulted in a healthy comment stream and also a blog post from @andreleibovici from VMware called Open letter to non-persistent VDI fanboys, encouraging us all to move exclusively back to the future.

Recently I wrote an article exploring new ways of implementing non-persistent VDI and wondered why not leapfrog traditional PC management?

This resulted in a healthy comment stream and also a blog post from @andreleibovici from VMware called Open letter to non-persistent VDI fanboys, encouraging us all to move exclusively back to the future.

While I respect Andre, enjoy his many thoughtful blogs and look forward to meeting him in person soon, In his open letter post, Andre makes a number of assertions that I think misunderstand the broader picture and are worthy of some further discussion.

“This is very 2011” and debunking the fan-boy myth

Andres equates everything to image management and goes on to discuss the evolution of full/linked clones and advanced tiering, calling non-persistent approaches “very 2011.”

This is not an image management problem that storage alone will solve. Those are the days of thinking with Ghost like tools, which never provided enough flexibility to deal with diverse user needs. This is about state management. I'd argue that, "All desktops are non-persistent." It's just that some have a longer shelve-life than others. I.E. You most likely format/rebuild your physical PCs every 3 years. You may want to rebuild your 'persistent VDI' from the clean image every 6 months to prevent drift or invest now to ease the next OS migration. Perhaps you want to build a capability that enables your desktops to burst to public cloud infrastructure. These are the types of things that many customers want.

The easier you can make the refresh/rebuild process the more often you can do it thus the cleaner your environment is. The more seamless to users (e.g. with personalization) the less pushback you'll get from the business. To achieve this you can’t manage your desktop as a monolithic image.  You need to manage the OS/APP/USER/DATA state independently if you want to move past the limits of today’s management capabilities, which don’t achieve this goal.

This in my opinion has not been possible for a desktop OS previously with the goals I outlined in my article. Therefore I’ve argued for a long time that the best way to proceed is to simply use persistent VDI without using complex and expensive storage. In fact I did this back in 2004, and find that sticking with this exclusively rather dated given the evolution of technology. I’m also not asserting that there is only one way, which is what fan-boys do. The intent of my non-persistent VDI article was to demonstrate the art of the possible and encourage more people to think about where things need to go.

Living in a central data center bubble

Andre goes on to argue in his post and follow up twitter discussion that things are greatly simplified with sticking to status quo inside the data center.

“My claim in this article is that non-persistent desktops, Linked Clones and alternative image and app management solutions are not a requirement any longer for the large majority of use cases since now we can utilize fully provisioned persistent clones without the capacity and performance penalties”

“My point is that in this new and modern world where all this amazing new storage technologies are helping us to simplify deployment and management there is no need to try to create complex science experiments to solve something that is already mastered and solved via a different disciplines; in this case storage.”

I agree with Andre here whole-heartedly.  I just don’t think it is enterprise reality or what customers want as a set of capabilities for broader adoption. 

It’s generally well known that no matter who’s VDI solution you use. Once you reach 150ms latency, user experience predictability degrades.  Global enterprises therefore have GEO location data centers and looking forward want to take advantage of public cloud infrastructure. This means that there is a very real distribution problem for OS/App/User/Data state. Andre goes further to argue that these are edge cases so why design for the minority?

The "good enough" product management lesson

I’ve heard this mode of thinking from many people in the past. It goes something like this. A bell curve shows the distribution of what would serve the majority of users. Edge case users are labeled as extreme and investment dollars are directed towards the average users with a good enough capability list drawn up. However there is a problem with this.

When you don’t take the time to understand and engage with these so-called edge users, you can miss out on valuable insights. If you go out and observe carefully what these folks do you’ll realize some key things. Most likely that these are some of your largest most insightful potential customers who really understand what it takes to implement VDI. If you dig a little deeper you’ll begin to understand that their whole persistent model is in fact a big work-around due to a limitation in your capability. Dig even deeper and their needs become amplified, something you won’t get by just engaging with people from the middle of the bell curve. Often the needs that you uncover through these edge users are also needs of a wider population.

I believe, the need for a stateless desktop is broad across all customer segments. The VDI industry incumbents have not met this need. This is why we keep circling back to why not just use published desktop with XenApp or simply use persistent VDI. These folks are right, because the current set of capabilities only meet those needs and only the edge case extreme users innovate past that. What’s required is a deeper appreciation of the needs of enterprise customers and new ways to take advantage of diverse and distributed cloud infrastructure. Address those needs and the volume of VDI use cases represented under the bell curve stands a chance of growing. Else be content with a 7% of enterprise virtual desktop industry. There’s an opportunity for somebody to lead. I don’t see this coming from the VDI incumbents. Hence why I put together innovation from smart private players that I think is not complex with some refinement to open people’s eyes to the elephant in the room. Some may consider that an opportunity…

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.


Nice and honest thoughts on this wholehearted discussion. We both agree that there is space for both use-cases. I also agree that the right and seamless approach to stateless desktops, including image and app management, has not yet been delivered by market players.

I think the next steps on this discussion should be over dinner and beers.



@harry - You have hit upon numerous items, including continuous change that is required across management tools, improved observation skills for product marketing and management (marketing fluff does not solve problems), and of course the biggest of them all: cost vs. complexity (here it is NOT about CAPEX or OPEX). If something does not work the way it was intended, users go back to what they're comfortable with.

Long story short, it's silly to think we all know where the puck will be, but sometimes the best way to predict the future is to invent it! (thx to Allan Kay).


I think the most salient point I take away from this is the celebration of mediocrity in IT.  Focusing on "good enough" and ignoring outliers is a sure way to stave off adoption of VDI.  Always taking care of the "low-hanging" fruit and EVENTUALLY (read never) conquering the hard cases mires us in the past, and helps vendors to rest on their laurels as opposed to improving products which would ultimately benefit EVERYONE.  The attitude of "letting advances in hardware take care of it" has resulted in tons of sloppy code being written (who remembers the days of DOS when stuff was crafted in Assembly Language?)