Blog Post

How Cloud & Utility Computing Are Different

Written by Geva Perry, chief marketing officer at GigaSpace Technologies.

We are witnessing a seismic shift in information technology — the kind that comes around every decade or so. It is so massive that it affects not only business models, but the underlying architecture of how we develop, deploy, run and deliver applications. This shift has given a new relevance to ideas such as cloud computing and utility computing. Not surprisingly, these two different ideas are often lumped together.

What is Utility Computing?

While utility computing often requires a cloud-like infrastructure, its focus is on the business model on which providing the computing services are based. Simply put, a utility computing service is one in which customers receive computing resources from a service provider (hardware and/or software) and “pay by the drink,” much as you do for your electric service at home – an analogy that Nicholas Carr discusses extensively in “The Big Switch.”

Amazon Web Services (AWS), despite a recent outage, is the current poster child for this model as it provides a variety of services, among them the Elastic Compute Cloud (EC2), in which customers pay for compute resources by the hour, and Simple Storage Service (S3), for which customers pay based on storage capacity. Other utility services include Sun’s, EMC’s recently launched storage cloud service, and those offered by startups such as Joyent and Mosso.

The main benefit of utility computing is better economics. Corporate data centers are notoriously underutilized, with resources such as servers often idle 85 percent of the time. This is due to overprovisioning — buying more hardware than is needed on average in order to handle peaks (such as the opening of the Wall Street trading day or the holiday shopping season), to handle expected future loads and to prepare for unanticipated surges in demand. Utility computing allows companies to only pay for the computing resources they need, when they need them.

What is Cloud Computing?

Cloud computing is a broader concept than utility computing and relates to the underlying architecture in which the services are designed. It may be applied equally to utility services and internal corporate data centers, as George Gilder reported in a story for Wired Magazine titled The Information Factories. Wall Street firms have been implementing internal clouds for years. They call it “grid computing,” but the concepts are the same.

Although it is difficult to come up with a precise and comprehensive definition of cloud computing, at the heart of it is the idea that applications run somewhere on the “cloud” (whether an internal corporate network or the public Internet) – we don’t know or care where. But as end users, that’s not big news: We’ve been using web applications for years without any concern as to where the applications actually run.

The big news is for application developers and IT operations. Done right, cloud computing allows them to develop, deploy and run applications that can easily grow capacity (scalability), work fast (performance), and never — or at least rarely — fail (reliability), all without any concern as to the nature and location of the underlying infrastructure.

Taken to the next step, this implies that cloud computing infrastructures, and specifically their middleware and application platforms, should ideally have these characteristics:

  • Self-healing: In case of failure, there will be a hot backup instance of the application ready to take over without disruption (known as failover). It also means that when I set a policy that says everything should always have a backup, when such a fail occurs and my backup becomes the primary, the system launches a new backup, maintaining my reliability policies.
  • SLA-driven: The system is dynamically managed by service-level agreements that define policies such as how quickly responses to requests need to be delivered. If the system is experiencing peaks in load, it will create additional instances of the application on more servers in order to comply with the committed service levels — even at the expense of a low-priority application.
  • Multi-tenancy: The system is built in a way that allows several customers to share infrastructure, without the customers being aware of it and without compromising the privacy and security of each customer’s data.
  • Service-oriented: The system allows composing applications out of discrete services that are loosely coupled (independent of each other). Changes to or failure of one service will not disrupt other services. It also means I can re-use services.
  • Virtualized: Applications are decoupled from the underlying hardware. Multiple applications can run on one computer (virtualization a la VMWare) or multiple computers can be used to run one application (grid computing).
  • Linearly Scalable: Perhaps the biggest challenge. The system will be predictable and efficient in growing the application. If one server can process 1,000 transactions per second, two servers should be able to process 2,000 transactions per second, and so forth.
  • Data, Data, Data: The key to many of these aspects is management of the data: its distribution, partitioning, security and synchronization. New technologies, such as Amazon’s SimpleDB, are part of the answer, not large-scale relational databases. And don’t let the name fool you. As my colleague Nati Shalom rightfully proclaims, SimpleDB is not really a database. Another approach that is gaining momentum is in-memory data grids.

One thing is certain: The way the industry has traditionally built software applications just won’t cut it on the cloud. That’s why companies such as Google, Amazon and eBay have developed their own infrastructure software, opting not to rely on products from the large middleware vendors such as Oracle and BEA, who designed them with a very different approach in mind.

For this reason, we are seeing the emergence of a new generation of application platform vendors. These vendors, which include my own company, GigaSpaces, are building software platforms made for the cloud from the ground up: “cloudware,” if you will.

