The Essence of Cloud

The industry roils with definitions and explanations of cloud. These definitions come from product vendors cloud-washing their products, cloud providers positioning their cloud infrastructure, IT teams attempting to cloud-paint their efforts in virtualization, and even from consultants writing articles like this.

This article will examine the essence of cloud and will provide a solid working foundation against which progress toward the cloud can be objectively assessed.

The Cloud Deployment Model

Cloud computing is essentially a deployment model that sets a new paradigm for how services are selected, provided and billed. The service consumers are typically computer-literate business units, application developers and IT capacity planners. Technologies that make cloud computing possible include: Internet access, a shared pool of virtualized resources and the ability to support an elastic services pool that can be turned on and off depending on capacity demand (this is achieved through a combination of capacity planning and technology).

So, what makes the cloud deployment model different from other deployment models (i.e. the platform oriented services or service provider models)? Quite simply, the cloud is defined by the following three components and technologies:

1. Self-selection of services,
2. Automated provisioning of those services, and
3. Billing for services ordered.

These deployment components are made possible by three key enabling technologies:

1. The Web interface,
2. Virtualized shared resources, and
3. The ability to support elastic demand.

A (Not So) Long Time Ago …

Historically, there existed two deployment models: platform oriented and service provider. The first generation was the legacy deployment model, where services where delivered based on a specific platform and nominated by a piece of hardware. This first-generation model required each service request to have not only multiple approvals through a chain of authorization, but also it inevitably resulted in a conflict with considerable backlog. As a result, each application, and its associated infrastructure, needed individual care and attention.

Success with this model is only achieved with considerable administrative effort with extensive backlogs and little opportunity for consolidation or repeatability improvement. In this scenario, costs were known only at the grossest level of total expense and were allocated annually as a budget overhead. Additionally, the concepts of elasticity and a virtualized or shared environment did not yet exist, while Internet access to administrative functionality was rare or non-existent.

The second-generation deployment model was delivered by the ITIL-based service provider model. This was structured with tiers of service through a service catalog with results delivered under the guarantees of a service level agreement. Within each tier of service, all infrastructure components had to meet quality of service needs, including performance, recoverability and availability. As for pricing, this model allows these functions to be performed at a determined unit cost per GB or per GHz.

The service provider model has significant advantages over the legacy application or platform oriented approach because this model forces a rationalization to a small number of tiers (typically three to five) differentiated by business aligned service attributes and delivered via a known and visible unit cost. This reduces IT administration to manage information from multiple platforms into three to five tiers while also encouraging cost-conscious decision making on the part of the consumer.

Alas, the provisioning effort with this ranges from days to weeks because of the multiple handoffs required for the approval process. This process can be further complicated if there is a need to acquire additional new resources. This second generation deployment model offered businesses the ability to consciously select services by cost but failed to provide a discrete invoice for these services. The service provider model implemented virtualized storage and servers as tiers of service; however, elasticity was only available through thin provisioning.

Administrative technologies made the ability to reclaim resources and return them to an available pool too complex for most organizations. Elasticity was achieved to some extent through the use of thin provisioning technologies but it was still a difficult task to release and reclaim unused or no longer used resources.

Present Day

This takes us to our third and current deployment model — the cloud.

Cloud computing is distinguished by three critical consumer-facing criteria. First, the cloud deployment model assumes that the service consumer is competent and able to select the appropriate services and the money to pay for it. Neither of these assumptions hold true in the legacy first-generation deployment model. In the second-generation service provider model, both these assumptions may be true, but more often the second-generation deployment model will include a significant “authorization” process because resources are finite and require consumption audits. Note that under the cloud deployment model, the service selection process may include some automated policy enforcement to replace the legacy authorization process.

The second criteria of the cloud deployment model, is the concept of auto provisioning. At once, this eliminates both procedural approval overheads and delays while also preventing technical configuration overheads and delays. Consequently, this allows for considerable labor cost savings.

Perhaps most importantly, consumer satisfaction runs rampant as requested resources are provided almost immediately following the request or, at worst, same day. Gone are the days of IT departments saying “no” or “that’s going to be difficult.” Now IT says “YES, and here’s what it will cost.” With the cloud, IT is no longer the denier of services but rather the enabler.

The third key element of the cloud deployment model is the requirement of a formal billing (and collection) of monies. With the first-generation deployment platforms and applications costs (especially at the unit level) were generally unknown. Costs for services were often an annual transaction seen as overhead at budget time. Under the second-generation deployment of the service provider model, costs were usually (but not always) visible at the time of service selection, and only in rare instances were they charged back at the service order level. Typically, second-generation models saw a similar approach to first-generation deployments with an annual budgetary cross charge of “overhead.”

Nothing Is Perfect …

Although the cloud is a big step forward, this model also has interesting issues, particularly when it comes to internal or private implementations. Once a consumer realizes that storage can be ordered in any quantity, they may not only order a generous helping, but they might double or triple the order just in case someone else jumps in and uses up what is left, leaving nothing for others to use.

This is a perfect example of why billing or chargeback is mission-critical to the cloud deployment model and why it is critical for this billing/chargeback to occur at the individual consumer level. Without this component, all resources could disappear overnight from a private cloud, and in the public cloud, a nasty surprise may await the CFO when the monthly bill is received.

As IT struggles to do more with less, the server virtualization arena is often seen as an opportunity to consolidate servers and reduce the number of hard entities under management, while showing senior management their commitment to “state of the art” cloud computing. It is not unusual for an IT team to define their virtualized environment as an internal (or private) cloud. Now, it is absolutely true that virtualization of platforms are an essential technology enabler to the cloud deployment model. Without the ability to pool and share resources, the cloud model is challenging to the point of impossible to implement; however, virtualized platforms are not the “essence” of cloud computing, but rather the enabling technology.

The essence of the cloud is the ability of the infrastructure to offer the consumer an automated capability to self-select the service/resource they want, to have that service/resource made available almost immediately, and to have those services billed to the consumer through a classic invoicing function.

The enabling technologies that support the cloud deployment model include Internet access/capability for service selection and service delivery monitoring, virtualization of the compute and storage environment to support shared resources, and the capacity planning skills and technology to support elastic resource allocations.

By understanding the critical components of the cloud and its enabling technologies, we see how the deployment strategies used in the first- and second-generation models have changed. With this understanding, IT and consumers are better prepared with a more realistic expectation for the transition ahead.