Sun's flawed utility vision

Now that Sun has booted up its grid offering, it seems like a good moment to explode one or two myths about utility computing. Sun has been trying to get this right for at least a decade now, and everyone (except Sun itself, it seems) can learn from its mistakes.

Its biggest mistake is to believe you can apply an electricity-style utility model to conventional software applications, and it's still making that mistake even now, as Martin LaMonica reveals in this paragraph from his story:

"Though the hardware-based service is still in limited release, Sun is already devising software-related services to go with it. In particular, Sun is building up hosted services for desktop and back-office business applications. It's also seeking partnerships with professional service companies and enterprise resource planning, or ERP, vendors to further develop the offerings."

Let me try and nail this fallacy as succinctly as I can before I lose patience with it. The electricity utility model is a shared infrastructure model. It shares the infrastructure for generating and distributing electricity because currently that's the most cost-effective way of delivering electric power. Grid computing is called utility computing because it corresponds to this model, by sharing raw computing infrastructure.

The applications of electricity are things like heating and lighting. The electricity utility model does not share application infrastructure. The light from your desk lamp isn't coming down a cable from the power station. The applications of electricity are instantiated locally at the point of need. There is no economic model in which it is viable to operate them from a remote location.

Computing is different from electricity in that it is possible to design applications in such a way that much of the underlying application infrastructure can be shared. But that only works if the applications are architected from the ground up for that purpose. Anything based on conventional software packages is just SoSaaS, and as economically clueless as shining a light down a cable.

Unfortunately, the telecoms companies in Sun's customer base who aspire to own and operate utility computing plants are so eager to get into what they see as the lucrative applications business that they overlook these architectural differences. Ten years ago, one of Sun's first customers for its abortive JavaStation network computer was British Telecom. Over the next few years, BT's boffins at its Martlesham Heath research laboratories worked tirelessly to implement a hosted applications model that would allow them to deliver SAP cost-effectively to small businesses using JavaStations. Eventually, they worked out that the only way to achieve this was by implementing a Citrix MetaFrame server at the customer site and serve Windows Terminal emulation sessions to the JavaStations over the LAN. It was hopelessly uneconomic.

BT finally launched the commercial results of these experiments (sans JavaStations by then) in March 1999 as BT BusinessManager, which promised to deliver SAP to SMEs for as little as $200 per user per month. To my knowledge, the sole production customer BT managed to bring online was a 17-employee cargo management business, whose financial controller was the sole user of the system. To this day, I'm sure that remains the only ever recorded single-seat implementation of SAP.

Encouraged by the likes of Sun, Citrix, Microsoft and SAP (yes, all these vendors and more have been guilty of this at one time or another), telecoms companies across the globe have collectively sunk millions of dollars into similarly clueless initiatives, entirely without success. They are wasting their time even thinking about becoming application providers, and I am astonished that, after witnessing so many disastrous failures, Sun still persists in talking as if they should.