Defining Private Clouds, Part Two

As noted in last week’s post, private clouds are a hot topic these days, but not everyone agrees on a definition or the potential benefits. In my view, building a private cloud offers:

1. A role for existing infrastructure: Instead of treating data centers full of equipment as obsolete junk, a private cloud can incorporate existing infrastructure into a new, internally-located cloud.

2. Application agility and scaling: One of the key challenges for internal data centers as traditionally managed is the inability of individual applications to grow readily when confronted with large increases in traffic. Likewise, applications offer poor economic performance when resources are put in place to meet peak demand and remain dedicated to an application even when no longer necessary. In essence, in traditional practices, resources are sticky — difficult to get moving and hard to eliminate. By putting a private cloud into place, applications that need additional headroom will no longer bang into an equipment ceiling and suffer from poor performance.

3. Lower security and privacy risk: Many IT organizations are reluctant to move much of their data to shared public clouds due to a concern that there might be risks that wouldn’t exist if the data were held within the corporate data center. By implementing a private cloud, these concerns are obviated.

From a 30,000 foot level, what’s not to like about this vision? All the benefits of cloud computing, with none of the drawbacks of public cloud services.

However, little detail is available from the 30,000 foot level, and when the details are examined from a closer vantage point, many of the key characteristics necessary to implement a private cloud come into focus.

This series of blog posts examines the requirements that accompany a private cloud so that IT organizations will have a better understanding of what actions they need to take to achieve their cloud computing vision.

The fundamental fact that comes into play is that private cloud functionality imposes a dividing line between IT inventory provisioning and IT resource consumption. In terms of the groups associated with these two activities, they may be identified as data center operations and business application groups. The vision of cloud computing is that someone in the latter group, who wants to create or run an application that requires IT resources, can push buttons (on a mouse, of course!) and have them provided—all without human interaction. The data center operations group’s responsibilities lie in ensuring that sufficient resources are in place and available to be called upon at a moment’s notice.

Last week, I discussed the responsibilities and key service capabilities needed by data center operations (or IT infrastructure operations, to give it a more formal description) to implement cloud computing. This week, I examine private cloud functionality from the perspective of business application groups; in other words, what services need to be in place for cloud computing to be in place for these groups. You can refer to the chart that accompanied last week’s posting to follow along the discussion below.

The right way to read the chart is from the center out. The hardware and software resources that intertwine both groups are located in the chart’s center. This reflects the fact that IT resources are the basis of cloud computing, and that both groups are involved with them—but with very different perspectives about them, and a very different ways of interacting with them. Nevertheless, hardware and software resources are at the center of cloud computing, because it is, ultimately, about a different way to marshal and deploy IT resources. The different perspective and different interaction mechanisms are denoted by the black broken line that runs across the chart horizontally: below the broken line, the services are those germane to IT infrastructure operations, which must put functions into place to support cloud computing; above the broken line, the services are those necessary for application groups to use cloud computing as part of their application activities.

The next level out (above) the central resources represents four key functions (or services) that must be in place for business application groups to take advantage of cloud computing. These four services are:

Agile Provisioning: Agile provisioning is what many people consider the totality of cloud computing. Agile provisioning means IT resources can be requested on a dynamic basis through some kind of automated system. The premier example is Amazon Web Services: Getting a working virtual machine up and running can be accomplished in less than 10 minutes. What this implies for an internal cloud is the ability for an IT resource user to instantiate compute resources as quickly as he or she can from Amazon. In essence, the demand for agile provisioning a la Amazon is analogous to the pressure IT groups felt when end users kept pestering them about why the company’s internal apps weren’t as easy to use as web-based apps or products like iTunes. In this case, Amazon Web Services has set a new expectation about how quickly IT resources should be ready.

The vision for agile provisioning is that a resource user should be able to access a web page and on-the-fly configure a new application infrastructure—a certain amount of compute resource, memory, storage, and network bandwidth (actually, the latter is probably not configurable, since most data centers have consistent bandwidth capability, which today means 1Gb or 10Gb). In practice, it’s unlikely that there will be unlimited flexibility of resources; more likely is something like Amazon, where you get to choose from three or four different capability configurations, a sort of small, medium, and large arrangement.

Key to this agile provisioning is the concept of orchestration, where a single request can coordinate a number of different actions, all coordinated to create the desired outcome. One can think of this as a coordinated business process; this orchestration reaches out to the virtual storage, network, and machines inventoried by IT infrastructure operations to create a complete compute instance for the requester. It can’t be emphasized enough how critical this is to the concept of a private cloud; without agile provisioning private clouds devolve down to nothing more than more efficient IT operations, rather than making IT more responsive to business initiatives. Expect much more emphasis on this subject as the concept of private clouds gets further awareness.

Application Management: Since much of the impetus for private clouds (and public clouds, for that matter) is to move control of computing closer to the users, a key function that must be available to business application groups is to be able to monitor and manage their applications. In some sense, the role of operations is bifurcating, with infrastructure operations remaining with the data center operations group, and management of the software components that comprise an application residing with application groups.

One can expect this to be a messy transition, as operations today spans applications, core frameworks and components (e.g., databases), and hardware. Echoing Amazon, where Amazon maintains responsibility for the compute infrastructure, while application developers are responsible for the application components, look for application management to transition above the line. Again, this is a service available to the application group, which will be able to more directly control the software components it has deployed to meet business goals.

Scalability: Cloud users expect application topologies to expand or contract as needed to match application needs to resource availability. Put another way, it must be easy to make the amount of compute resources devoted to an application to be congruent with compute load. As traditionally practiced, this is one of the least flexible aspects of data center operations. Because compute resources tend to be sticky, applications often have insufficient resources available as needed, with little ability to modify resource availability in an acceptable timeframe.

In the world of private clouds, application groups expect that it will be easy to add or subtract resources as appropriate; in fact, application groups expect that the application management system will monitor system performance and resource use and automatically adjust the resources available to an appropriate level.

Chargeback: The ability to charge according to resources consumed rather than a fixed amount of assigned capacity. The concept of chargeback being an integral part of private clouds is controversial. Some maintain that very granular pricing must be in place for cloud computing to operate effectively; others maintain that the mode of payment is incidental to the scalability and flexibility of commitment that are the true hallmarks of cloud computing. The typical practice in place for internal IT today is that, upon request for compute resource (e.g., a four-processor machine with 16 GB of memory, 50GB of storage, and 8 NICs) a capital charge is applied, meaning that an overall cost for the acquisition of the system (perhaps $8,000 in this case) is transferred from the requesting group to the IT organization; in addition, the overhead costs for the IT group (headcount, facilities, etc., etc., down to the donuts put out every Friday) are applied, pro rata, to IT-consuming organizations.

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

Follow everything from CIO.com on Twitter @CIOonline