Before I begin, I want to thank Brian and Gabe for inviting me to blog on Brianmadden.com and especially Gabe for nudging me that I should stop procrastinating and get on with it. Thanks guys!
For years now the debate over PC vs. VDI has raged on. I’ve watched it from the customer and vendor side of the fence and feel that the discussion too often is incomplete which causes confusion for so many. I’ll begin with reminding everybody that we used to talk about FAT CLIENTS.
Fat clients were and still are great for many use cases, which we have understood for ages. However, we also understood many of the challenges we faced with them. Filled with crap from the IT department that you didn’t need or want to use, patching nightmare, inventory maintenance, configurations drifting, software packaging and distribution overhead amongst many other things that ultimately led to slow change in a managed environment due to so many moving parts that needed to be tested together. Broadly speaking we called this OpEx (operational expense). It’s well understood that this is the largest part of the cost of the PC lifecycle as shown in fig 1 below.
Fig 1: Comparing the Fat Client OpEx to CapEx.
PCs were not that expensive once they matured, i.e the CapEx (Capital Expense) was lower than the OpEx. As a result we understood that we needed to optimize our PC plant to not just reduce OpEx, but to also be able to make changes in the environment faster. To do this, we’d have to invest in better management tools and a certain level of service or settle for chaos and security risk with so many still allowing local admin rights. This was consistent with what Microsoft was also telling the world. “A better managed PC is a cheaper PC.”
Then with much fanfare came along VDI and mistakenly over asserted claims that it would solve the ills of the fat client era. Every vendor made the mistake in the early days of leading with the promise of cost reduction, not appreciating how diverse an enterprise PC environment was. I recall the “power of one” message from Citrix and many similar promises from VMware.
I’d submit that the reality for most is illustrated in figure 2 below. On the right of the seesaw (also known as teeter-totter) it’s the combined Fat Client story and on the left side it’s the VDI story reality for many.
Fig 2: VDI vs. Fat Client – OpEx and CapEx view.
That reality is higher CapEx and OpEx for VDI. The higher CapEx in VDI comes from needing client and server hardware as well as storage etc. The higher OpEx comes from the reality that the marketing message of single image management from the VDI vendors is not yet feasible in an enterprise at scale with a diverse user base. Attempting to do so adds further operational complexity. I have witnessed first hand people who have tried to brut force their way to scale this model and it’s not delivered the ROI that was hoped. This has resulted in scaling back of the VDI project because the politics of the initial architecture made it very hard to save face and change course.
As a result many stick with what they know works and end up implementing limited VDI in a 1-1 model with existing management tools. This of course further adds to CapEx.
The CapEX challenges are well-understood and the industry is making good progress to solve these. However in my assessment the logical conversation stops here for most and they don’t think hard enough about the OpEx reality. This starts with many analysts I have spoken to who add to the customer confusion, by over rotating on CapEx and therefore poopooing the 1-1 model. I’ve argued many times that there is too much focus on just talking about the CapEx and a lot more light needs to be shone on the OpEx components. In fact I believe that’s the smoking gun that should be front and center of the conversation. The answer I’ve got back in the past is that customers don’t believe OpEx and buy on CapEx. This line of thinking really irritates me since it’s fundamentally flawed.
Customers have understood for a long time that OpEx is all about a better-managed PC irrespective of an organization’s will to accept some of the caveats that come along with this. So overly focusing on the CapEx of VDI is the wrong answer. CapEx is a side effect of VDI that needs continued innovation as part of a VDI solution out of the box so it’s comparable to fat client CapEx. The good news here is that progress is being made.
OpEx however is a different ball game. I don’t believe the VDI vendors will, can or should fix this problem entirely. It’s a desktop management challenge, and it needs to be fixed by management vendors unless the current crop of VDI vendors, decide that they truly are going to become desktop management vendors. I have limited expectations, as any new capabilities VDI vendors develop will be focused on future workplace concepts. Sure we’ll get small acquisitions and lots of marketing promises, but show me an established vendor who invests forward on a platform that they also say is dying as part of a previous era?
To make matters worse, I see next to zero innovation from the traditional systems management vendors to do anything about this except for stay as status quo and follow a roadmap based on incrementalism. Yawn.
Therefore, I expect more successful enterprise scale VDI deployments to be based on a 1-1 model and an increasing need for these enterprises and the partner eco system to be willing to write their own tools leveraging open source where they can. I also hope the smaller private vendors who are trying to help customers move to a shared model, gain more traction and continue to scale up their solutions for enterprise customers. However I still believe that for most, 1-1 is the path of least resistance.
This all seems like a lot of risk and not high on the priority list of things to do. Perhaps the fat client is better, so why even consider VDI?
I’ll share some of my experiences and observations in my next post.
(Note: You must be logged in to post a comment.)
If you log in and nothing happens, delete your cookies from BrianMadden.com and try again. Sorry about that, but we had to make a one-time change to the cookie path when we migrated web servers.