1. Virtualization is key. I think the cloud is marked by a construction from dynamic pools of virtualized resources.
2. Instead of focusing on individual physical components, the cloud focuses on pools of compute resources. This seems to have led to higher priority for service delivery.
3. Finally, I think the cloud is defined by being convenient for the consumer instead of being convenient for the provider.
Within those constraints, I usually call a cloud private if it is under the control of an enterprise IT organization, in a way similar to older systems. I think of the cloud as public if the provider is mostly in control instead of the tenants.
With that definition of the private cloud in mind, the model offers a lot of advantages to larger IT departments. The private cloud allows IT teams to more quickly provision resources in support of business initiatives. It's also a better way to invest in IT infrastructure. The model is inherently scalable, which means that IT funds can be used to create value instead of keeping the lights on so to speak.
Obviously, private clouds aren't for every IT organization, but I think the private cloud has merit. As organizations globalize and just generally get big, economies of scale can be leveraged internally to increase the quality of IT projects and services.
I think a much more apt - and something more applicable to SFDC, is anything which exposes "architectural resources" - such as Platform, Storage, or Compute as a service/hosted system is a much better, and cleaner a term then throwing applications built on cloud technology into the mix. The cloud is the dynamic, elastic, "on demand" of resources, not the utilization of those resources.
Yes.
We have a word for that - Internet.
You noticed that? :)
I think a much more apt - and something more applicable to SFDC, is anything which exposes "architectural resources" - such as Platform, Storage, or Compute as a service/hosted system is a much better, and cleaner a term then throwing applications built on cloud technology into the mix. The cloud is the dynamic, elastic, "on demand" of resources, not the utilization of those resources.
I think you are right, kind of. Developers talk about cloud computing, cloud storage etc to distinguish it from their traditional services.
However, non-developers don't see it like that. They see "email" as a resource, and the ability to elastically grow their email service as making it "in the cloud".
I think, as a term passed to non technical or lightly technical end-users, "the cloud" is largely useless. The cloud is not an "end user" feature except in the features that a cloud-based architecture might bring.
Taking your example - end users should never hear about "the cloud" when discussing email. All they care about is a hosted application that "just works" - having it based "on the cloud" is uninteresting, except by the features it brings with it, which they reap the benefits of.
So, maybe trying to use it when discussing things outside of mostly technical (IT personell, Devops folks, developers) is mostly useless except to denote a very specific (scalability, uptime) set of features and even then you're better off not talking about "the cloud" but the specific features, which are tangible to them.
They are CIO's and managers in charge of purchasing an email solution. They know they need a "cloud strategy", and vendors are quite happy to tell them their solution is "cloud based" if it make them happy.
So yes - it's mostly useless as a technical term.
Take for example, cloud storage. I would not sell "the cloud" part to a person, rather, I would sell them the fact that it's hosted and highly reliable, infinitely scalable, pay as you go and cheap compared to a local storage cluster buildout.
I wouldn't sell them the cloud part, as not all things in, on and around the cloud inherit all the features the cloud might bring (meaning, you can screw up an architecture no matter where it's implemented).
But unfortunately many times the people with the budget don't actually care about the features. The word "cloud" is important to them because their CEO read about it in a glossy magazine, so they need to be "cloud enabled"
You need to be careful, though because sometimes "cloud" is seen as a negative. I've seen companies that state "We don't believe in the cloud and we have a purchasing policy that excludes any cloud based solutions" - but then you dig deeper and find how proud they are of the "hosted solution" they bought from a vendor because of the way they don't have to pay for capacity until they use it.
Sigh..
(Advice for young players: Enterprise sales will kill your soul)
You can say it shorter - it's cloud.
It does not, however, make your application "the cloud" - hosted applications are just that; hosted applications. Hotmail is not a cloud application, it might have a cloud back end, it might run on Azure, etc, etc but it's not "the cloud"
Also, your alternative explanations are very Microsoft/Windows focused.
I find your definition of the cloud as very confusing and very limiting.
We at SFDC hear a lot about offers to businesses of "your own private cloud", which is essentially marketing jargon for something very un-cloud-like: running software locally, on your own servers, while you're completely responsible for the entire operation. It's a grossly disingenuous hijacking of the "cloud" terminology that I've found promotes confusion.
Most of the other responses here would match my own definition of the cloud: software, offered as a service, where all the underpinnings (data center management, software updates, redundancies, reliability) are abstracted away from you. The key is that you only need two things to access a cloud resource:
When I explain the cloud to people who don't read HN, I usually make a comparison to Gmail and MS Office. You access Gmail through your web browser, and there's no local software to download. When Google releases a new feature or a bugfix or a security patch, there's no action required on your end. You're simply up to date the next time you connect.Contrast that with MS Office, which comes on a CD/DVD, requires a local install process, and needs to be constantly patched for features and security. All of the work to maintain that software falls to you, the end user.