Topics


Blogs


Forums


Samples


Media


Labs


Resources

 




DevCentral > Weblogs > Lori MacVittie - Two Different Socks
 Cloud Computing: The Last Definition You'll Ever Need
posted on Wednesday, November 05, 2008 6:53 AM

The VirtualDC has asked the same question that's been roaming about in every technophile's head since the beginning of the cloud computing craze: what defines a cloud? We've chatted internally about this very question, which led to Alan's questions in a recent blog post.

quote-left Lori and others have suggested that the cloud comes down to how a service is delivered rather than what is delivered, and I’m fine with that as a long term definition or categorization. I don’t think it’s narrow enough, though, to answer the question “Is Gmail a cloud service?” because if Gmail is delivered over the web, my internet connection is my work infrastructure, so therefore…Gmail is a cloud service for me?

No, it's not. It may be for the developers, if they're using cloud computing to develop and deploy GMail, but for you it's naught but cloudware, an application accessed through the cloud. From the end-user perspective it's a hosted application, it's software as a service (SaaS), but it isn't cloud computing or a cloud service. 

The problem here, I think, is that we're using the same terms to describe two completely different things - and perspectives. The real users of cloud computing are IT folks: developers, architects, administrators. Unfortunately, too many definitions include verbiage indicating that the "user" should not need any knowledge of the infrastructure. Take, for example, Wikipedia's definition:

It is a style of computing in which IT-related capabilities are provided “as a service”, allowing users to access technology-enabled services from the Internet ("in the cloud") without knowledge of, expertise with, or control over the technology infrastructure that supports them.

It's the use of "user" that's problematic. I would argue that it almost never the case that the end-user of an application has knowledge of the infrastructure. Ask your mom, ask your dad, ask any Internet neophyte and you'll quickly find that it's probably the case that they have no understanding or knowledge (and certainly no control) of the underlying infrastructure for any application. If we used the term "user" to mean the traditional end-user, then every application and web site on the Internet is "cloud computing" and has been for more than a decade.

FINALLY, IT REALLY IS ALL ABOUT *US*

The "user" in cloud computing definitions are developers, administrators, and IT folks. Folks who are involved in the development and deployment of applications, not necessarily using them. It is from IT's perspective, not the end-user or consumer of the application, from which cloud computing can be - and must be - defined. We are the users, the consumers, of cloud computing services; not our customers or consumers. We are the center of the vortex around which cloud computing revolves, because we are the ones who will consume and make use of those services in order to develop and deploy applications.

Cloud computing is not about the application itself; it is about how the application is deployed as how it is delivered. Cloud computing is a deployment model leveraged by IT in order to reduce infrastructure costs and/or address capacity/scalability concerns. Just as an end-user cannot "do" SOA, they can't "do" cloud computing. End-users use applications, and an application is not cloud computing. It is the infrastructure and model of deployment that defines whether it is cloud computing, and even then, it's never cloud computing to the end-user, only the folks involved in developing and deploying that application.

Cloud computing is about how an application or service is deployed and delivered. But defining how it is deployed and delivered could be problematic because when we talk about how we often tend to get prescriptive and start talking in absolute checklists. With a fluid concept like cloud computing that doesn't work. There's just not one single model nor is there one single architecture that you can definitively point to and say "We are doing that, ergo we are doing cloud computing."

THE FOUR BEHAVIORS THAT DEFINE CLOUD COMPUTING

It's really about the behavior of the entire infrastructure; how the cloud delivers an application, that's important. The good thing is that we can define that behavior, we can determine whether an application infrastructure is behaving in a cloud computing manner in order to categorize it as cloud computing or something else. This is not dissimilar to SOA (Service Oriented Architecture), a deployment model in which we look to the way in which applications are architected and subsequently delivered to determine whether we are or are not "doing SOA."

  1. DYNAMISM. Amazon calls this "elasticity", but it means the same thing: this is the ability of the application delivery infrastructure to expand and contract automatically based on capacity needs. Note that this does not require virtualization technology, though many providers are using virtualization to build this capability. There are other means of implementing dynamism in an architecture.
  2. ABSTRACTION. Do you need to care about the underlying infrastructure when developing an application for deployment in the cloud. If you have to care about the operating system or any piece of the infrastructure, it's not abstracted enough to be cloud computing.
  3. RESOURCE SHARING. The architecture must be such that the compute and network resources of the cloud infrastructure are sharable among applications. This ties back to dynamism and the ability to expand and contract as needed. If an application's method of scaling is to simply add more servers on which it is deployed rather than be able to consume resources on other servers as needed, the infrastructure is not capable of resource sharing.
  4. PROVIDES A PLATFORM. Cloud computing is essentially a deployment model. If it provides a platform on which you can develop and/or deploy an application and meets the other three criterion, it is cloud computing.

