SBC + VDI + Streaming = A full application delivery solution

I recently wrote a paper about VDI and when it can be used versus when server-based computing can be used. I think the paper was generally well received, but based on some of the comments it's clear that I didn't do a good enough job articulating how SBC and VDI relate to each other.

I recently wrote a paper about VDI and when it can be used versus when server-based computing can be used. I think the paper was generally well received, but based on some of the comments it's clear that I didn't do a good enough job articulating how SBC and VDI relate to each other. What I mean is that in that paper I talked about when VDI is the right fit and when SBC is the right fit, but I analyzed each solution by itself in a vaccuum. In the real world, a complete application delivery solution will be made up of both SBC and VDI (and most likely, some application streaming as well).

In the paper I only included one small section called "When does VDI make sense?" I explored this issue in more detail in an article I wrote last month for TechTarget. I'd like to revisit that here.

Server-based computing: The solution for 80% of our apps

As you know, VDI technology will never replace local desktop computing 100%. But just we got most of the mundane applications off of the desktop and into the datacenter delivered via SBC, that only got us so far. (Maybe 80 percent?)

So why only 80 percent? Why can't you bring the rest of your applications into the datacenter via SBC? Possible reasons include:

  1. Users need offline access (traveling laptops, etc.)
  2. The applications are not terminal-server compatible.
  3. The applications are resource hogs that "kill" a terminal server.
  4. The applications are graphics-intensive and don't work well over a thin-client remote display protocol like RDP or ICA.
  5. The effort to make the apps work in the SBC environment isn't worth the benefit.

How to address the "other" 20%

VDI is not the be-all end-all to application delivery. Terminal Server-based SBC is a good foundation. From there, look at the above list and think about VDI. Items number 2, 3, and 5 can be solved with VDI solutions. This means that VDI technology is useful in any scenario where you have power users or users who need strange, non-terminal-server-compatible applications, but where the users still need the flexibility associated with traditional SBC environments. (Examples include connecting to applications from anywhere, over slow connections, etc.)

