Archive for May, 2011

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.

2 Comments

Composing the Open Cloud puzzle

“When it rains, it pours”: This was my first thought while reading the RedHat announcement of yet another cloud project, OpenShift (a new PaaS) and Cloudforms (IaaS). The excellent Stephen O’Grady of RedMonk provided a very complete Q&A covering the announcement and the implications quite well. This is just the last of many, many announcements in the same line, that makes the Open Source cloud environment a very active and crowded one.
-

What exactly was announced? RedHat leveraged its acquisition of Makara, a PaaS vendor with a quite interesting technical solution, and its own Jboss/DeltaCloud platform to create a combination of PaaS and IaaS, designed to facilitate deployment and management of Java, PHP, Python and Ruby applications. It falls in a market that recently saw VMWare’s entry in the market with CloudFoundry, previous entrants like Eucalyptus, OpenNebula, Nimbus, OpenStack and the still unreleased Yahoo IaaS.

It would seem that there is really too much to choose from-but the reality is that each piece does have a place, and the biggest problem in finding this place is that we forget to look at the big picture that is on the puzzle box. The first point is that there is no single market for cloud/IaaS/PaaS/whatever. There are several distinct areas, and for every one there is a potentially different combination:

  • the software (SaaS) producer, that for small scales may be interested in hosting its own small IaaS+PaaS, with the opportunity to move it or dynamically expand outside (on Amazon, for example) when bursts come in. People still think that every company has a full swing of consumption, from very little to galactic scale, while the majority of SaaS producers tend to have a very static set of customers, and acquisitions are slow (compared to procurement time) and easily managed. With a full cloud you pay an extra for scalability – the capability to grow dynamically leap and bounds, and that extra may not be economically justified. Also, many companies already invested in hardware and networking for their own in-house small datacenter, and until the amortment period is ended those companies (for financial and fiscal reasons) would not turn to a full external cloud. So, the next best thing is to create their own little IaaS (for single customer instances), PaaS (for shared customers) on the hardware they already have. The economics here is related to the reduction in management costs, and the opportunity to simplify code deployment.
  • The Telcos: my own sources indicate that lots of telcos are working feverishly to create their own cloud offering, now that there is a potential solution that has no license costs. They could have built it earlier with VMWare or Citrix, but the licensing alone would have placed them out of the market; with the new open source stacks, with a relatively limited investment it is possible to reuse the massive hardware cache already in house to consolidate and offer a IaaS to individual customers, usually mid-to-large companies willing to outsource their varying computational loads outside, or directly dematerialize their server farm. It is mostly a transitional market, that will however be important for at least 5 years from now.
  • The System Integrators: large scale INT and consultancies are pushing a set of integrated offerings that cover everything – technical, management, legal and procurement aspects for companies that are willing to move their IT completely off their backs. It is not a new model – Accenture, Atos Origin et al are doing it since the beginning of time – but thanks to the availability of open source components it does provide a more compelling economics.
  • The small VARs: there is a large number of very small companies, that targets the very low end of the market, and that provide a sort of staircase to the cloud for small and mostly static workloads. It is a market of small consultants, system administrators, and consultancies that cover that part of the market that is largely invisible for larger entities, and that is starting to move towards web apps, hosted email and so on – but still need to manage some legacy system that is currently in-house.
  • The service provider: it just started as a movement, but in my opinion will become quite big: the specialized and cloud-based service (an example is the freshly released Sencha.io). I believe that those specialized providers will be among the most important contributors to the individual OSS components, that are internally used to deliver a service, and will provide a backbone of updates for most of the ancillary parts like storage, DB, identity and so on.

And the obvious question is: who will win? In my view, if every actor works properly, there will be more than a dominant actor. The reason is related to the two main factors of adoption, that is packaging and acceleration. Packaging is the ease of installation, deployment, management and in general user and developer-friendliness of the whole. So, taking for granted that RedHat will open source it (as it did with all the previous acquisitions) the main advantage for OpenShift and CloudForms will be ease of installation for RedHat and clone users – that are still the majority of enterprise Linux deployments. It will be natural for a RHEL user to start converting some servers into a RedHat IaaS and PaaS, given the fact that systems will also fall under a simplified management through RHT Satellites; the main interest in this case will be for system integrators and developers that already standardized under RedHat. A potential future enhancement could be the push towards a better identity management (a sore point for most IaaS, with the exception of the Grid-inspired Nimbus): RedHat does have a good Java-based provisioning and identity server in-house, that can probably be expanded with external tools like ForgeRock’s OpenIM/OpenIDM. The first one that will solve the “cloud identity” problem will actually have a gold mine in its hands.

OpenStack is more relevant for bare-metal installs, and will probably get the majority of new, unbranded installs thanks to its massive acceleration – the incredible rate of change that is clearly visible by the amount of new features delivered in any release. The combination of OpenStack and CloudFoundry is probably of interest mainly for large companies that want to create an internal development environment (reducing developer friction) – in this sense, I believe that the market for secondary services will be probably limited, but with a substantial contribution from “independents” that improve the platform to facilitate their own internal jobs.

The end result is that we will still see several competing platforms, each evolving to occupy a niche and taking (and giving) pieces of code to the others. The obvious result will be the pressure on proprietary vendors, that in my opinion will have a very hard time to keep the same development pace of these collaboratively developed solutions.

, , , ,

No Comments