Menu
Defining Private Clouds, Part Two

Defining Private Clouds, Part Two

Your guide to public vs private

The common vision for private cloud chargeback is that a standard cost for highly granular IT resources (e.g., compute hours of a medium-sized configuration) are charged to the consuming application, which is paid for by the business group responsible for the application. Left out of this vision is how overhead would be handled in a private cloud.

Some feel that overhead should be factored into the granular pricing; others feel that the current overhead cost arrangement should be continued, while granular resources should be charged on a usage basis.

My view is that chargeback is very important, not because it's "fairer," but because price is an important rationing mechanism-and rationing computing resources will be more important in an environment where obtaining resources is as easy as filling out a web form, whereupon the resources are automatically provisioned through the orchestration mechanism in place. This brings us to the next level out in the chart.

The next level out is not software components that support a user view of private clouds; rather these elements are organizational artifacts or processes that need to be in place to support private cloud computing. To reiterate something I've said in this piece and the previous one, cloud computing requires that manual intervention and human interaction be removed from the request, assignment, and consumption of compute resources. Absent the removal of the traditional "resource request and approval" meeting that leads to someone in the ops group assigning resources, organizational processes need to be put into place that enable those kinds of checks and balances to be performed outside the automation system -- that act as an input to the automation system and can by dynamically checked for "approval" by runtime systems. The level to which we are referring reflects those processes.

The linchpin at this level goes by the term governance, which covers institutional processes in which important approval processes along with minimum approval requirements are defined, along with whatever organizational groups are involved in the approval process. So, for example, IT organizations often have an Open Source Review Board to which requests to use open source software components are submitted; the OSRB reviews the requests in light of the established Open Source Policy to determine whether to approve the request. The combination of policy, process, and organization constitute open source governance.

With respect to cloud computing, governance addresses how the organization decides who gets to request compute resources, how the request is approved, and so on. All of this takes place before the actual physical act of filling out the web-based request form. The rules that govern resource request need to be captured in rules (i.e., in a policy engine) that is integrated with an identity management system to implement resource requests that align with approved cloud policy. In short, governance sets the boundaries within which requests for cloud resources are allowed, which facilitates the automated processes of resource assignment. One way of thinking about this is that it takes the existing, relatively unstructured organizational processes in place for resource assignment and structures them in a format that can be captured in automated rules, while putting into place a governing body that monitors the overall system.

A key input to this is the Legal and Regulatory constraints on the organization regarding computing and, particularly, data handling and storage; this organizational process is depicted to the left of Governance in the chart. To get a feel for the issues involved with this, read the Cloud Security Alliance's recent report. However, for private clouds to come to fruition (or, for that matter, for public clouds to do the same), privacy constraints regarding data storage must be codified and captured in a form amenable to automation. Again, if a meeting to discuss where the data should be located must be called half-way through the provisioning process, there's a hole in the fabric of the cloud. The legal and regulatory constraints the organization operates under must be defined and put into rules, which can be executed during the provisioning process. I know it seems like I'm banging on about this automated stuff, but this is an area where advocates of private clouds and experts in security have not yet thought through the implications of their recommendations. Believe me, unless privacy (and the overall approval process that is contained within governance) is automated, you don't have cloud computing.

Also at this layer of private clouds is the SLA function; this is depicted to the right of Governance in the chart. An SLA is, simply stated, a business agreement about the level of compute performance expected by the using organization and delivered by the operations organization. This is nothing new. SLAs are a staple of outsourcing agreements and are often in place for internal IT as well. The only difference in a private cloud is the potential impact of an automated fabric and the cloud-architected apps that reside within that fabric. It may very well be the case that SLAs may need to be adjusted to take into account the cloud computing environment in which the applications operate; surprisingly, the adjustment may very well be up, in that cloud-architected apps are often less vulnerable to hardware failure due to scalability design that is built into the app. In any case, SLAs need to be addressed, because availability expectations are always present and therefore need to be delineated.

This completes the review of the private cloud seen from the perspective of the business applications group.

To summarize our journey thus far:

Moving to cloud computing within an internal data center offers the opportunity to gain many of the benefits of the cloud while avoiding some of the drawbacks like data privacy issues and reliance on unproven external providers. Moving to an internal private cloud requires that manual, informal processes be defined and captured in rules to support an automated provisioning process. The need for automation imposes a split between data center operations (the provider of the cloud) and business application groups (the users of the cloud) who must be able to coordinate across well-defined service boundaries that are operated via automation. Many of the policies that are paper-based or implemented by meeting and verbal discussion need to be codified and captured in software to ensure that the services can operate and that the cloud fabric is unbroken.

In the next two parts of this series, I will address the pros and cons of private clouds and discuss the implications of the vision of private clouds from a cost and process perspective.

Bernard Golden is CEO of consulting firm HyperStratus, which specializes in virtualization, cloud computing and related issues. He is also the author of "Virtualization for Dummies," the best-selling book on virtualization to date.

Cloud Computing Seminars HyperStratus is offering three one-day seminars. The topics are: 1. Cloud fundamentals: key technologies, market landscape, adoption drivers, benefits and risks, creating an action plan 2. Cloud applications: selecting cloud-appropriate applications, application architectures, lifecycle management, hands-on exercises 3. Cloud deployment: private vs. public options, creating a private cloud, key technologies, system management The seminars can be delivered individually or in combination. For more information, see http://www.hyperstratus.com/pages/training.htm

Follow everything from CIO.com on Twitter @CIOonline

Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.

Join the newsletter!

Or

Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

Tags cloud computingBernard Goldenenterprise cloudHyperStratus

More about Amazon Web ServicesCSAetworkStratus

Show Comments
[]