Utility Computing vs. Cloud Computing

February 7, 2010

I have spent some time thinking about the functional differences between the terms Utility Computing and Cloud Computing, both as I think they are used today, and as how they could be used to differentiate a different class of service.

I see Utility Computing as a service provider that sells computing instances, computing time slices, networked and “local” storage, computing services (Map Reduce, Key Stores, Message Queue), the network bandwidth needed for this, and ways to reliably target traffic to your site to a single or multiple machines (floating IP address or load balancer).

The way Utility Computing service providers deliver these things to you gives you details about the instances, the volumes, the descriptor names for their network services, but the important point is that you are given a label for a real VM instance on real hardware.  You are tracking something that is essentially a fixed service; an EC2 instance gives us it’s instance ID number (i-12345678), and with that we can reference only this one particular assignment of the physical hardware and Xen VM instance.

To contrast this, a Cloud Computing provider would give you an idealized system, and the actual VM instance or real hardware behind it would forever be abstracted.  You would know you simply have a MySQL database with two 200GB network attached volumes in a RAID 1 configuration, with 32GB of RAM and 20 CPU units, and the Cloud Computer provider gives you a label to the stored concept of this goal, which could presently have an actual instance behind it, or not.  Whether it has a running instance behind the goal, depends on its current configuration state, which could change at any time.  The Cloud Computing provider would ensure that a new instance, of the correct specification, is brought back under the goal, and that in a pool of 20 machines, each can have a several volumes assigned to respective device paths, and when a replacement instance launched, all volumes will be re-attached in their proper place.  The machine’s configuration process is initiated with the knowledge that this machine is part of a pool, and may load only a certain data set (sharding).

I see the difference between having a label for a machine instance, and having a label for the goal of what you want any instances behind that label to perform, and I believe this is the difference between a useful labeling of Utility Computer and Cloud Computing.  I think this underlines my feeling that, at present, Amazon’s EC2 service is a Utility Computing service, and is only starting to become a Cloud Computing service with their new service RDS (Relational Database Service), which allows you to specify a goal for a database system, with its own backup and restore automation, though I haven’t launched one yet to see if this offering still leans more towards Utility or is delivering the Cloud abstraction and management as presently offered.

Presently, if you want Cloud Computing, you have to implement it yourself, or pay someone to help implement it for you so that your computing goals remain functioning even as the underlying hardware has failures, is replaced (perhaps with hardware in a different data center or region) and re-configured so that the goal can be picked up with a new set of hardware, and still serve the same function.  I believe that is the reason Cloud Computing creates so much interest, and it appears to become a foundational pillar of the next wave of computing.