The Thousand Faces of Cloud Computing

It’s amazing that people are still arguing over what cloud computing is and what is a cloud. I am certainly not immune to such naive arguments. Claims such as “EC2 is NOT a cloud” just makes my head spin and wonder what the heck people are thinking. But if I taking a step back and try to understand why people are so passionate about this subject, I start to realize why there are so many definitions for Cloud Computing and why people continue to passionately argue over these definitions.

The short of it is that cloud means different things to different people. The Cloud has different characteristics to people coming from service provider backgrounds than people from a developer background; it has different meanings to people who care more about architectures than people who are more business-oriented; and it certainly .. to people who are building the clouds than the consumers of the cloud.

So instead of creating a single definition for Cloud Computing, let’s look at it from

  • Two perspectives
  • Five architecture characteristics
  • Three delivery models
  • Three deployment models
  • Three consumption models
  • Two pricing models

Two Perspectives

There are passionate discussions on the definition of Cloud and Cloud Computing. If we summarize the arguments, we can see that there are really two camps of people: those who looks at Cloud as an architecture and those who looks at Cloud as a business model. In many cases they agree on many of the characteristics but there’s usually one topic that really heats up the discussion and that is whether pricing and billing should be a defining characteristic of the Cloud.

The Cloud Architecture camp usually argues that how the Cloud is priced and billed should not be a defining characteristic of the Cloud since that’s a business decision. And they are absolutely right about that.

The Cloud Business camp also passionately argues that how the Cloud is priced must be a defining characteristic, otherwise how else can the user be billed? And they are absolutely right about that as well.

At the end of the day it’s about perspectives. Here are the characteristics again and where I think they fall:

Characteristic Architecture Business
Infrastructure Abstraction
Resource Pooling
Ubiquitous Network Access
On-Demand Self-Service
Elasticity
Pricing Model
Consumption Model

Five Architecture Characteristics

  • Infrastructure Abstraction
  • Resource Pooling
  • Ubiquitous Network Access
  • On-Demand Self-Service
  • Elasticity

I am going to refer you to the write ups in Guidance for Critical Areas of Focus in Cloud Computing from Cloud Security Alliance, as well as the Draft NIST Working Definition of Cloud Computing. These folks have done an awesome job of writing these up so I won’t elaborate here. Notice that these five are architecture characteristics so I didn’t include the utility-based pricing characteristics here.

Three Delivery Models

  • Software as a Service
  • Platform as a Service
  • Infrastructure as a Service

Again, I am going to refer you to the write ups in Guidance for Critical Areas of Focus in Cloud Computing from Cloud Security Alliance, as well as the Draft NIST Working Definition of Cloud Computing. This is generally referred to as the SPI model.

Three Deploy Models

I found that the distinction of public, private, managed, community and hybrid clouds in both the NIST and CSA documents somewhat difficult to comprehend. I don’t mean that they don’t make sense but you really have to think through them before you can understand them. In most cases, the follow three seem to be easier to understand.

  • Internal Cloud

    An internal cloud lives within the 4 walls of the enterprises (like their data center.) It’s fully built, operated, controlled and managed by the enterprises themselves. It has all five of the architecture characteristics of a Cloud. It may or may not have the pricing model required for external clouds since some enterprises may not care about chargebacks.

  • External Cloud

    An external cloud lives outside of the enterprises and it’s usually built and operated by service providers but the resources maybe controlled and managed by the customers. The external cloud can either be shared (multi-tenant) or dedicated (single-tenant). It has all five of the architecture characteristics of a Cloud. The service provider will usually dictate the consumption and pricing models of the external clouds.

  • Private Cloud

    A private cloud is a combination of internal and external clouds. In most cases enterprises have more than one cloud just like they have some infrastructures inside the 4 walls and some outside. Even though there’s both internal and external clouds, enterprises will want to control and manage all of the resources that belong to them, potentially through a single pane of glass. The cloud resoures are private to the customers, thus the name private cloud.

Three Consumption Models

  • Allocation-based
  • Resource pool-based
  • Usage-based

I’ve previously written about the consumption models so please use that as reference.

Two Pricing Models

