Cloud Computing and Theories of Knowledge and Reality

Posted on February 9, 2012

If a tree falls in a forest, and nobody is around to hear it hit the ground, would its impact with the ground make a sound?   If an organization implements Cloud computing technologies, but does not use them in a “Cloudy” way, is it still a Cloud?  As Cloud computing continues its torrid pace of adoption worldwide, many challenges still must be addressed to make sense of reality in the Age of Cloud.  A couple of thoughts to share follow.

Is it Cloud or Not?

One of the most interesting discussions today, in particular in the Federal Government, is the fundamental question, “Is it a Cloud or not?”

While the NIST framework provides a foundational set of definitions and essential criteria for Cloud computing, there is a lot of obfuscation and lack of architectural clarity as to what is and is not a Cloud.  Part of this has to do with access to funding.  Do you think a new program would get funding if it was based on Client-Server technologies, or a mainframe technology?  However, if it carries the “Cloud” moniker in its title or description, it stands a better chance for funding approval.  Many Cloud projects are being funded to exploit the halo effect of the Federal Government 25 Point Plan and Cloud First Policy.

I believe there needs to be a set of clear, objective criteria –  technical/ l, operational and business criteria – that help define what is a Cloud computing implementation, and equally important, what is not.  These criteria would also help define the relationship of Cloud computing to other related computing models, such as High Performance Computing (HPC ), Grid computing, and really cool distributed computing architectures.

I’ll post another Blog entry soon with a table of criteria to help attempt to answer this, but I’m curious who else has asked these fundamental questions, and who else has answered them.

Below is a start to such a definition of objective criteria for what is and is not Cloud based on NIST criteria, augmented by technical, operational and business criteria. This is a first cut draft, and we’ll expand on in a future whitepaper.

NIST Essential Criteria	Technical	Operational	Business
On Demand Self-Service Access	Self-Service reservation of and access to Cloud resources	Can access additional capacity on demand	Sharing of Resources in Some Way
Broad Network Access	Cloud resources are accessible via network connection from any device   based on consumer requirements	Cloud service catalog enables access to enterprise Cloud services,   pricing information, SLA and other information	Consumer-Provider Relationship (Optional Cloud Broker)
Resource Pooling	Cloud resources are aggregated, centralized and shared by various   consumers; standard offerings are architected and delivered based on Consumer   demands	Help desk, IT service management and Service portfolio owner   processes and policies are established to support the Cloud operating model.	Enables consolidation of physical resources
Rapid Elasticity	Cloud implementation supports rapid spin-up of Virtual Machines, or   other Cloud resources, and also the release of those resources back to the   shared resource pool in near-real time.	Capacity planning processes enable the resource pool to be created,   managed, and sized based on actual and forecasted demand. Ensures “capacity   ahead of demand” for all Cloud resources.	Shared, centralized pooling of various Cloud resources, e.g. compute,   storage, network, application platforms, software applications, data, et al
Measured Service	Cloud resource management, metering and other enabling technologies   are implemented for all Cloud services.	Cloud metering, billing and accounting capabilities are enabled by   Cloud Management technologies	Consumers pay for what they use, and no more.
	Builds on NIST Service Layers
	Can evolve to a hybrid Cloud to consumer either internal private   Cloud resources or externally-provided resources (private or public)

 

The other pressing question is the separation of the technology of Clouds from the behavior of Clouds.

What I mean is this:  if Organization A implements a private Cloud, delivering Infrastructure as a Service (IaaS) for a business unit requirement, but does not share any IaaS capacity or resources within that program, or within the business unit, does the implementation still qualify as a Cloud?  I would argue that implementing Cloud enabling technologies is not sufficient to call it a Cloud, if it is not behaving as a Cloud.  That means the Organization itself has to adopt the behavior of sharing resources, of being both Providers and Consumers of shared capabilities, under terms of a Service Contract and supporting Service Level Agreement.

I would argue that the combination of business criteria and operational criteria establish the behavioral model of Cloud computing.  Technically, Cloud is here and now.  Behaviorally, many organizations have not implemented the necessary organizational behaviors to harness the power of Cloud computing technologies, nor have they designed an operational Cloud governance framework that creates incentives to consume resources from the Cloud.

If you implement Cloud technologies, but not the supporting Cloud Behavior, you will not truly have a Cloud in your enterprise.   If an organization implements a Cloud technical solution, but does not implement the Cloud behavioral model, the consumer-provider relationship, the service contract and SLAs, does it still qualify as a Cloud?  Back to theories of knowledge and reality:  “If it walks like a duck, quacks like a duck, and looks like a duck, you must be a duck.  With Cloud, if it doesn’t behave like a Cloud, I don’t believe it qualifies as a Cloud.  Does your Cloud quack?