Private Clouds, Multitenancy and Control
Update: The Amazon VPC example I originally gave in this post was confusing and in fact possibly incorrect in some ways. I have removed it.
Recently I posted a video explaining how we at Cisco look at the differences between internal and external clouds, versus private and public clouds. In short, Cisco believes that internal and external clouds describe where the resources underlying the cloud service reside. Private and public clouds describe where the cloud is defined and governed. Both of these definitions are from the cloud service user’s perspective, which is the perspective we believe matters most when rationalizing cloud investments.
I highly recommend that you follow the link and view the video, as I did a much better job describing the topic there than I have words to in this post.
The response was from my good friend Sam Charrington, VP of Product Management and Marketing at Appistry. In Sam’s post, he took issue with my focus on control as the core issue behind the private/public differential:
To illustrate the latter point, (James) provides an example of a unifying control system creating a “private cloud” from internal and external resources. This example is what I was primarily responding to, as it seems to label as “private cloud” an idea more commonly called “hybrid cloud,” primarily by virtue of the unified control system. This masks the “less private” (e.g. hybrid) aspects of the cloud and as a result (IMO) “muddies the waters.”…
…To extend James’ example, if I deploy a tool that allows me to “control” virtual resources from Amazon EC2 and GoGrid, either directly or via a broker, without having to utilize either offerings’ native tools, does that mean I’ve created a “private” cloud based on these “public” cloud services? Amazon would like you to think so. Most enterprises would not.
First, let me say that the overlap of private and hybrid clouds is something we struggled with for a long time. In the end, though, most people think of hybrid clouds as combinations of internal and external resources, even if they use the terms “private” and “public”. Hybrid cloud computing is about where resources reside, not about cloud operations.
There is plenty of room for a private cloud to start out as an internal cloud, but evolve into a hybrid cloud, or even an entirely external cloud.
Furthermore, I think Sam misses the gist of what I meant by “control” over a private cloud. Just having start/stop and provisioning control over resources is not enough. A management tool typically doesn’t create the unique domain that a private cloud requires. That’s the concept that is key here.
By the way, Sam’s definition of private cloud is actually very good:
I define “private cloud” as a system exhibiting cloud characteristics, but operated for/owned by/contolled by a single organization. As mentioned in previous posts, I believe tenancy…is a key determinant of “privacy.” By tenancy I’m referring to who the cloud is “operated for.”
So there is NOTHING about the way Cisco describes private cloud that disagrees with this. A private cloud, in Cisco’s view, is a “single buyer”* construct–logically. I think where Sam and I may differ here is tenancy of the underlying infrastructure delivering the service or resource.
I gather that Sam thinks that if resources come from systems that are shared with other private clouds, or public clouds, then they cannot be virtual private cloud resources. I think that the logical use of those systems in a “single buyer” fashion as part of a larger logical whole means they have to be considered a part of the private cloud–a hybrid implementation of a private cloud.
What do you think?
* I use the term “single buyer” instead of “single tenant” here because a corporation buying external resources for their private cloud could be delivering them in a multi-tenant fashion to multiple BUs, etc.