Three Criteria for Being a Cloud Service

By George Reese
December 8, 2008 | Comments: 22

The expression "cloud computing" is confusing a lot of people.

It means different things to many of the people who understand it, and those who do not understand it are having a hard time grasping what exactly it means. And then you get commentary that suggests it means nothing at all.

Cloud computing is a critical advancement in IT infrastructure. People talk about cloud computing because it means something to them; it's simply too new for all of us to have developed shared reference points that make each of us say, "A-ha! That is cloud computing."

Here are the three criteria I have for determining whether something is a cloud service or not:


  1. The service is accessible via a web browser (non-proprietary) or web services API.

  2. There is zero capital expenditure required to get started.

  3. You pay only for what you use as you use it.

The third criterion also implies that there is no ongoing commitment to the service once you are bored with it.

You may agree or disagree with those criteria. When I talk about cloud computing, that's what I mean.

I have chosen those three criteria because I think they capture the essence of what excites people about cloud services as opposed to other kinds of technology services.

What diverse service options qualify under these criteria?

  • Amazon Web Services
  • SalesForce.com
  • LinkedIn
  • Google Apps/AdWords/Website Optimzer/*

When one person is talking about LinkedIn and another about Amazon Web Services, it can often seem that perhaps one party does not know what they are talking about or they are talking about two separate things. In these cases, however, most people are excited about the idea that they can just sign up and begin using the service using open web protocols. That's it. No IT investment, no long-term commitment, no risk at trying it out.


You might also be interested in:

22 Comments

George,

Thx.. I like you simple and easy definition.. I'm gonna use it in my explanations.

I believe your 3 criteria are a good start, however they are based on a limited reference point. If you are looking just from a industry user's point of view when looking to buy services, then sure, I guess your criteria work. However in reality cloud computing can be so much more. What about creating your own cloud resource or cyberinfrastructure, such as with Eucalyptis? What about a cloud service that is free, and you aren't paying for it? This is true typically in large national-scale academic/research deployments where researchers are simply given resources (see Teragrid). Also, Google App Engine is free (to a certian capped point) and in many ways could be considered a cloud. It meets your first two definitions very well, but it is needlessly limited by the third.

This is why defining cloud computing is so hard. There are many factors from many different points of view that need to be considered when defining Cloud computing. The only way to do this is to create a abstract and pure definition, however doing so will severely diminish the value and impact of the definition itself. So is it worth defining at all?

I certainly don't claim I have answered this question forever and everyone can move on with something else to do. But if you feel I have missed the mark, how so?

What things have I failed to include in the concept of "cloud service" that you would like considered a "cloud service"? Why should those things be considered cloud services? What is interesting about them that ties them to the other things you call a cloud service that is meaningfully distinct from the things that are not cloud services?

What things have I included in the concept of cloud service that you feel don't really fit the bill? Why are those things different?

You provided several examples, but I am not understanding the rationale behind them.

Eucalyptis and other tools that allow you to create your own virtualized infrastructure based on the EC2 API. That's not a cloud in any meaningful way that I can see, nor is the virtualized results. It's just private virtualization and it requires capital expenditure and hardware maintenance. That's not the cloud.

As far as free stuff goes, there is nothing about my criteria that precludes free things. Pay for what you use includes free :)

Just re-read my reply to your comment and it read unbelievably snooty.

I'm just trying to tee off further conversation and apologize if I am coming off as talking down or anything like that. Definitely NOT intended.

No worries :-) The same could probably be said about my original comment. I think its worth discussing as cloud computing needs to have a well defined meaning in order for it to move from a this year's buzz word to an important piece of technology and the internet as a whole.

I'm glad you brought it up as most people wouldn't even care :-)

Eucalyptus should be without a doubt part of Cloud computing. Just because its a tool that can create cloud deployments (instead of being a cloud deployment) doesn't exclude it from being part of cloud computing.

Don't get me wrong, I think your post is good at outlining what a client should expect to be a cloud from a corporate/business sense. But in reality, there is so much more that the definition is missing. I think this is so prevalent to me as I'm coming from a research/academic standpoint and not industry.

I think we (you, me, the community) need to concentrate more on defining the feature set clouds look to offer, their end goal and intended purpose. I do not pretend that I have all the answers either. I will try to find what I believe to be a more complete definition, and if one doesn't exist, I will give my best attempt at one...

Andrew said, "Just because its a tool that can create cloud deployments (instead of being a cloud deployment) doesn't exclude it from being part of cloud computing."

I am not saying it is not part of cloud computing. It's a great contributor to the advancement of cloud computing.

But it is not a cloud service itself.

Why define the network to be a web browser? Couldn't a service via the internal network be considered a cloud?
You also state non-proprietary browser but follow with a proprietary web-services API. Sure Amazon uses a REST(ful) API but it is proprietary. Force.com publishes a different but equally proprietary interface. Today any cloud locks you into their solution and portability between clouds is a future dream.

You mention zero capital but that is only part of the cost. What about the opex of tweaking your applications so they speak force.com or EC2? It's easy to say zero capital to start but require rewriting applications is far from free and easy.

Enough nit-picking on my part. Instead I offer a slightly different definition:

1. A service over a network (inter or intra).
2. On-demand scalability
3. Ease of management (everything requires some level of system management or interface tweaking).

Thoughts? blast away :)
MwM


Mike says, "Why define the network to be a web browser? Couldn't a service via the internal network be considered a cloud?"

I don't think it is because it violates everything I personally think of as a cloud. That does not mean I am right and you are wrong. But why do you think such a service is a cloud? What about it makes it important to be considered a cloud service that makes it meaningfully distinct from other cloud services?

Mike says, "You also state non-proprietary browser but follow with a proprietary web-services API. Sure Amazon uses a REST(ful) API but it is proprietary. Force.com publishes a different but equally proprietary interface. Today any cloud locks you into their solution and portability between clouds is a future dream."

As long as the API is a published API, I think it is OK. It means anyone in practice can leverage the service without respect to the architecture of the systems that access them.

Vendor lock is a feature of any cloud service I can think of. If done well, it is much less of a lock than using an internal solution.

Mike says, "You mention zero capital but that is only part of the cost."

Of course it is, but it is a part of the cost that has huge business implications beyond other kinds of costs.

Mike says, "What about the opex of tweaking your applications so they speak force.com or EC2? It's easy to say zero capital to start but require rewriting applications is far from free and easy."

The only reason you need to re-write apps for EC2 is because they were not designed to be scalable web apps in the first place. Force.com and Google AppEngine are different animals.

At any rate, I don't think the OpEx is relevant to defining the term cloud because an OpEx is part of any service, cloud or non-cloud.

Mike's definition:
> 1. A service over a network (inter or intra).
> 2. On-demand scalability
> 3. Ease of management (everything requires some level of system management or interface tweaking).

It really comes close to calling SQL Server a cloud service :)

I think only #2 really captures what most people think of as a cloud service and it leaves out things like GMail or problems that have a hard management problem like EC2 (without cloud infrastructure management tools like enStratus, managing EC2 is a pain).


I found an interesting definition of "Cloud Computing" from Lizhe Wang, a colleague of mine:

Cloud Computing "is a set of network enabled services which provide scalable, QoS guaranteed, normally personalized, and inexpensive computing platforms that can be accessed in a simple and pervasive way."

While I don't believe this is a perfect definition, I do think it encompasses more of the cloud computing field in a way that is meaningful enough for the average person and doesn't limit any of the perceived 'cloud' technologies that exist today.

I think your definition of cloud computing suit SaaS (Software as a Service) better. This is primarily due to point 3, which assumes cloud computing always implies a pay per use model.

In fact, I personally feel some of the comments have better definitions.

Arun says, "This is primarily due to point 3, which assumes cloud computing always implies a pay per use model."

I believe the payment model is critical to the concept of being a cloud service. Did you have something in mind that does not have a pay-per-use model but is a cloud service?

Hi,

I like your definition. I think there is a real distinction between infrastructure service such as MxMail or Amazon EC2 and applications (e.g. LinkedIn). Of course, with some giants the frontier can be blurry (e.g. is Google search an application or an infrastructure block?).

What is interesting also is that we built MxMail around the standards you have defined.

The problem is the usual one of assimmilation and accommodation of new concepts.

The industry is changed by the new concept - accommodation
The new concept is changed by the industry - assimilation

Early Cloud was relatively simple to understand but the concept is getting distorted - take Microsoft's definition - I call this "Fog computing"

I think item 3 should be Service - this can be started, contracted. expanded or terminated as required whether paid or not.

I have reservations about the growth of client applications to access cloud APIs as this erodes the simplicity
of the browser concept and returns us back to client application installs.

I came to the conclusion it's called cloud computing because of the maps you draw of your physical server topology.

In these maps you typically draw each server as a box and write an IP adress under it. The unknown internet with all other IPs is usually drawn as a big cloud.

Cloud computing now means you run your programms inside of this cloud and you can't say before what IP your server has. Usually it isn't executed on a physical server but in a VM that can reside on more than one physical server at one time and can even move between servers.

This implies a very different business model. Usually you pay per server or per share on a server.
But because your programms "in the cloud" aren't bound to any physical server you pay only for what you actually use. (This is your 3rd definition.)

On a wider definition I would even define Amazon's Mechanical Turk as cloud computing. I would even define it as cloud computing if it runs on only one physical server.
This is my argument: The client writes his "program" in natural language, defining what he wants the Mechanical Turk to do. The Mechanical Turk will do it, as long as you pay for the service. The client don't know where his "program" actually runs because there are real people on the other side who may or may not "execute" the "program" for the client. But the program does run (if the client pays for it) and he will get a response for his request.

I think this is a good definition for a "cloud service," which as previous posters point out, what most people think of as SaaS.

"Cloud computing" however strikes me as a bit of a broader--and more elusive--concept that encompasses the end result "cloud services" as well as the technologies/architectures that enable it.

I tried to address some if these issues (in poetic verse) in a post entitled The Blind Men and the Cloud, and can attest that nailing down strict definitions is hard to do.

That's two things we agreed on today. Great post.

John
johnmwillis.com

Yes, any pay per use service can be converted into a free model and it would still be Cloud Computing. This is because, by very definition, the computing is still performed on the cloud.

I believe I have been able to distinguish SaaS and Cloud in my blog post here: What’s the Difference between Cloud Computing & SaaS?

Martin King said, "I have reservations about the growth of client applications to access cloud APIs as this erodes the simplicity of the browser concept and returns us back to client application installs."

The browser concept is simple, but coding a user experience for the browser is not. Many of the web UIs we are seeing today are amazing, when you consider that they are implemented in JavaScript. It is much more difficult than developing a client app. I am encouraged by the ever growing trend of NOT making web apps IE-only. It requires an immense investment in development and QA resources to develop your app once for all non-IE browsers, then again for IE.

The only reason you need to re-write apps for EC2 is because they were not designed to be scalable web apps in the first place. Force.com and Google AppEngine are different animals.

Perhaps a minor point, but you often have to tweak code, even when you're switching services that use the same standard API. For example, you might have two vendors' DM systems that are both WebDAV-accessible. However, what happens behind the WebDAV calls might be slightly, subtly different, in each case. Certainly, there's reason to consider tweaks for other reasons, like performance, too.

I'm not sure if these kinds of migration should be considered a "capital expenditure," but they're a fact of life, even when you don't migrate from one proprietary API to another.

Great discussion - thanks for getting it started George - a few more thoughts as it relates to Cloud:
1) Not my data center (or closet) - I know this is same as colo, but the point is, I don't worry about the power, cooling, redundancy which addresses the "over the Internet or not" quandry.
2) Not my hardware - again raising cap ex/opex discussion up a level
3) Not my people at the infrastructure or app level depending on if you're talking about a SaaS or IaaS provider.
4) Not my software - paying for all software - OS and virtualization software on a monthly basis, but I don't really "own" it.
5) Not my Pager - going off at 3 AM when the hardware fails.

Don't worry - this problem is not unique to cloud, it's about applying the right use-case and getting what you want/need out of it - example: define a "space ship"...

Nice article. Its a good starting point. But cloud computing is a lot more then this.

And also changing Cloud service providers will never be easy as you need to code the changes to match the nwe API everytime you change the provider.

News Topics

Recommended for You

Got a Question?