The upcoming cloud storm, or ChromeOS revisited

The latest IO2011 conference from Google marked the first real marketable appearance of several noteworthy additions: Angry Birds for the web, a new Android release and the latest netbooks based on ChromeOS. The most common reaction was of basic lack of interest from analysts and journalists, with the prevalent mood being “we already saw what netbooks are, and we don’t like them” or “you can do the same with Windows, just remove everything and leave Chrome on it”.
Coming this Way!

Well, I believe that they are wrong. ChromeOS netbooks may be a failure, but the basic model is sound and there are strong economic reasons behind Google push in the enterprise. Yes- I said enterprise, because ChromeOS is a pure enterprise play, something that I already wrote about here. I would like to point out a few specific reasons I believe that ChromeOS, in some form or the other, will probably appear as a strong enterprise contender:

  • It is *not* a thin client. Several commentators argued that a ChromeOS netbook is essentially a rehash of some old thin client of sort, with most people presenting a parallel between ChromeOS and Sun Ray clients. But ChromeOS is designed to execute web applications, where the computational cost of the presentation and interaction layer is on the client; this means that the cost per user for providing the service is one order of magnitude lower than bitmap-based remotization approaches. How many servers would be necessary to support half a billion Facebook users if their app was not web based, but accessed through an ICA or RDP layer? The advantages are so overwhelming that nowadays most new enterprise apps are exclusively web-based (even if hosted on local premises).
  • It is designed to reduce maintenance costs. The use of the Google synchronization features and identity services allows for management-as-a-service to be introduced fairly easily; most thin clients infrastructures require a local server to act as a master for the individual client groups, and this adds costs and complexities. The extremely simple approach used to provide replication and management is also easy to grasp and extremely scalable; provisioning (from opening the box to begin useful work) is fast and requires no external support – only an internet connection and a login. This form of self-service provisioning, despite brochure claims, is still unavailable for most thin client infrastructures, and when available it is extremely costly in terms of licensing.
  • Updates are really failsafe. Ed Bott commented that “Automatic updates are a nightmare”, and it’s clear that he has quite a deep experience with the approach used by Microsoft. It is true that automatic updates are not a new thing – but the approach used by ChromeOS is totally different from the one used by MS, Apple or most Linux distributions. ChromeOS updates are distributed like satellite set-top box updates – whole, integrated new images sent through a central management service. The build process ensures that things work, because if something happens during the build the image will simply not be built – and distributed. Companies scared by the latest service pack roulette (will it run? will it stop in the middle, making half of the machines left broken in the rain?) should be happy to embrace a model where only working updates are distributed. And, just as a comment, this model is possible only because the components (with the exception of Flas) are all open source, and thus rebuildable. To those that still doubt that such a model can work, I suggest a simple experiment: go to the chromiumos developer wiki, download the source and try a full build. It is quite an instructive process.
  • The Citrix receiver thing is a temporary stopgap. If there is a thing that confused the waters in the past, it was the presentation done by Citrix of the integrated Receiver for the ICA protocol. It helped to create the misconception that ChromeOS is a thin-client operating system, and framed in a wrong way the expectations of users. The reality is that Google is pushing for a totally in-browser, HTML5 app world; ICA, RDP and other remotization features are there only to support those “legacy” app that are not HTML5 enabled. Only when the absolute majority of apps are web based the economics of ChromeOS makes sense.

On the other hand, it is clear that there are still substantial hurdles- actually, Google approach with the Chromebooks may even fail. In fact, I am not a big fan of the notebook format for enterprise computing, where a substantial percentage of users are still on the desk, and not nomadic. I believe that having a small, very low cost device is more interesting than leasing notebooks, especially if it is possible to lower the cost of the individual box to something like 100$ (yes – believe me, it is actually possible). Also, Google must make it easier to try ChromeOS on traditional PCs, something that at the moment is totally impossible; a more generic image, executed from a USB key, would go a long way towards demonstrating the usefulness of the approach.

  1. #1 by Adam - May 30th, 2011 at 13:53

    There’s another solution for accessing Wndows apps from Chromebooks. Ericom AccessNow is a pure HTML5 RDP client that enables Chromebook/ChromeOS users to connect to any RDP host, including Terminal Server (RDS Session Host), physical desktops or VDI virtual desktops – and run their applications and desktops in a browser.

    This means that you can use AccessNow for instant, turnkey web-enablement of most any Windows application. Running entirely within a browser, AccessNow works natively with Chrome, Safari, Internet Explorer (with Chrome Frame plug-in), Firefox and any other browser with HTML5 and WebSockets support.

    Ericom‘s AccessNow significantly reduces IT overhead in key ways:
    1. It does not require Java, Flash, Silverlight, ActiveX, or any other underlying technology to be installed on end-user devices
    2. IT staff do not have to manage / maintain separate product versions and updates for multiple clients (end-point operating systems) – an HTML5 browser is all that is required

    For more info, and to download the beta of Ericom AccessNow please visit:

    For a video demo:

(will not be published)