Changing the delivery of IT

Tony Bishop

Subscribe to Tony Bishop: eMailAlerts Email Alerts
Get Tony Bishop: Homepage mobile Mobile RSS Facebook twitter Twitter LinkedIn

Blog Feed Post

The Cloud Is Not A Synonym For Cloud Computing

“Where are you storing your data these days,” he asked casually after trying to come up with a better opening line but failing

By Lori MacVittie	Article Rating:
October 22, 2009 02:15 PM EDT	Reads:	16,228

Related
Print
Email
Feedback
Add This
Blog This

Cloudonomics Journal

“Ah, dahhling,” she drawled while gesturing in no particular direction with an almost deprecating wave of her hand. “The Cloud, where else?”

Thanks to the nearly constant misapplication of the phrase “The Cloud” and the lack of agreement on a clear definition from technical quarters I must announce that “The Cloud” is no longer a synonym for “Cloud Computing”. It can’t be. Do not be misled into trying, it will only cause you heartache and headaches. The two no longer refer to the same thing (if they ever really did) and there should be no implied – or inferred - relationship between them. “The Cloud” has, unfortunately, devolved into little more than a trendy reference for any consumer-facing application delivered over the Internet.

Cloud computing, on the other hand, specifically speaks to an architectural model; a means of deploying applications that abstracts compute, storage, network, and application network resources in order to provide uniform, on-demand scalability and reliability of application delivery.

Of similar importance is the distinction between “user” and “consumer”, and this is important enough that we need to nail this down and be particular in our usage of these terms. “Consumer” is anyone who uses a web-application to do anything. Consumers make use of applications over the Internet, but they are not “users” of cloud because they don’t interface with “cloud” any more than they interface with hosting providers; they interface with an application. Users of cloud are developers, administrators, and IT organizations that interface with a cloud computing environment with the intention of deploying an application for their consumers.

I’m really not all that concerned whether we use “application user” and “cloud user” to distinguish between the two or “consumer” and “user” or “application customer” and “cloud customer”. I am firm in the belief that we need to distinguish between the two before we go any further down this road. The lack of distinction between the two points of view continues to confuse just about everyone who isn’t knee-deep in the technology and this is partially responsible for the Chicken Little responses to application failures that may or may not be deployed atop cloud computing architectures.

“The Cloud” has lost meaning as far as cloud computing models and data center architectures are concerned and is now little more than a technical-sounding term thrown around by consumers – and others - who never really understood the use of this delightful little phrase or that there’s even a difference. Maybe that’s success, as consumers shouldn’t care about internal implementation, but it’s also failure because it’s confusing to a lot of people who are supposed to care and be able to differentiate.

CLOUD COMPUTING AND APPLICATIONS ARE NOT INTERCHANGEABLE

When you deploy an application in a cloud computing environment and something goes wrong, who does the consumer call? Not the cloud computing provider. That’s a by-product of not caring about implementation – they aren’t supposed to know that information in the first place. It’s a near certainty that BitBucket’s customers or consumers, whichever you prefer, weren’t calling Amazon when its application became unavailable due to a DDoS attack, they were e-mailing, tweeting, and calling BitBucket – the application provider. Similarly, T-Mobile customers were likely calling, well, T-Mobile after Microsoft’s spectacular failure because they are the provider as far as customers are concerned, not Microsoft.

It’s not like a customer or consumer can call 1-800-THE-CLOUD and get support for whatever problem they’re having with whatever application they may have been using. They interface with an application, they use an application, and whoever is responsible for that application (hint: that’s you) is who they’re going to call and blame in the event of an outage, or a data loss, or a security breach.

That’s why it’s important that the cloud computing user, that’s you, have some knowledge of the cloud computing provider’s implementation. You don’t need to know the nitty gritty details, but you do need to understand whether the model is appropriate to meet your business and technical needs. Automatic scalability is often assumed to be part and parcel of a cloud computing environment, but that’s not always the case. If you need that scalability you’d darn well better understand whether it’s just part of the offering or whether you have to do something special to provision it. If your application suddenly doesn’t work when it’s deployed in a cloud computing environment, maybe you didn’t verify whether the provider’s load balancing solution is sticky or not, or whether there’s something you need to configure, specify, or modify in your application to make sure it works properly.

Somewhere along the lines the lack of distinction between users of an application and users of the cloud led to the erroneous and dangerous belief that users of cloud computing don’t have to know anything about the implementation. That’s just not true and it can be detrimental to not only the success of cloud computing but more specifically and closer to home, I’m sure, to the success of your application deployment.

The way in which we describe technology can and does have a profound impact on the way we use it, understand it, and support it. So let’s be more clear about who interfaces with what, and maybe in the future more people will be less apt to put forth the notion that a failure in the cloud is the same as a failure of cloud computing.

No, I won’t hold my breath, but I can hope, can’t I?