The Vagaries Of Cloudcabulary: Why Public, Private, Internal & External Definitions Don’t Work…
Updated again at 13:43pm EST – Please see bottom of post
Hybrid, Public, Private, Internal and External.
The HPPIE model; you’ve heard these terms used to describe and define the various types of Cloud.
What’s always disturbed me about using these terms singularly is that separetely they actually address scenarios that are orthogonal and yet are often used to compare and contrast one service/offering to another.
The short story: Hybrid, Public, and Private denote ownership and governance whilst Internal and External denote location.
The longer story: Hybrid, Public, Private, Internal and External seek to summarily describe no less than five different issues and categorize a cloud service/offering into one dumbed-down term for convenience. In terms of a Cloud service/offering, using one of the HPPIE labels actually attempts to address in one word:
- Who manages it
- Who owns it
- Where it’s located
- Who has access to it
- How it’s accessed
That’s a pretty tall order. I know we’re aiming for simplicity in description by using a label analogous to LAN, WAN, Intranet or Internet , but unfortunately what we’re often describing here is evolving to be much more complex.
Don’t get me wrong, I’m not aiming for precision but instead accuracy. I don’t find that these labels do a good enough job when used by themselves.
Further, you’ll find most people using the service deployment models (Hybrid, Public, Private) in absence of the service delivery models (SPI – Saas/PaaS/IaaS) while at the same time intertwining the location of the asset (internal, external) usually relative to a perimeter firewall (more on this in another post.)
This really lends itself to confusion.
I’m not looking to rename the HPPIE terms. I am looking to use them more accurately.
Here’s a contentious example. I maintain you can have an IaaS service that is Public and Internal. WHAT!? HOW!?
Let’s take a look at a summary table I built to think through use cases by looking at the three service deployment models (Hybrid, Public and Private):
THIS TABLE IS DEPRECATED – PLEASE SEE UPDATE BELOW!
The blue separators in the table designate derivative service offerings and not just a simple and/or; they represent an actual branching of the offering.
Back to my contentious example wherein I maintain you can have an IaaS offering which is Public and yet also Internal. Again How?
Remember how I said “Hybrid, Public, and Private denote ownership and governance whilst Internal and External denote location?” That location refers to both the physical location of the asset as well as the logical location relative to an organization’s management umbrella which includes operations, security, compliance, etc.
Thus if you look at a managed infrastructure service (name one) that utilizes Cloud Computing principles, there’s no reason that a third party MSP could not deploy said service internally on customer premises equipment which the third party owns but operates and manages on behalf of an organization with the scale and pay-by-use model of Cloud internally that can include access from trusted OR untrusted sources, is there?
Some might call it a perversion of the term “Public.” I highlight it to illustrate that “Public” is a crappy word for the example because just as it’s valid in this example, it’s equally as valid to suggest that Amazon’s EC2 can also share the “Public” moniker, despite being External.
In the same light, one can easily derive examples of SaaS:Private:Internal offerings…You see my problem with these terms?
Moreover, the “consumer” focus of the traditional HPPIE models means that using broad terms like these generally implies that people are describing access to a service/offering by a human operating a web browser, and do not take into account access to services/offerings via things like API’s or programmatic interfaces.
This is a little goofy, too. I don’t generally use a web browser (directly) to access Amazon’s S3 Storage-as-a-Service offering just like I don’t use a web browser to make API calls in GoogleGears. Other non-interactive elements of the AppStack do that.
I don’t expect people to stop using these dumbed down definitions, but this is why it makes me nuts when people compare “Private” Cloud offerings with “Internal” ones. It’s like comparing apples and buffalo.
What I want is for people to at least not include Internal and External as Cloud models, but rather used them as parameters like I have in the table above.
Does this make any sense to you?
Update: In a great set of discussions regarding this on Twitter with @jamesurquhart from Cisco and @zhenjl from VMware, @zhenjl came up with a really poignant solution to the issues surrounding the redefinition of Public Cloud and their ability to be deployed “internally.” His idea which highlights the “third party managed” example I gave is to add a new category/class called “Managed” which is essentially the example which I highlighted in boldface above:
This means that we would modify the table above to look more like this (updated again based on feedback on Twitter & comments) — Ultimately revised as part of the work I did for the Cloud Security Alliance in alignment to the NIST model, abandoning the ‘Managed’ section:
Revised Model
This preserves the notion of how people generally define “Public” clouds but also makes a critical distinction between what amounts to managed Cloud services which are provided by third parties using infrastructure/services located on-premise. It also still allows for the notion of Private Clouds which are distinct.
Thoughts?
Related articles by Zemanta
- Friday Cloud Poetry: “On the Bullshit That is False Cloud” (rationalsurvivability.com)
- The Classical DMZ Design Pattern: How To Kill Security In the Cloud (rationalsurvivability.com)
- Incomplete Thought: The DevOps Disconnect (rationalsurvivability.com)
- The Security Hamster Sine Wave Of Pain: Public Cloud & The Return To Host-Based Protection… (rationalsurvivability.com)
- The Hypervisor Platform Shuffle: Pushing The Networking & Security Envelope (rationalsurvivability.com)
- Security: In the Cloud, For the Cloud & By the Cloud… (rationalsurvivability.com)
- Virtualization & Cloud Don’t Offer An *Information* Security Renaissance… (rationalsurvivability.com)
- All For One, One For All? On Standardizing Virtual Appliance Operating Systems (rationalsurvivability.com)
- CLOUDINOMICON: Idempotent Infrastructure, Survivable Systems & Bringing Sexy Back to Information Centricity (rationalsurvivability.com)
- If You Could Have One Resource For Cloud Security… (rationalsurvivability.com)
- Cloud Computing: Whats a Hybrid Cloud and Where Can I Get One? (informationweek.com)
- Multi-Tenancy Requires More Than Just Isolating Customers (devcentral.f5.com)
It does.
I think looking at cloud descriptions as a combination of "who runs it" and "who uses it" makes perfect sense. It acknowledges that cloud computing styles are going to cross all of the sizes of enterprise and have to meet requirements/budgets of all manners and sizes.
One nit to pick: I think at this stage of discussing cloud architecture that precision in terms is vital. It seems to me that a lot of the consternation in the community could be resolved if a common set of vocabulary and concepts was used. That way we could argue about specifics of the technology and its design versus arguing about labels…
@Armorguy Totally agree with your last statement.
However, before I suggested alternative titles (which nobody will agree on 😉 I wanted to discuss the issue first.
/Hoff
Hoff,
1) the confusion (or terminological laziness) you point out regarding Public- Private distinction and the External-Internal distinction definitely DOES make sense.
Taking some liberties (and at risk of getting into a kerfuffle about cloud and electricity grid analogies):
Many public electric utilities will permit the individual property owner to deploy electricity generating equipment, and supply power back to the public grid, so long as the public utility has a level of administrative and management control on the means of production. This seems like an analogous situation to your Public IaaS utilizing an "internal", privately OWNED source of production.
2) Some years ago, BT proposed a grid-computing "service" in which corporate compute resources (or at least some portion of them) would be under the management responsibility of a BT Operation, Administration and Management facility. In something of a co-op arrangement, many subscribers to the service were also members of the community which contributed resources to the pool, allowing the BT management service to allocate / re-allocate resources to those members on a near-realtime basis. This is an example of an MSP taking responsibility for the management of means of production and resultant resource distribution — a situation where the means of production is privately owned (by the member/customer), and located internally, but managed by a third party.
3) Question to you about the "Accessible / Consumed by" descriptor: you've made the distinction one of trusted versus untrusted. Is this an issue of identity, authentication and access only? Is this an issue of assurance that the consumer has the ability to pay for service (e.g. a valid credit card)? Means of access is sufficiently secure? It wasn't addressed in any detail, so I'm not sure precisely what it means.
= R
Doesn't the HPPIE model also require a point of reference from the organization and the provider before Trusted and Untrusted can come to play?
An example would be two internal divisions of a Mega-corporation who have seperate support teams that classify the other as Untrusted. Wouldn't a cloud provider see the Mega-corporation as a single entity although there could be two seperate contracts for the divisions with different personnel permitted to the cloud. If the cloud provider is contracted to do the work can the same staff member of the cloud be permitted to access the different systems if they are deemed to be untrusted of each other?
One man's "Trusted" is the other mans "Public"? hmmm.
OK. Here are my additional thoughts/questions…
Looking at the "Private" model.. Is the use case of a system managed by an organization but owned by a 3rd party and located externally a feasible one??? I don't think so but am open to being corrected.
I grok the public, managed, and hybrid models but private just doesn't feel right… For example, only the private model cares about trusting or not trusting the consumer. I think you could make a case that trust or not trusting the consumer doesn't really matter – the level of authentication/validation is driven by the requirements of the application/service not by delivery model.
Maybe if you kick 3rd party out of the private model in the "owned by" column that makes more sense… The alternative (which I still submit doesn't make sense) gets covered in the catchall hybrid model…
I'm also feeling stronger as I write this that trust/non-trust doesn't matter… But, again, I'm open to discussion.
I think you're suffering from the constraints of a 2D table.
You can have a Private cloud managed by a 3rd party, owned by a 3rd party, located both internally and externally, and still only be consumed by trusted sources within the organization. So what differentiates Hybrid from that?
Same story with Managed.
Post the source for the table, will ya? That way we can submit alternatives. 🙂
@Aneel
Ah, in the case of private clouds, those little blue lines are critical in the table.
The blue lines represent distinct linear branches of service deployments whereas the use of "or & and" in the hybrid model indicate that both parties can manage/own in combination.
So in the case of Private, this means you can have:
Private : organization-managed : organization-owned : Internally-located ||
Private : organization-managed : third party-owned : externally-located
Private SPECIFICALLY denotes ORGANIZATION management, not third party.
Managed means the opposite.
I had to make a distinction between public and private with managed.
Hybrid is a free-for-all.
I wonder if I put little arrows denoting a path in the table if that would help.
The Table is an image from a PPT slide I created…if you want, I can put it up…
/Hoff
@Armorguy
Absolutely! I have customers (or had) doing it today. Here's an example: you outsource what amounts to your Intranet to GoGrid using what amounts to their co-location model with scale/utility billing added to it. You manage the stack…they provide the hardware. You VPN back to HQ.
Perhaps I should change "Owned by" to "Infrastructure Owned By"…check out the arrows I added to clarity
But Private Clouds are absolutely valid in either model…perhaps not well adopted as of yet, but I feature them in my Frogs presentation.
Perhaps a friend's comments to me need to be made as a disclaimer…"I'm playing 3 dimensional chess on a 2 dimensional board."
/Hoff
OK, let me just suggest this then..
Use "on-premises" or "off-premises" to denote physical location of the infrastructure. That's what's really important and (even better) it frees us up to..
Use "internal" or "external" to describe the users of the service as they relate to the organization. "Trusted" is such a loaded word that I think you might want to avoid it… I don't "trust" my users any more than I "trust" my customers. 🙂
Combining that with your use of those nice directional arrows gives me a more solid feeling with where you are going…
@Beaker Yeah, put up the ppt.
I disagree with this: "Private SPECIFICALLY denotes ORGANIZATION management, not third party." I'd rather that Private primarily denote that access is only to "Trusted" things.
I think it's possible to have a single table like yours that makes sense from every angle, but not the way you've got it. Who does the managing can't be defining characteristic for that to happen. The defining characteristics have to be functional (not operational).
@Aneel
I don't understand your comment "Who does the managing can’t be defining characteristic for that to happen. The defining characteristics have to be functional (not operational)." In fact, I maintain it's critical.
If "management" includes the definition of and in many cases (like the Go-Grid example in the comments above) operational roles of crafting and executing policy, then it HAS to be a factor in definition, just like ownership is.
In the table, private already designates "trusted" use.
I've updated the table, check it again…
I'm going to go noodle on your points. Whenever I can't visualize a gap in thinking from someone like you with whom I normally agree, I know I'm missing something.
@beaker
Let me just ask this, if I put a blue line with Organization / Third party provider in the "Managed by" column and under "Public" in the "accessible and consumed by" to "untrusted" only, would that work?
If I do that, then I just need a better definition of "trusted" — if I remove the "…governed customer/members" but at the end it could encompass "authorized" users that are not governed as a logical extension of the organization…
While I'm still not a fan of the "trusted/untrusted" terms (but understand and agree with the concept) I think that I agree with your model here…
To make this clearer to folks who haven't been in the sausage factory all this time I'd suggest perhaps putting real world examples with each model (much like you did for me earlier in the comment stream) to help people visualize how the model plays out.
The notation of the trusted/untrusted has teeth with the clarification of the company extensions versus the end user or target audience.
I still have the tendency of classifying these as "green", "yellow", "blue", and "red" but that is somewhat old school for the big cloud.
Excellent discussion. For a given client we may see:
Marketing Analysis: Amzaon using Paas/IaaS for Marketing Analysis (Hybrid,External)
HR: Employease using SaaS (Public, External)
Finance: SAP using (Private/Internal)
@Beaker Getting better in that you're covering more cases.. but worse in that confusion is rising.
What about 3rd party, 3rd party, off-premise, trusted and untrusted?
I'm stickin' with my line that "Managed" doesn't make a good row. It should be just another attribute, not a major division.
@beaker Here ya go! This is admittedly stupid, but I think that: 1) you have to be able to cover all these (or most of them) scenarios and 2) the isolation and management issues are just characteristics.
@beaker meh.. I guess embeds don't work in comments. Here's a link.