James Urquhart (Cisco marketer and author of The Wisdom of Clouds) has posted a video to the Cisco Data Center Networks blog entitled Clarifying Internal Cloud versus Private Cloud. In the video James stands by an unreadable whiteboard (new markers, please, James! ) and discusses the difference between public vs. private clouds and internal vs. external clouds, briefly summarized as:

While internal and external clouds are based on the ownership of where the computing resources reside, two other cloud types – public and private – have more do to with the control point of the cloud applications and resources.

Sam Charrington (Appistry marketer and regular CloudCamp organizer) commented on James’ definition in a post on his blog:

While I agree that Private is not always equal to Internal, James’ [re]definition of increasingly accepted terminology just serves to muddy the waters by introducing the existence of unified control systems as a defining characteristic.

I have much respect for James and Sam as cloud thought-leaders, but I’m afraid I have to disagree with them both.

I’ve been hearing confused voices discuss the public/private cloud concepts for a couple years now, but I don’t think the industry has yet settled on a definition that captures the dimensions of a cloud environment completely. Oh, I agree that the conversation has become more subdued recently. But I suspect this is due to boredom with the topic rather than consensus.

But boredom be damned, James expands/clarifies the definition to cover a new dimension. His division of the cloud based on two attributes, ownership and point of control, leaves aside other dimensions that are critical to the cloud’s definition. I don’t have any disagreement with these attributes being central to a cloud instance. But I would add a few critical attributes to the list of dimensions that must be captured by the internal/external private/public definition.

To illustrate the point: My own boss*, Bryan Doerr (Savvis CTO), was recently summarized describing the “Private” aspect of a cloud instance similarly to how I suspect Sam would define it but with the on/off-site aspect that James is trying to accommodate in his internal/external definition:

In general, the phrase, “private cloud” has meant cloud-like resources inside the enterprise. Savvis is proposing that the “private cloud” be located off premises but include greater measures of security and quality of service than temporary workloads sent to the shared facilities, like Amazon’s EC2.

Bryan’s talk, which led to the summary quoted above, hints at the fundamental problem: that a cloud service has to accommodate all of the complexities of a traditional IT environment. There is no magic pixie-dust that makes an infrastructure cloud capable of side-stepping longstanding IT challenges and best-practices while scaling existing applications as-is in an efficient hardware environment.

Rather, cloud service providers design and package different IT elements into a solution, addressing the aforementioned challenges on the user’s behalf. It’s IT outsourcing taken one step closer to the inevitable conclusion of any technology life-cycle in a free-market economy: commoditization.

But we’re not there yet. We can say that this packaged solution is a “cloud” solution because of the high-level behaviors that it supports: on-demand provisioning, usage-based costing/billing, consolidated controls, etc. These behaviors are typically enabled by a collection of multi-tenant hardware and software platforms. But the specific platform details such as capabilities and features, implementation choices, etc, all lead to small differences in the solution.

These differences, in addition to being the gap between commoditization and our current position in the technology life-cycle, are what lead us to need terminology like internal/external and private/public. Maybe one day IT infrastructure will converge around a common set of attributes with limited and known values. (Not that I would predict such a thing anytime soon.) In the meantime we’re stuck with a terminology that is more complicated than cloud marketers and customers would like.

I’d propose that this terminology includes at a minimum the following attributes:

• Platform Ownership – customer, provider, other
• Financial Liability – customer, provider
• Physical Location – customer premises, provider premises, other location
• Point of Control – customer, provider, other
• Point of Management – customer, provider, other
• Network Connectivity – private, public, both
• Security Policy Management – customer-driven, provider-driven
• QoS Policy Management – customer-driven, provider-driven

Our job as cloud service providers is to package these attributes in the best way for our customer-base and to make transitions between different attribute states as seamless as possible. As an architect working on one such cloud platform, however, I’d sure kill for some of that aforementioned pixie-dust…

* – Note Well: This post is not endorsed or sponsored by my employer, Savvis, Inc, and has not been written, edited, reviewed, or approved by anybody except me (Benson Schliesser).