by
Gabe Knuth
Lately, I've been looking into browser desktops to see if they qualify as a type of VDI. For those that aren't aware, browser desktops (BD's) are relatively lightweight desktop environments that execute in your local machine's internet browser. They're typically sourced from a cloud-based infrastructure, be it home grown or from a "traditional" cloud like Amazon EC2. The BD itself could be considered an operating system, but I think it's more appropriate to separate it from a typical OS, which interfaces with the hardware on the client device. Instead, a BD interfaces only with the software running on the OS, using the browser as an abstraction layer between the normal operating systems like Windows, OS X, or Linux, and the browser desktop itself.
Several browser desktops exist today, and I'm sure there are many that I've missed or that are in the works right now. Each is similar in presentation, although some use apps built into the BD itself while others use cloud-based apps like Google Apps. Files are stored server-side, as is the user environment, so that the look & feel is the same from wherever a user logs in. Lets take a quick look at who is out there (with obvious apologies to those I've missed). All three of these organizations have free products to try.
G.ho.st (pronounced Ghost, but written that way because that's also the web address) is one of the most recognizable names in browser desktops. The G.ho.st environment is an edgy looking, Windows-like interface right down to the "Go" menu where a Start menu should be. G.ho.st consists of a 2MB Flash/JavaScript package that runs in any browser that supports those technologies (which is to say "everywhere"). Applications (and there are many) are cloud-based apps like Google Apps, Zoho, or Zimbra that run in iFrames to give the appearance of running in their own windows. There is also an HTML-only version that runs on mobile phones and gives you access to your documents as well as the various cloud-based apps.
G.ho.st is currently consumer-oriented, but is considering modifications to make themselves more viable in a business scenario.
iCloud is based on a web service called the Xcerion Internet Operating System /3 (XIOS/3), which is based on Ubuntu Linux. What is interesting about iCloud is that if it is started while online, it can be used offline because the applications execute from within the BD. An offline browser desktop is intrguing, but it's not ready for prime time unless you can pre-cache it and start the desktop while offline. Still, it appears that iCloud has a definite enterprise focus.
At this time, iCloud only supports IE fully and is in alpha for Firefox, so if you're going to check it out, make sure you use IE. It feels a little clumsy in Firefox.
eyeos is an open-source browser desktop with a host of "local" applications (in that they run natively in eyeos and not from a cloud). I thought this might mean that they would work offline similar to iCloud, but that's not the case. It appears the applications and other components are sent down to the client on demand. eyeos has the distinction of being the only BD that allows the server to be installed in your enterprise and accessed without touching the internet.
So what's the big deal?
Proponents will say that the browser desktop is the reinvention of the desktop--the way it would be done if you were building a user environment from the ground up today. Riding the wave of "The Cloud," it's easy to get caught up in the hype, and there are some interesting benefits to a BD, such as the server-side user environment and ubiquitous access to the lightweight desktop. Since everything runs on the client side, there are no remote protocols to worry about. Even the web apps like Google Apps are mostly code that is executed in the browser and not on the server. YouTube videos, for instance, aren't remoted down from a centralized location. Instead, the BD that's executing in your browser is just wrapping around another instance of your browser that is going to YouTube.com.
Opponents argue that it might be all right for task users, but it's not a valid replacement for VDI scenarios since those are typically more hardcore users that require hardcore applications instead of web-based ones. SBC users might be more adaptable to a browser desktop, but the interface is to unfamiliar, the apps aren't the same, and the integration with the rest of their enterprise systems isn't there.
Who's right?
Beats me! I think right now, regardless of any of the claims of network bandwidth reduction and latency tolerance, there's not much of a place for a browser desktop in an enterprise. My take is that there needs to be some serious integration into enterprise systems before they can gain any traction. The issue is that companies have invested millions and millions of dollars (or hundreds of euros) into their systems, and they're not going to be willing to take their systems and modify them to work with a browser desktop when they have a solution that works well today. While an increasing number of applications are becoming web-oriented, there are still plenty of applications and systems, not to mention file shares and collaboration systems that don't work (or don't work as well) via the web.
So, in order to be useful in an enterprise, browser desktops need, among other things:
- LDAP integration - some have this, at least experimentally
- Access to file shares - SMB for sure, others as needed
- Some way of connecting to those non-web apps - If we all put our heads together, we can probably come up with something :)
- Security - most organizations aren't going to want to send their files over the net to web apps and back, so something super-secure has to be created and vetted out thoroughly before people will begin to accept a BD as a possibility. eyeos is ahead of the pack here, with an option to install the server side directly into your data center.
Some folks will argue that offloading all the processing back to the client is counter-intuitive to the whole VDI approach, and in some ways that might be true. Thing is, some solutions for remote protocol issues already offload some things to the client side, requiring clients to be more powerful. I suppose that will always be the case, though. My fear here is the increased amount of client administration as more things are offloaded to the end point. The goal of VDI/SBC is to centralize almost everything and offload only what is needed. The current BD is the other way around--centralize the easy stuff, but leave the heavy lifting to the client.
We're sure to see more browser desktops pop up in the coming
months/years. Google
Chrome OS has a different delivery mechanism than the BD's above,
but shares a similar goal. Adobe AIR is gaining popularity as an app
that can turn web services into desktop applications (like TweetDeck). And Mozilla's Prism project promises to "split web
applications out of their browser and run them directly on their
desktop." While these might not be presented in a desktop browser interface, it
could be argued that they're in the same vein as BD's. After all, they
are still aiming to provide applications in a native-looking manner.
In the end, even with a well-integrated solution from the browser desktop makers, the decision that has to be made is this:
Your users don't know one "cloud" or desktop from another. Are you comfortable with that desktop coming from "The Cloud", or do you want to own that cloud?
I'm not saying it won't ever work. I'm just saying don't cancel your VDI pilots.
(Note: You must be logged in to post a comment.)