New! Listen to this post in our daily podcast.
I've been getting lots of crap from the commenters on BrianMadden.com accusing me of ignoring Sun's desktop virtualization offerings. And these people have a point. I have been ignoring Sun. I just don't "get" why anyone would use Sun's solution and I haven't had any hands on experience with Sun over the past few years. So let's change that today. In this article, I'll give a quick overview of where Sun is today, and I'll provide an opportunity for everyone who loves Sun to show me what I'm missing.
So bring it on.
What are Sun's VDI offerings today?
From what I can tell, Sun has four products that make up their desktop virtualization offerings:
- The Sun Ray client devices, which are thin client devices. (As of yesterday there's also a software version of the Sun client software.)
- The Sun Ray Software, which is the management server that these Sun Rays connect to.
- Sun VDI Software, which is the whole back-end VDI system that the Sun Rays can connect into.
- Sun Secure Global Desktop, the former New Moon software which allows Sun Ray clients to connect to Windows Terminal Server sessions (among other platforms)
Each of these components is priced and licensed separately.
Here's my biggest problem with Sun:
Yesterday Sun released Version 5 of their Sun Ray Software. I tried to download it to check it out and found this:
In other words, the Sun Ray software only runs on Solaris or Linux. The same is true for their VDI software. And for Secure Global Desktop.
This is a problem because I'm a Windows guy. My desktops are Windows. My servers are Windows. My life is Windows. So even if I could download Solaris or Linux and make it work, I don't really know the first thing about it. I don't know how to secure it. I don't know how to patch it. I don't have confidence that I know how to do it "right."
This is a problem in the context of Windows desktop virtualization because I already have to be an expert in Windows in order to deliver those desktops, so using Sun as my back-end means I have to be an expert in Linux or Solaris in addtion to Windows. Contrast that to running a desktop virtualization solution from VMware/Citrix/Microsoft/Quest/Leostream/Ericom/Symantec/2X/HOB/GeNUIT: In each of those cases, I can run my back-end on Windows.
Sun's desktop virtualization architecture
You start with a Sun Ray client, which can be a thin client device, or, as of yesterday, software that you run on Windows:
One thing I'll give Sun credit for is that their new desktop software installed with no complications on Windows 7. :) Just click setup.exe and you're done! Yay!
So the Sun Ray (software client or device) connects to the Solaris- or Linux-based Sun Ray server, which then could further connect to the Solaris- or Linux-based Sun VDI Server and/or the Solaris- or Linux-based Secure Global Desktop server.
But all these things have separate licenses, and you can easily be up over $200 per user for the whole stack. So why would you use this solution versus something from Citrix or VMware? (Seriously, why would you? This is not rhetoric.)
So I don't know? I mean yeah, this new Sun Ray Software supports USB device redirection and 32-bit color and has good Flash video support... But what's the advantage of this stack? Is it for people who already have an investment in Sun? Is it for people who are educational institutions who get huge discounts? Is it for people who love open source? (i.e. hate Microsoft)
Actually Sun has a video on their website about the top 10 reasons to use Sun VDI software. Unfortunately all the advantages the woman lists in the video are general advantages of VDI and server-based computing. They're not about why Sun's particular flavor of VDI is better than the rest.
So I'm asking you, the community: please educate me about Sun. Have you used their VDI software or Sun Rays? What's good? What's bad? Why did you chose it over the competition?
(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.