One of the interesting debates out there is whether Clouds must have utility-based pricing, that is, consumers are only billed for what they used/allocated. I’ve generally seen the following two pricing models from service providers who have cloud offerings.

  • Utility-based

    This is the pay-per-use model that most people associate with cloud infrastructures. Amazon and Google App Engine are based on these models.

  • Subscription-based

    Most people tend to forget the subscription model is very popular in the cloud as well. For example, Salesforce is based on a per-user-per-month charge, so is Google Apps Premium Edition (per-user-per-year.) In fact, most of the cloud applications (SaaS) are based on this model. In addition, we are seeing some of the traditional service providers who are launching clouds also offer this pricing model as well.

So what is Cloud Computing and what is a Cloud?

Well, many combinations of the above can likely be considered clouds. I am not going to add another definition to the mix and hopefully this blog post will point out the reason why everyone has a different definition of Cloud Computing.

May 15th, 2009 | Jian Zhen | 3 Comments

Review of Cloud Security Alliance Guidance

During RSA 2009, Cloud Security Alliance released its Guidance for Critical Areas of Focus in Cloud Computing (pdf). Below are the comments I made on twitter (using hashtag #csaguide). Later on George Hulme (@GeorgeVHulme) also posted his comments to #csaguide as well as written a blog post on it.

My Twitter Comments

Page 19, not sure about the tie of “private clouds” and “single-tenant (dedicated). For example, multi-tenancy is important even for the on-premise cloud within the enterprise. Also, the off-premise cloud piece (essentially an extension of the customer’s on-premise cloud) could be on a multi-tenant cloud. Other than that, i am kewl with the definition of “private cloud”..or maybe i am just not reading correctly..

There seems to be some font size issues with the Governance portion of the doc…or maybe it’s just my adobe reader.

Domain 2 on Governance reads like a list of things that’s designed for an outsourcing check list…and maybe it should be…but i wonder how likely a customer will get that from like google. Apologies to @jsbardin in advance, but seems like this domain is rushed…there’s a lot more context that can help readers. Domain 2 should really be “IT Governance” and not Governance in general. For example, it doesn’t cover corporate governance.

Wassup with the domain 3 with copyright to Francoise Gilbert? Domain 3 on legal issues is quite well written i think…covered a lot of the issues folks have been talking about.

Domain 5 on compliance and audit is a bit light as well…good stuff in there…but i think there’s a lot more can be said.

There seems to be quite a bit of overlap from domain 2 to domain 6…especially around data/information mgmt. Not necessarily a bad thing to keep hammering it in..but i wonder if there might be a better way to structure these.

Surprised at the shortness of domain 7 on portability and interoperatility…there’s pro’ly more to it i am sure..good start. Pro’ly at least 3 layers to portability…data, app, and server image (in the case of IaaS)…i think only the first 2 are covered.

Domain 8 covers some of the same issues as b4..but good list…can def’ly be expanded..good stuff tho.

A bit perplexed bout domain 9…not sure what the goal is for this write up…maybe i just need more brain cells.

Good issues being raised in domain 10…not sure if there’s a lot of guidance…must re-read another time.

Domain 11, page 65, “In an Infrastructure as a Service (IaaS) cloud platform”?? is it a cloud platform or cloud infra? Top of page 66…”local data storage is not persisted across machine restarts”…HUH?! wah? seriously? EC2 only maybe. Page 66 under “IaaS Impact”, “comparable controls do not exist by default..” again…says who? too limted of a view. Think domain 11 author should be diligent in how they use the word “platform”…could be confusing. Top of page 68, Figure 4, actually in many cases dev & test are outside and production is inside. So while figure 4 is valid for some, def’ly not for all. Again..lots of good stuff in domain 11…not sure i agree w/ everything…good start and write up nonetheless. Paas and saas section somewhat light.

Skipping domain 12 [for now]

Scanned domain 13…raises many good issues. [Re-read later]

Domain 14 again raises issues…but seems to be short on guidance. [Again, re-read later]

Not sure what to think of domain 15…must re-read later.

May 2nd, 2009 | Jian Zhen | 2 Comments