My practical definition of cloud was a cherry-pick of NIST’s (PDF) “essential” characteristics of cloud. Clearly I don’t think that everything NIST listed is essential. And I don’t think either that service or deployment models should be part of the definition of cloud. Why’s that?
Broad network access: Not part of cloud. Network access, sure, but broad? What if it’s just for use within your lab?
Resource pooling: Not part of cloud, just a cloud-enabler. As I like to say, you could build a cloud service on top of a non-virtualized environment. It would just be foolish to try. That doesn’t make virtualization part of the definition of cloud.
Rapid elasticity: If you have any appreciable elasticity in the cloud system, it should be rapid—yes. But elasticity itself isn’t inherent to cloud, even if today most cloud environments are elastic. I don’t think it will stay that way, because that implies that cost is unimportant.
[Defined by] service and deployment models: This is where NIST gets to incorporate the buzzwords, SaaS, PaaS, public, private, etc. The problem with these is that they’re really just guideposts. Any given cloud solution can, and eventually almost always will, combine all of these. Any one cloud solution can easily defy exact definition. What is a SaaS offering that includes a development platform, for example? These models are illuminating examples, but not part of a definition.
In the end, I cut all these from my “practical” definition because they don’t add value if you’re at the first stages of knowing what is and what isn’t a cloud approach to a given business problem. They just add depth, complexity, and context—useful at later stages, sure, but progressively less practical.
What do you think?