he topic of private clouds is heating up. A private cloud is, essentially, a cloud computing capability dedicated to one organization. The term "internal cloud" is often used for this kind of functionality, but as many people point out, the term "internal cloud" conflates functionality with location. That is to say, one can imagine a company's cloud that is physically hosted at an EDS site—the equipment, infrastructure, cloud computing software would all be dedicated to the customer company, which would make it a dedicated, or private, cloud, despite the fact that it is not located within the company-owned-and-operated data center. Therefore, private cloud is probably a more appropriate term, and is the one used throughout this post (and subsequent post, which will address private clouds from the perspective of the cloud user).
Now that we have the terminology straight, what constitutes a private cloud, beyond being dedicated to one using organization?
The easiest way to characterize a private cloud is to identify its functionality as being similar to a public cloud, except that it is not available for use by just anyone. While there are many definitions of cloud computing, I like the one from the Berkeley RAD Lab's cloud computing report, which I recently discussed here. The RAD Lab report says that cloud computing has three characteristics:
1. Huge Resources: Computing resources are available upon demand and appear to be infinitely scalable, thereby enabling highly agile and scalable applications.
2. No Commitment: Computing is immediately available and may be used without the commitment to an on-going or long-term agreement.
3. Pay By-the-Drink: Users pay only for the computing resources actually used; when resources are released, no further payment is required.
Note that the RAD Lab specifically states that they do not consider internal (i.e., private) clouds to be "real" clouds, since there is inevitably some point at which additional resources are not available, as when an individual company runs out of room in its data center.
What this implies for private clouds is that they should offer the same functionality: highly scalable for applications that require lots of headroom; no commitment beyond actual use, with dropped resources no longer charged to the former user of the resources (i.e., once I'm done with one or more virtual machines, I shut them down, and am no longer charged for them); and payment tied to actual resource consumption.
It also implies that IT organizations will implement a clear-cut distinction between infrastructure provision and cloud services consumption. That is to say, a clear demarcation between granular services provisioning and computing resources consumption is necessary. If you view my graphic representation of this concept, you can see that it portrays a private cloud, divided between core IT infrastructure cloud provisioning and business IT (i.e., application creators/users); the dark line halfway down the figure indicates the areas of responsibility.
I've taken a different approach to describing private cloud computing. Most other discussions of it focus on the hardware and software components that are used to create a private cloud. In this approach, I've chosen to focus on service capabilities, since a functional characterization is, in my view, really key to understanding the fundamental capabilities that the cloud consumer (i.e., Business IT application group) expects and the granular services that the cloud provider (in this case, the private cloud provider, aka IT infrastructure services) must deliver.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.