Server Based Computing versus Virtual Desktop Infrastructure

One of the things I did not see coming was the pending battle between Server Based Computing (SBC) and Virtual Desktop Infrastructure (VDI). This first became obvious at BriForum 2008 with sessions titled such as “SBC vs VDI”. The resulting discussions were very lively and ran throughout all the different VDI discussions. This is also being shown through the variety of posts related to the relative benefits.

Having been around the block a few times, I see this discussion to be a bit religious in nature. In other words, every one has strong beliefs and it is unlikely that many people are going to change their minds about what they believe in. Secondly, it is pretty pointless to argue when it comes to doing what fits best. Either it works for you or it does not. Talk is cheap. 🙂

To me, the two are much more related that what people typically say. Surprisingly this can be true in life with many other topics as well. Some difference has been isolated and blown out of proportion to the point of excluding the other. Oh well, that’s just how people can be.

Truthfully, I would classify VDI as a new variant of SBC. Why? VDI runs on a virtual machine on a server. The truth is that by adding virtualization, it is possible to host multiple user desktops using the actual desktop operating system. The attraction is obvious if you understand the weaknesses of traditional SBC. With Terminal Services, there are limitations related to applications installing and the user not getting their normal desktop experience. There is also the risk of having one system being shared without virtualization. All it takes is one false step in kernel space in the system goes down.

On the other hand, virtualization has a cost. It should never be expected that virtualization will match native performance. Also, virtualizing at the hardware layer guarantees a great deal of duplication between virtual machines. This includes having a copy of the operating system per user. The disk model also means that each user is likely to own a virtual drive in the gigabytes. In collective, this adds up to a massive amount even if most of the space in the drives is not being used.

These are just some quick surface differences. Is there really anything worth getting upset about? Well, no.

But, strangely I sense this tension between the two groups. The old SBC group almost seems a bit threatened. Maybe it is just my imagination. If it is there perhaps it is just the uncertainty.

Anyways, Brian Madden has already declared that he thinks VDI is going to win. To me this seemed a bit early to declare and besides that it will not really matter in the end since both are actually SBC.

Perhaps another way of saying it is that VDI is disruptive and is not being treated real seriously by the old SBC camp. Well, some care. But the point is that VDI is seen to be a bit like a toy compared to the mature existing SBC market.

The news is that VDI is not going away and new trends saw that it is well on its way to supplant the older SBC business. I can sense a few heads shaking. Well, maybe not tomorrow. But, it will eventually.

The reasons will become more obvious as time goes by. The first step was to remote the desktop environment in its natural state. This has been accomplished. The next step is to tackle things that SBC never did quite figure out. This includes the ability to remote high performance graphics/audio on the LAN. This too has already begun to happen. Further refinements are coming including the ability to remote USB devices and further integrate the experience between the two machines. The goal overall is to completely blur the distinction between the client and host machines. In a sense, you get two machines with one environment with the combined power and strength of each.

Ultimately you get the ability to have a universal desktop which works anywhere (well almost). This universal desktop does not really care how it is run (local or remote) and always adjusts to situation with the maximum performance. It is incredibly idealistic to believe this is possible but the writing is already on the wall that it is coming and sooner than anyone is expecting.

Part of the reason I blog is to share what I see coming. It is hard to convince anyone in the beginning but given enough years it eventually comes true.

About five years ago I put forward an idea inside Citrix that we should investigate using virtualization to support different operating systems remotely. This was proposed to address the need to remote workstation operating systems (like Windows XP) which would be more compatible than the server (like Windows 2003). It was also hoped that we could remote things like Linux if needed. I saw this as the future of MetaFrame since it would give a much more mainframe like approach to hosting different platforms. In other words, the only decent way to truly support applications is to given them what they expect and then find a way to remote it. The idea did not catch on at the time. It would not be until VDI came around that this idea finally came to light.

About 13 years ago I proposed that we create a single user version of WinFrame that would work on Windows (Not NT). The idea was it would help to have a commercial product intended for consumers. At the time Citrix was not widely known and an easy way to address it was to target the lower end with a product that would be seen and appreciated. It was not until PortICA came around in 2006 that this begun in earnest.

It is little known that around 2002 there was a project called Jardine that duplicated MetaFrame on Windows XP using Terminal Services. This was very clever and timely work done to target managing XP with ICA. The problem was that Microsoft said no. They didn’t like it. They refused to license Terminal Services for the non-server environment to Citrix. The project died soon after.

PortICA was built on the assumption that we could not use Terminal Services interfaces. This meant rewriting aspects of the TS stack since we simply didn’t have rights to them.

The realization that came from this is that Citrix once again had control of a stack and that past limitations would be removed if we saw an opportunity. There is a big play for potential improvement over the typical TS code base.

Balanced against this is the constant tightening of the TS platform with what Citrix is allowed to do. Microsoft wants things to be just so and Citrix really has little choice in the matter.

But perhaps the most obvious reason why VDI will come out ahead is the shear number of competitors chasing after the business. Unlike old SBC/TS, there is pressure to evolve quickly with some very nimble and small companies. It will be true that companies like Citrix will validate the market much like IBM did the original personal computers but this does not mean that anyone is guaranteed to win. This is not related to size but rather mind share. If Citrix does not move quickly to embrace VDI even stronger, it risks losing this market to younger players.

However, all is not lost. SBC is still important and will be used to leverage into the VDI market. The most clever thing that Citrix could do right now is combine their offerings back into one. One of the most consistent messages I heard at BriForum is that one product is better than two in this space. This is largely viewed from a management angle. One of the companies is already providing a dual VDI/SBC product. There is no reason for Citrix not to do this as well.

So, why am I writing all this down?

Well, I’ve written it recently internally (based on the trip report to BriForum). My concern is that this information will not reach the right people easily. I also would deem that this kind of stuff is not secret and should be openly shared. Pretending that people don’t know is perhaps one of the most severe mistakes any organization can ever make.

Having come to the end you might be curious what I think of the title.

My answer is that it should really be “SBC and VDI”. The versus implies turmoil and in this case it should really be overlapping circles of coverage.