Dynamism and resource sharing are the key architectural indicators of cloud computing. Without these two properties you're simply engaging in remote hosting and outsourcing, which is not a bad thing, it's just not cloud computing. Hosted services like Gmail are cloudware, but not necessarily cloud computing, because they are merely accessed through the cloud and don't actually provide a platform on which applications can be deployed. Salesforce.com, however, which provides such a platform - albeit somewhat restricted - then fits into the definition of cloud computing.

Cloudware is an extension of cloud computing but they do not enable businesses to leverage cloud computing in the same way as an Amazon or BlueLock or Joyent. Cloudware may grow into cloud computing, as Salesforce.com has done over the years. Remember when Salesforce.com started it was purely SaaS - it simply provided a hosted CRM (Customer Relationship Management) solution. Over the years it has expanded and begun to offer a platform on which organizations can develop and deploy their own applications.

Cloud computing, as Gartner analysts have recently put forth, is a "style of computing". That style of computing is defined from the perspective of IT, and has specific properties which make something cloud computing - or not cloud computing as the case may be.

Follow me on Twitter View Lori's profile on SlideShare AddThis Feed Button Bookmark and Share



 
      

Feedback


11/6/2008 2:22 PM
Gravatar Couple things...

I have some thoughts on the "cloud hosting" issue myself, actually blogged today. I have yet to see a fully stable solution, Mosso included, and am doubting the cloud hosting idea as of yet. Right now, it seems we have a lot of expensive hardware and staff working to try to accomplish this, but without proper structure of the devices in a failover state, I don't see it happening yet. Media Temple, Amazon and yes, even Mosso, have all suffered outages as a result.

Thoughts? Anyone? Feel free to check out my blog and read/Digg/send to a friend as well. This is a good idea that hasn't been fully executed yet in my opinion.

Read: Cloud Computing - Is it just a bunch of fluff?
William Ashworth

12/9/2008 3:17 PM
Gravatar Normal 0 false false false EN-US X-NONE X-NONE MicrosoftInternetExplorer4 Here is a reposting from the
Technical AND Marketing?

1/27/2009 4:24 AM
Gravatar Cloud Computing's Other Achilles' Heel: Software Licensing
Lori MacVittie

4/1/2009 7:44 PM
Gravatar First, I really like your blog – it pulls together the implicit elements of Cloud Computing nicely.

Second, it is never all about *us* - whether we are talking SOA or Cloud or whatever the latest hype word or acronym might be, we don't exist in a vacuum. IT sells the concept to the business; the business adopts the concept and frames it in a way which pleases the analysts which hopefully enhances shareholder value as well as real value in terms of the service delivery of the organization or department.

Third, it is not binary (at least in my opinion) - real world examples of Cloud Computing will continue to evolve and contain elements which meet the strict definitions of Dynamism and Resource Sharing used above. Practically speaking, existing solutions contain elements which both meet and break these rules at the same time - within the same solution. Are these solutions not worthy of being used in the same sentence as Cloud Computing? I agree with William Ashworth in the sense that depending on how exacting we want to be about the IT principles, arguably there are no real world examples to speak of at all.

Let’s not forget that the concept came from solution architecture diagrams where the cloud was used to explain complex underlying architecture (not requiring further elaboration in that context). That defintion has evolved and current defintions will also.
Mark van Meurs

8/24/2009 7:33 AM
Gravatar We Don
Lori MacVittie
 Leave Feedback
Title  
Name  
Email
Url
Comments   
Please add 4 and 1 and type the answer here: