by
Brian Madden
Can you believe that it’s been over five years since we wrote our first article comparing TS-based SBC solutions to workstation-based SBC solutions? Of course in those days we were talking about PC blades in the datacenter rather than VMs, but the idea was the same. (Actually, we could probably go back even further. In 1998 I installed a 32-blade Cubix rack with 386 processors running Windows 95 and PCAnywhere. Each blade had its own modem, and our “connection broker” was the phone switch that routed incoming calls to an open line.)
Anyway, once hardware virtualization became more popular, the blade PC concept morphed into the VDI concept, and blade PCs faded into obscurity. In fact if you mention “blade PC” to most people in our industry, they would probably think, “Why would anyone buy a blade PC? VMs are so much cheaper?”
That said, blade PCs do have some advantages, even in 2009.
The first advantage is that a blade PC is an easy concept to understand. You can go to any CIO and say “blade PC” and he or she will know exactly what you’re talking about. Try doing that with “VDI,” “desktop virtualization,” or “server-hosted desktops.”
And then there’s the fact that in today’s world, a physical desktop (like a blade) can still have a virtual disk that’s mounted on-demand. When blade PCs first came out years ago, you either had to (1) give each blade its own hard drive, and either force users to share images or assign blades-to-users one-to-one, or (2) you had to use expensive SANs that could allow the blades to mount different LUNs on demand.
But today we have things like Citrix Provisioning Server which can integrate with the connection broker to make boot-time decisions about which disk image a device should mount, and we have Windows 7 that can natively boot from a VHD file instead of a full file system.
On top of all of that, though, I think the biggest advantage to blades in today’s world: they’re physical hardware of a known quantity. If you buy 50 blades, then you know you can support 50 concurrent users. No more. No less. Compare that to VDI solutions when everyone’s trying to calculate how many users per core they can get, and of course there’s a user experience curve and the vendors are saying one thing and the consultants are saying another and you really don’t know who to believe or how many servers to buy... You can avoid all of that by going to blades on the back-end instead of VMs.
Sure, it’s possible that your blade solution might be a bit more expensive up front, but there are a lot of people out there who are willing to pay a bit more up front to get a guaranteed known quantity. And if you go with blades, you don’t have to worry a one powerful user taking down another user or one app breaking everyone else.
The bottom line is that I’m not saying you should never use VDI or that blades are always better than VDI. I’m just saying that I used to think blades were crazy in today’s VM-based world, but honestly, I could see several cases where blades make sense over VDI—and not just where you have to use blades, like the 3D graphics apps—I mean where a customer could choose blades or VDI, and they would choose blades.
(Note: You must be logged in to post a comment.)