Picked up this post about how cloud and utility computing are different. Thanks to James Urquhart for the link.
From the comments, I saw that SaaS has got dragged into the conversation. So, for the sake of clarity, I thought I'd expand on my post which included some of definitions that I often use.
Software as a Service is "a software application delivery model where a software vendor develops a web-native software application and hosts and operates the application for use by its customers over the Internet". It's a delivery model, as much as bespoke and stand-alone products are.
Utility computing covers "the packaging of computing resources, such as computation and storage, as a metered service similar to a physical public utility, This system has the advantage of a low or no initial cost to acquire hardware; instead, computational resources are essentially rented". Essentially it is a billing and commodity provisioning model, though the field of study does also cover the concept of large scale utility providers (hence there is a natural overlap with volume operations and SaaS).
Cloud computing covers the concept of computing resources being provided by a mesh of external devices and grids as opposed to a single identifiable device. It's a fairly ephemeral term, just like clouds. When considering the infrastructure for provision of computing resources, I happen to prefer the concepts of distinct computing grids, whether those are provided by specific companies or through P2P infrastructure.
Virtualisation is simply a "technique for hiding the physical characteristics of computing resources from the way in which other systems, applications, or end users interact with those resources". Such techniques are often used to create computing grids.
So "software as a service" can be provided on a "utility computing" basis and the underlying infrastructure can be provided by a "computing grid" which can be built using "virtualisation". It doesn't have to be that way, but it can.
The "software as service" provided could be an application (like Salesforce.com) or a development framework (like Bungeelabs) or an operating environment (often called 'hardware as a service' like Amazon's EC2).
Furthermore, an application can be built upon a framework which can be built upon an operating environment. So you can have a "stack" of "software as a service".
It is worth noting that not all services in the stack need to be provided in the same way.
A Competitive Utility Computing Market is "an ecosystem of utility 'software as a service' providers where there is portability between one service provider and another". In the case of an application, such as CRM, there would be several SaaS providers of that application with portability between them. Such a market is analogous to the electricity market. It should be noted that portability, in this case, is not simply a matter of switching services and open standards, as consumers are not infrastructurally neutral and have a data relationship with their supplier.
It is also worth noting that each level of the stack from application, framework to operating environments, could be provided by a computing grid or a competitive utility computing market.
Those are the terms that I find useful. These concepts were behind my talk at OSCON and the Zimki product (a JavaScript development framework provided on a utility basis as SaaS through a computing grid which included all the components of portability necessary for creating a competitive utility computing market).
James Urquhart is promising to write more on this subject, so if you haven't already read his blog .... keep an eye out for his posting.
One last thing,
- "computing grids" (an architectural method of providing infrastructure)
- "virtualisaion"(a technique for abstracting the physical location of computing resources)
- "software as a service" (a delivery mechanism)
- "utility computing" (a billing and provisioning mechanism)
... are different things.
As for "clouds", they are wispy formations of water vapour and some other ephemeral gathering of computing resources which sort of maybe, somehow, isn't quite ... nah ... slipped through my fingers again.
Nick Carr wrote a book on the subject, ask him.
[Update: James has posted a workable definition of cloud computing. The cloud gets a little less 'wispy']