If VDI can solve issues 2, 3, and 5, then what about 1 (offline access) and 4 (grapical apps that don't work via RDP or ICA). Since those application use cases cannot be solved by any SBC-based solution (traditional SBC or VDI), then we have to look elsewhere. And that's where application streaming comes in.

By streaming apps, we can get them to run locally on a device while centrally managing them. This solves problems 1 and 4 from the list above. Of course it also potentially solves issues 2, 3, and 5! So if app streaming can solve issues 1-5 above, then why not use streaming for everything?

The reason is that the list above contains only the downsides of SBC. But SBC has many advantages over streaming. (Again, the term "SBC" here refers to the remote presentation architecture, be it "real" SBC or VDI.) A short list of SBC advantages might include:

  1. Access an application from any client platform.
  2. All execution happens in the datacenter. Better performance for 3-tier apps.
  3. No wait to begin using the application.
  4. Instantaneous application upgrades.
  5. Use applications over slow connections.
  6. Application stay running as you switch devices.
  7. And so on...

The point here is that a true application delivery solution will be composed of multiple technologies, including SBC, VDI, and streaming. Where one is weak, another is strong. By combining all of these technologies together, you can come up with a solution that will work for all your apps and all your users.

Join the conversation


Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Brian, I think both papers, as well as the article you wrote for TechTarget, provide an excellent overview of the strengths and weaknesses of the various application delivery solutions. I'm in total agreement with you that providing an integrated solution that supports all these techniques is the way of the future (and this is indeed the approach we are pursuing at Ericom Software). I also think it's great that the upcoming BriForum will cover all of them.
At the same time a major factor I mentioned in a response to your previous post, and which you did not touch on in either articles, is cost. Even with an integrated solution which provides both SBC and VDI, the cost of each VDI desktop will be much higher than the cost of an SBC desktop. Since one of the major selling points of SBC is its lower TCO compared to local desktop computing, the higher cost of VDI may become a significant deterrent to its adaptation.
Finally, as I wrote in my blog, I believe that virtualization technology properly applied to SBC can also address items 2, 3 and 5 at a lower than VDI.
I don't understand what cost has to do with it? (In this case.) I'm talking about a blended solution here. There will be some cases where SBC will not work, and where you will need VDI. In those cases, will people think "Oh, VDI is more expensive, so I just won't have a solution for some people?" Of course not! They will use VDI in a limited case when needed, and use streaming and SBC when needed. Just because one element of the complete solution is more expensive than the others doesn't mean it will not or should not be used.

I definitely believe people will use VDI. Indeed some are already using it. All I was saying is that the higher cost of VDI compared to SBC is something which needs to be explicitly discussed ([link=http: Dan
Do you consider blade PCs (ClearCube, HP, etc.) to be part of this space?  If so, then you are shortchanging your readers by not including them in this analysis.
Really, the only difference between VDI and a Blade PC is that one uses a virtual machine to host the image and the other uses a dedicated piece of hardware.
Please give us a complete picture of the virtual client space.
I agree with the reader commenting on the PC/Workstation blades .... in order to get the full picture you should include those as well.
However I want to touch briefly on your article and specifically on the 80% you mentioned. Put like that it appears that, out of 100 organizations, you could turn 80 of them into and SBC deployment using Citrix + Thin Clients and let 20 of them doing other stuff (i.e. standard desktops, VDI etc etc). This is clearly not happening since thin client users are still a very small fraction of the overall standard desktop users. And the reason, in my opinion, for which this is not happening is it is very rare that one could find 100% of the client side stack to be fully compatible with the TS environment. Most of the time what you find out is that you need to leave a desktop on the user's desk and provide core applications via TS/Citrix. Correct me if I am wrong but it is not that common to find many SBC (Citrix) customers using thin clients. Certainly there are a load of them I am sure but I was always told that the ratio of SBC TC users / SCB desktop users is about 20/80. That is: you do not usually distribute the SBC desktop ..... you distribute the applications.
Again this is due to the fact, in my opinion, that you will always find in a desktop sw stack something that is not compatible with the TS/Citrix environment (not to mention the different XP desktop user experience etc etc).
So my take is ... instead of getting into religious battles (certainly not you but this happens) why don't we just try to take these different solutions as complementary rather than alternative ? Certainly if one is in the 20% of those lucky enough to do standard Citrix SBC with thin clients he/she should not even bother about this but how about the other 80% of the users using their desktops and some SBC published applications ? Wouldn't it be better to use consolidated virtual XP clients in the datacenter (perhaps managed through Ardence virtual templates) on top of which you distribute applications via TS/Tarpon/Softgrid etc etc ? So it would be, in my opinion VDI + TS/Citrix ....... not VDI Vs TS/Citrix .........
Of course there will be situations where VDI and TS/Citrix would go head-to-head ... but there can certainly be situations where you would want to take both...... I hear lots of discussions as if TS/Citrix SBC has already taken over the world and everybody is using it by means of Thin Clients. In my opinion this has not happened and while SBC is a great idea we need to acknoweldege that it has taken a "ridicolous" amount of marketshare compared to its potential and to the current desktop deployments.
Pehaps VDI will help to move from "ridicoulous" to "very little".
My 2 cents ... probably less.
Yes of course I include Bladed PCs in my definition of "VDI." That's what I wrote in the paper a few weeks ago, and you'll note that in today's article I didn't mention VMware at all when discussing VDI. So yes, my definition of VDI is anytime you "SBC-ify" an WinXP / Vista desktop, whether that's a blade, VM, or a stack of physical PCs in the datacenter.

Hi Massimo,

I agree with what you're saying. My article meant that within each organization, maybe 80% of the apps can go SBC, and you need technologies like streaming (OS and app), VDI, and traditional desktops to make up the remaining 20%. The whole point of my article is that these technologies should be blended together, and that they do not compete.

Massimo, thanks for a great analysis. I think that the very limited penetration of SBC is something that all of us need to think very hard about. It is an especially poignant issue when compared to the vast penetration that virtualization has achieved in a shorter duration. And, unfortunately, I don't believe VDI will change this. The issue of the limited penetration of SBC and what we can do about it was, in fact, one of the main issues I addressed in my presentation at BriForum Europe 2006. This presentation is also available as a [link=https: Dan
Hi Brian,

For me, there is a missing point in your 5 Points list, which is hardware.
There is a lot of devices you can connect already today to SBC-Solution, but you will always find customers who have special scanners, dongles or whatever, which makes them use Desktop-Solutions.
And VDI does not help in that area, too.


From what I've seen after several years in this space, most customers can migrate 60-70% of their applications to SBC.  80% is high.  However, that isn't the right way to look at this.
To make the decision on SBC as a desktop replacement, you need to identify the proportion of users for whom you can move 100% of their applications to SBC.  Because if you can't move even one application that that group of users needs, then you can't put a thin client on the desk - and there goes most of your value prop.
That percentage is typically quite low within most enterprises.
However I agree with the comment from the IBM guy above about viewing these as complementary.  Because of the low proportion of users who can move their entire image to SBC, from what I've seen there is a small percentage of cases where SBC and VDI (Brian's definition) overlap.  We'll see how that dynamic changes with the upcoming stuff coming out of Citrix in the broker space, but for now the overlap is low.
Sorry for missing that definition Brian.  However, I would caution bundling these two.  While they do both host an XP image, run from a thin client, and can be managed by the same toolset, there are some very significant differences between VMs and Blade PCs/workstations around:
Performance - both price-performance and the ability to deliver consistent pc-like performance
Licensing - especially Microsoft but also applications
Support - both from the vendor and their partners
I've [link=http: Dan

Old article, but i will still respond. My issue is with terminology. Many are confused because Brian, Gartner, or other sources use terms interchangeably or different terms to describe the same thing. We all agree there are pros and cons to each technology, and hybrid approach will probably be the answer. I will submit the following for the community to land on from a terminology standpoint.

SBC (as stated here) and VDI are both "Server-based" Computing models. Streaming is a software delivery mechanism like SMS, ZENWorks, etc. Here is how I break these categories down (keeping in mind some products may include multiple pieces of functionality)

Devices: thin-clients, PCs, PDAs, etc
Application Execution Platforms: BladePC, VDI, Terminal Services, PC
Software Installation: Traditional, Virtual (SoftGrid, Altiris)
Software Delivery: Streaming, File/Share, CD, Push/Pull (example: Leostream, SMS, )