So although they are often lumped together, the differences between utility computing and cloud computing are crucial. Utility computing relates to the business model in which application infrastructure resources — hardware and/or software — are delivered. While cloud computing relates to the way we design, build, deploy and run applications that operate in an a virtualized environment, sharing resources and boasting the ability to dynamically grow, shrink and self-heal.

63 Responses to “How Cloud & Utility Computing Are Different”

  1. Hi,

    I’m doing a second phase architecture in cloud computing with multi phase SAAS platform with various other components such as service management, CRM, directory, hosting of applications from clients, open source in the cloud, custom integrations etc. The over all goal is to provide business users to minimize their initial investments and cut down their running expenses. Currently tcc247 has a client base of 600 hot customers. Our initial goal is to convert all the existing customers to cloud users and give them the fruitfulness of the cloudy SAAS environment. Our enthusiastic development team, aggressively working on adding new applications and adding new features to existing applications. httpgain itself has a common interface for customer management and sales. In year 2010, it is assumed that a full cloud will be implemented with no time facilitation delivered.

    Comment: I’m working as Chief Architect for the HTTPGAIN Cloud Platform. Happy to communicate with those with similar interests.
    More on tcc247 please watch :

    Najeem M Illyas

  2. Eric Stahl

    Here are my two cents…

    There are packaged apps that run in the cloud (, Workday, Siebel On Demand) and there are platforms for building and running custom apps in the cloud (Amazon Web services, Google App Engine and

    All of them run remotely, are elastic and are metered some way (by # of users, CPU, storage, bandwidth, page views, etc.)

    Each comes at it from a different angle and is optimized for different use cases.


    Full disclosure: I work for

  3. Interesting correlation drawn between Utility and Cloud Computing. My cloud company, has offered cloud storage since day one, and offers many other cloud computing services as a Data Rich company. indexes in real time, and stores for long term review of usage analytics and usage data including latency trends, predictive necessity or pre-load planning feed aggregators.

    Currently is building a network of partners in the Enterprise SaaS industry. Please visit for more information on many of the core products and services offered. Including: User Interface as a Service, Data Feeds asa Service for MashUp Enterprise Apps and Gadgets.

    [email protected]

  4. Scott D

    My two cents…
    Utility Computing – buying your application services from a third party hosted vendor. App on demand via the web. Pay as you use services.

    Grid Computing – ability to utilize multiple systems to in effect calculate and process information. Think BOINC and how they utilize global systems at off peak hours. Utilizing un-used processing time from other systems collectively. Utilizing un-used processing time from other systems collectively. Or connecting a lot of low cost computers and using the “power” of those low cost systems collectively.

    Cloud computing – who has the most money to host the bigger datacenter with redundancy built into the architecture and servers. Apps still need customized to take advantage of fail over else you have done nothing more than dress up a standard fail over model and 5 nines of service. A nice investment in an ISP hosted DC, VM solution and the ability to dynamically manage and move the system data around without impacting down time or performance to the customer..Again nothing new to infrastructure people who have utilized MPLS and VPN backup architectures to deliver 5 nines of up time, but those app guys are still struggling to make it work.

    Personally, I think Cloud computing is a new wrapper on an old architecture. Just sounds cool doesnt it.

  5. First of all: Congratulations. This really is a great Guest Column! Well structured, sophisticated and still coherent and intelligible. Back to the topic, that means I´d like to bring some clearness into the discussion, although Geva explained it already: While speaking of Cloud and Utility Computing we mean that the Grid Computing services are outsourced to external operating companies. Utility Computing discribes more the Service and the Business Model of actuating the storage and processing of datas. The term “Cloud Computing” is located on a higher level of abstraction and describes the concept and the idea of outsourcing this services.
    Kind Regards

  6. Its meaning depends on an individual’s view. I mean that the view as you see a cloud in the sky. Under the same sky, you see different shapes of the cloud. Also read “AARON WEISS: COMPUTING IN THE CLOUDS”.

    So IBM’s, Amazon’s, Google’s, Sun’s, HP’s, Oracle’s, your, and even my clouds are different. But we need a way to integrate these clouds together.

    Boomary… [email protected] (a former Sun guy)

  7. Hina Khalid

    James Urquhart & Geva

    is it so that” cloud is definitely NOT a job scheduling and execution platform”. isnt cloud suppose to these tasks as well .the terms of grid and cloud are quite confusing, to me it seem as if cloud is some sort of commercial version of grid , if both concepts are same then why to coin a new term for it

  8. Geva,

    Just for fun, let me counter your argument that cloud computing and grid computing are one and the same–at least without qualification. “Grid computing” means infrastructure for “high performance computing” for many (see, and the cloud is definitely NOT a job scheduling and execution platform.

    That being said, I also think the definition of cloud computing is broader than you state. I wrote about this today, but the short-short version is I believe cloud computing is a systems architecture with certain properties focused on service and data deployment and ownership. In truth, though, it is just a little more broad than your definition, and doesn’t dent anything that you said about software architectures.

    Now, do I think cloud computing is synonymous with getting your computing services from an “electric grid”-like infrastructure? Oh, yeah.

  9. Gridiron

    James Urquhart links to a post by Paul Wallis about Cloud Computing. I think it is a good article.

    Wallis makes a great point about the economics of processor usage. If I read him right (between the lines), until technology gets better “the Cloud” might work for small businesses and individuals, but big business will think its too expensive and too risky.

  10. @Alex — As I actually wrote in my post, I agree that “grid” and cloud” are pretty much synonymous. Here’s a little bit from my Parting the Clouds post on my personal blog –

    “BTW, in my mind “cloud computing” is merely a refresh on “grid computing”. Grid is simply an older term that to many people had certain connotations to it, such as being related to the scientific and academic community. It’s a bit like SaaS being a refresh of the older term Application Service Provider (ASP), which was tainted because so many investors lost money on ASPs during the dot-com bust. See my post Tower of Babel – – for more on this phenomenon.”

  11. Giva, You’ve tackled a truly knarly semantic tangle in trying to differentiate utility computing from cloud computing.

    I’m not convinced, however, that the term “cloud computing” isn’t a repackaging of grid computing and utility computing, however, even if the context is vastly improved network architectures and virtualized data centers. Your point regarding the development of new infrastructure software by Google, Amazon and eBay is well-made, as each company positions itself to serve vast amounts of information to any connected device.

    Our definition for cloud computing comes closer to a precise definition for the term than most out there, though it comes with the cavaet that as with any evolving technology there will necessarily be differences of opinion over specific implementations, as you note in your post.

    Wikipedia’s current entry for cloud computing defaults to utility computing, in fact, which delivers one (large) Web community’s consensus on the confluence of the terms.

    I agree with you that utility computing is a model, not a technology. We define it as “a service provisioning model in which a service provider makes computing resources and infrastructure management available to the customer as needed, and charges them for specific usage rather than a flat rate.”

    Grid computing, the more relevant comparison, is a technology, and a long-standing one. We define is as “applying the resources of many computers in a network to a single problem at the same time – usually to a scientific or technical problem that requires a great number of computer processing cycles or access to large amounts of data.” To my ears, that’s remarkably similar to cloud computing.

    Other key differentiators you cite virtualization, self-healing and SLA-driven architectures. While these technologies have been developed and matured in recent years, do they depart sufficiently from the grid computing architectures of the past to drive a genuine difference?

    A post from a fellow editor, Margaret Rouse, explaning computing in a cloud, where she puts the technology in the context of its technological forefathers, makes me wonder.

    All that being said, your list of characteristics is thoughtful, useful and intriguing. Thanks for a great read!


  12. @HK — I am afraid these concepts are a bit too abstract to have a diagram. As I said, they are also apples & oranges. Utility computing is a business model, while cloud computing is an architecture. For the latter, therefore, there are some diagrams – depending on which of the elements I spoke of you want to demonstrate. You can find many of the scattered throughout Nati’s site at and and on the GigaSpaces wiki, such as here:

  13. @Sodl – I would answer you if I understood what you are saying. Are you saying the concept of “utility computing” is bull? If so, not sure I understand your reasoning, but in any case, your pretty much alone on that one…

  14. This concept , in my opinion , is bull! Pardon me pretty please..
    If you are comparing utility with computing then answer me this….

    Is the application you are running == the iron connected to the outlet?
    Is the outlet your iron is connected to == the computing power (memory,cpu etc)

    Now you dont have to tweak your iron and reset its little microprocessor (if any) often … do you?

    However software is not a iron to press your pants

  15. Great post. I also see a lot of confusion between apps-on-tap (where there’s no login, but the semblance of a programming language) and computing-on-demand, like S3. It’s still a source of a great deal of confusion, particularly with services like Coghead, Intuit’s Quickbase, and’s Apex language sitting somewhere in the middle.

  16. As non-technical person, but one who needs to approve IT budgets and development plans, your article was informative. It has provided me with a business level checklist and a clear and high-level linkage between technical design choices and business implications/customer experience.

    Great job.

  17. Harry Quackenboss


    Thanks for your thought-provoking article.

    I am struggling with your definition of utility computing. It’s a lot narrower than the definition first used in the 1960s about computer utilities and accessible computing (

    Consumers don’t think of utility electricity as a business model, they think of it as a service. Electricity can be acquired on a metered, flat rate, or free (meaning it is bundled with something else such as your rent or your tax bill) basis.

    But using your definition of utility computing to assert that cloud computing is a broader concept is like claiming that hydroelectric power plants are a broader concept than utility electricity.

  18. @Bert Armijo — First, I think 3Tera is great and on the cutting-edge. I don’t think I was being over-simplistic, I was consciously trying to simplify. Or rather, trying to more clearly define terms that are used as interchangeable. So I am distinguishing between the business model of renting resources by usage (as in the electric utility), and the underlying architecture/deployment/provisioning model, which I call cloud/grid. Sure, it would be almost unthinkable to run a utility service without an underlying cloud/grid architecture. But the opposite is not true. Not all clouds/grids operate in a utility model (according to my definition). For example, many of our customers have internal clouds/grids.

    I think we are arguing semantics with your example of self-healing. I just don’t call that utility. I call that cloud/grid (done right).

  19. Geva,

    Probably I didn’t put it right. When I said software, I meant software for the underlying architecture. In fact, I agree with your differentiation. I have been waiting to write a post like this because many people use both these terms loosely.

  20. Geva,

    You’ve written an interesting attempt to clarify a subject that’s confusing many people at the moment and I think that much of what you’ve written about cloud computing is quite interesting. However, I’m afraid your definition of utility is overly simplistic. Utility computing, beyond the economic model, is a set of technologies that make it possible to package computing resources for consumption in a utility fashion. More to the topic though, utility computing is a critical technology for developing cloud computing to the level you describe.

    As an example, without utility computing, if you were asked to deploy an instance of your system across a few hundred servers in Europe tomorrow you’d be hard pressed to accomplish the task. The long accepted method of deploying distributed systems accross servers, software, network, storage and security is simply too labor intensive. Utility computing replaces that labor with technology, so that whether you’re deploying to 1 server or 1,000, the process is exactly the same. Fortunately though, now that there are providers in Europe building utility services today (many on 3tera’s own AppLogic), the task of setting up a 100 server application is trivial.

    Looking beyond mere deployment, I believe there is an even more symbiotic link between cloud and utility computing. Consider for a moment one of your defining characteristics of cloud computing; self-healing. How, precisely, will your cloud middleware layer obtain the extra hardware resources? Will an operator be required to add a node? That would hardly be economical or expeditious. No, the system must be able to provision that node itself which leads to the question of whether that intelligence must be built into your system? Will all clouds be required to do so? That hardly seems practical either. No, just as all applications that run atop Windows utilize device drivers provided for windows to access hardware, cloud systems will utilize utility computing to access their hardware – even if that hardware resides across the globe.

  21. @Krish — Perhaps it’s a nuance, but again, I would say that SaaS is really a “business model” rather than a technology. Essentially, a software subscription model and delivery over the Web (or some other network).

    Software can also be delivered in a utility model – that’s exactly what Amazon is doing with things like SimpleDB and my company, GigaSpaces, also provides the option of getting our software in a utility model on EC2.

    Cloud computing is more of an architecture in my mind.

    I wouldn’t nitpick normally, but I think part of the point of this exercise is to start agreeing on some common terminology in the industry.

  22. Matt – thanks for your comment. I did not mean to suggest that relational databases are going away. RDBMSs are great for very complex querying of very large sets of data, durability of long-lived data, etc. However, I definitely do see relational databases significantly changing (diminishing) their role — and especially in clouds and other distributed environments. I’ll refer you again to my friend Nati’s post: Putting the Database Where it Belongs ( It refers to great links about this topic from none other than Michael Stonebraker, Pat Helland and others. Also, I suggest reading this from Vivek Randive, Tibco CEO/Founder: Here’s a taste: “There has been really very little innovation because in the last 20 years we’ve been locked into extortionist database architecture. The mother of all databases, the relational database, is at the center of everything, which is why prices of databases have stayed the same.”

  23. In your post you say, “New technologies, such as Amazon’s SimpleDB, are part of the answer, not large-scale relational databases.” I would argue that large-scale relational databases as they are implemented today are not the answer. We have yet to fully dive into Codd’s true meaning of relational database and concepts such as those expressed in “The Third Manifesto” have yet to see true daylight. Granted implementation of a clustered D relation database is not for the faint of heart but writing off relational databases for cloud computing seems a little eager. I think we’ll see a renaissance of relational databases as a result of cloud computing. In the same breath I agree that a relational approach is not always necessary for a successful cloud application. Databases (or data stores is you will) like CouchDB and GigaSpaces can sometimes fulfill the need better. I just don’t want to write off relational databases because of currently poor implementations.