Sunday 30 January 2011

Making Sense of Cloud Computing

The terms virtualization, utility computing and Cloud computing are often used interchangeably which can be very confusing. A new report I have just authored aims to provide clarification - to identify the similarities and differences in those characteristics, and provide a framework in which organizations can decide which capabilities they require in specific situations – as it is unlikely that one model alone will suit all their requirements.
A visitor from outer space would be forgiven for thinking that virtualization, utility computing and Cloud computing are different capabilities. But most of us understand that many product and service offerings use the terms rather casually and the trend is to assume they are all describing the same thing, where virtualization is synonymous with utility computing which is synonymous with Cloud. Some might say these are just steps in the evolutionary process – where utility has simply evolved into Cloud.
So, are they the same or different? Can the terms be used interchangeably, or are there clear distinctions between them?

The answer is not straightforward. There are clearly some common, overlapping characteristics that allow the terms to be used interchangeably. But at the same time there are other characteristics that enable them to be distinguished from each other.

The report aims to provide clarification. To identify the similarities and differences in those characteristics, and provide a framework in which organizations can decide which capabilities they require in specific situations – as it is unlikely that one model alone will suit all their requirements.

Capabilities

What capabilities are provided by utility and Cloud computing, and where does virtualization fit in? The figure below shows a layered ‘stack’ of IT capabilities and the relationships to Cloud Computing and Utility Computing capabilities.

Utility and Cloud Computing Classification

Utility Computing is the provision of infrastructure capabilities such as the server and operating system, compute capability, and storage on a pay as you go (PAYG) basis. In many cases utility computing utilizes server virtualization.

As the figure illustrates, Cloud Computing equates to Utility Computing in terms of the capabilities provided. As mentioned earlier, some might see this as a trend with Cloud terminology simply replacing utility. But Cloud Computing can provide these capabilities on a finer-grained basis that was typically the case with Utility Computing. Cloud also raises the levels of abstraction, providing a higher level of interaction for the consumer via utilities and a management layer that can make them easier to use than raw infrastructure, and provides complete virtualization of resources, usually with self-service provisioning on a multi-tenancy basis. In Cloud terminology these infrastructure resources are provided as Infrastructure as a Service (IaaS).

Note we are happy to recommend the NIST definitions of Cloud Computing, which we covered in a previous report.

Security capabilities such as authentication and identification, and networking and mediation capabilities such as message delivery, routing and transformation can also be seen as part of Utility Computing and also classified as IaaS. These capabilities can be combined together into a ‘platform’ and classified as Platform as a Service (PaaS). PaaS provides the IaaS capabilities via a higher layer of utilities, and not directly. Hence the PaaS can be said to encapsulate the IaaS capabilities.

Layered on top of the platform are the applications or ‘business’ capabilities. These might be broken down into client, business process and business function capabilities, but more often than not are packaged together as an application. Cloud providers don’t normally distinguish between them, and hence they are typically combined as Software as a Service (SaaS), regardless of the granularity or separation of layers.

The exception to this is Business Process as a Service (BPaaS). This is an emerging layer in which process assembly is offered as a service which allows the consumer to orchestrate services from disparate sources. BPaaS is therefore a specialization of SaaS.

PaaS is also used to characterize a suite (hence ‘platform’) of application functions that are exposed as service interfaces. For example Google Apps or Salesforce.com provide PaaS capabilities in addition to their core SaaS capability, to expose specific interfaces as a ‘platform’ on which consumers can assemble a custom application.

The use of PaaS and SaaS may be abused, and we advise that you interpret the capability offered on the basis of level of access and control - that is SaaS delivers applications with no opportunity to manage or control the underlying infrastructure or application capabilities. In contrast PaaS provides control over the deployed application and possibly the hosting environment.

Their use may also be seen as contextual. That is, as an end user of Google Apps the context would be SaaS, but as a developer using Google Apps as a platform on which to implement a new application, the context would be PaaS.

Use of a higher layer in the stack usually means the lower layers are inherited. Typically there is no separation of supplier down through the layers from the consumer perspective. That is, whilst the SaaS provider may in turn use a different IaaS or PaaS provider, this is transparent to the SaaS consumer. The exception here is BPaaS which we think qualifies it as a specialization precisely because it allows orchestration of disparate capabilities.

The term virtualization spans all of these capability layers. Cloud computing environments virtualize the capability at its highest level of abstraction in order to make the underlying resources location independent, more scalable, resilient, and so forth. In the Cloud context, virtualization is a generic term and it may be expected that server virtualization and server clustering technologies provided by platform vendors will be used to provision individual capabilities and resources supporting the Cloud service.

However, the same virtualization technologies may be employed wholly within an organization’s own private data centre, and so are not necessarily used to support Cloud behaviors (multi-tenancy etc.). Equally in house virtualization which is deployed with multi-tenant elasticity may reasonably be relabeled as a private Cloud.

Enabling virtualization is usually a necessary first step towards utilizing both utility and Cloud computing. If resources cannot be virtualized, how can they be deployed to the Cloud?

Characteristics


Most large enterprises will be commencing use of Cloud, but inevitably they will have a spectrum or continuum of capabilities deployed which span server virtualization, utility and Cloud computing. For most enterprises an early objective of Cloud initiatives will be to rationalize and modernize existing assets. A table I have compiled therefore provides a set of nomenclature which may assist in documenting and classifying existing and planned technology assets.

As well as considering virtualization, utility and Cloud, I have also included the notion of an outsourced data centre as a further option that many organizations will use. How does this compare to Cloud and Utility? I have also distinguished between public and private Clouds. A private Cloud will provide both utility and application capabilities. As the table shows, in some respects it might be hard to distinguish a private Cloud from a traditional data centre, or the outsourced data center if administered by a 3rd party. However, if it exhibits distinguishing Cloud features such as metering usage on a PAYG basis, providing capability on a fine-grained basis through an easier to administer interface, then it can be identified as a different model. You could further distinguish between Private PaaS/IaaS and Private SaaS provisions, but I don’t think that adds much to the model, as the only difference is the capability offered.

But beware provider organizations that may have merely relabeled these deployed assets with a more fashionable term!
 
Continued in the PDF version of the report  (free on registration)
 
The full report contains the table of characteristics discussed above plus a set of decision criteria and risk assessments that organizations should take into account when considering utility and cloud computing options.
 
You can also download the complete CBDI Journal which this month contains an associated report looking at Business Driven Cloud Strategy.

No comments:

Post a Comment