Users use Applications. Applications use Clouds.
Preparing for the upcoming Cloud Connect conference several speakers and presenters have put forth the proposal that no one should attempt to define cloud yet again. After all, if you’re attending the conference (and you are attending, of course, aren’t you?) then you certainly have a firm understanding of what cloud computing is and what it can do. But most end-users and business stakeholders won’t be attending and don’t have a firm understanding of cloud computing. Even the technology pundits to whom these constituents turn to learn about the technology often fail to really “get” cloud computing, as evinced by the number of “what is cloud computing” articles have sprung up in main stream publications lately. Many of these articles define cloud computing necessarily, it’s the focus of the article after all. But the definitions proffered clearly indicate that there are still equal parts confusion and interest in cloud computing from, well, the mainstream. Take this statement from the Wall Street Journal regarding cloud computing:
Broadly speaking, any service or program sent over an Internet connection can be considered a cloud service.
No, actually, it can’t. Or more correctly – because there’s no vocabulary or definition police in the technology sector – it shouldn’t be.
Cloud computing is not a synonym for cloud. And vice-versa. Cloud computing is perhaps the first case of “technology for technology’s sake” that is actually a good thing. That’s because cloud computing is for applications. It’s not for users, it’s for applications. A cloud computing environment without an application is pretty much useless. A dynamic collection of compute resources that remains unfulfilled, idly spinning disks and catching CPU interrupts willy nilly without purpose.
Users, i.e. consumers, never really interact with a cloud computing environment, they interact with an application. Many folks identify SaaS (Software as a Service) as “cloud” because many of the properties associated with cloud computing – scalability, multi-tenancy, on-demand usage and dynamic adjustment to capacity – are inherently part of the offering. That may – or may not – be because the underlying infrastructure on which those applications are deployed is, in fact, a cloud computing infrastructure. But that does not automatically make a SaaS offering a cloud computing implementation any more than it makes my “Hello World” application a “cloud” when it’s deployed within Amazon or BlueLock or RaceSpace or GoGrid’s cloud computing environment. An application is not a cloud, its infrastructure and environment is “a cloud”.
Let’s say that again: an application is not “a cloud”, its supporting infrastructure and environment are “a cloud.” An application may be a cloud-based application or service, but it is never, ever a “cloud” itself nor are you using “cloud computing” by simple virtue of accessing that application. You are using an application, the application is using cloud computing.
To visually see the myriad relationships in cloud computing between disparate components I encourage a perusal of Brenda Michelson’s excellent cloud-o-gram.
A “cloud” is really an architecture that exhibits particular characteristics (on-demand, multi-tenant, rapid elasticity, resource pooling) that enable applications deployed atop that architecture to appear “infinitely scalable.” Saying an application is or is not cloud is like saying an application is or is not SOA. The application may leverage a SOA, it may be comprised of services (a “composite application”) but it is not SOA. It can’t be because SOA is an architecture, a design and deployment model, a means of interaction between services. Like SOA, there’s no right or wrong way to build a cloud because it’s simply a set of architectural principles and characteristics. If the end-result of applying those architectural principles is an infrastructure exhibiting those characteristics, then you’ve got a cloud. This is why virtualization is not a requirement to build a cloud computing environment. It is certainly one way to achieve resource pooling and rapid elasticity, but it is not the only way.
If, as a user, you can tell the difference between a web-based file backup service/application from five years ago and a web-based file backup service/application today built atop a cloud computing environment then perhaps I’ll reevaluate my present stance on what is and is not a cloud. But I sincerely doubt that any user can tell the difference because as far as the user is concerned, there isn’t any difference. The application from a user perspective remains the same, regardless of its infrastructure. As well it should.
That’s because users use applications and applications use clouds.