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:
FAQ: Cloud computing demystified
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 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 eight 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 (for example, compute hours of a midsized 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.