In a previous post we discussed the positive shift in the cloud computing discourse towards actionable steps rather than philosophical diatribes on definitions. And to support that discussion we offered the following list of things not to do:

1. Not understanding the business value
2. Assuming server virtualization is enough
3. Not understanding service dependencies
4. Leveraging traditional monitoring
5. Not understanding internal/external costs

As we continue our discussion of these missteps, in this post we'll address both a mistake and a common misconception.

Cloud computing is not about any particular technology, but rather is a new operational model for the delivery of IT services. Make no mistake: technology and implementation decisions have the potential to radically change your IT financial models by increasing IT efficiency. But this does not mean that specific technologies are requisite components of a Cloud.

Virtualization is one of those technologies frequently associated, and sometimes thought to be synonymous, with cloud computing. Moreover, if you asked a group of 20 IT professionals to define virtualization, the overwhelming majority would reply: "VMware." Together, these misconceptions perpetuate the notion that an organization can realize a cloud delivery paradigm by exclusively leveraging VMware or other comparable virtualization technologies. But this notion is false - VMware certainly deserves praise for their marketing prowess in the cloud space, and for providing a powerful, cloud-enabling technology. But implemented alone, VMware is not a cloud; it is a recipe for more operational headaches than you already have.

Let's start by refining our understanding of virtualization. VMware, Xen, KVM, and HyperV provide server virtualization. They facilitate ease of provisioning and movement of application workloads, and enable the sharing of an individual server's resources among multiple applications. But is that the only thing we consider when we deploy a solution? What about networking and storage? How about middleware and the data consumed by the workload? What about the application itself?

We have been virtualizing at the server level since MVS was invented for the mainframe. We've been virtualizing networks for the past 20 years. In the past decade we've begun to aggressively virtualize storage platforms as well, so none of those bear further analysis in this forum. However, when we ask people about middleware, data, and application virtualization, their resultant blank stares suggest that more examination is warranted.

Middleware virtualization is an imprecise term without a universally accepted definition. In this context we mean the true decoupling of the APIs that handle scalability, high availability, etc., from the runtime platform that provides those services. If you are familiar with the now-passé technology for grid computing, you know exactly what we mean. Why does this matter for the cloud? Horizontal scaling for web applications by simply overprovisioning (current approach for most deployments, cloud or not) is easy to do, but it's inherently inefficient: it is time-consuming to continually provision/de-provision resources, and underutilized infrastructure in the run-time environment goes wasted most of the time. Those familiar with middleware virtualization know those parameters are configured once during deployment, and actions are fully automated thereafter. Consequently it is much quicker to react to changes in demand.

Data virtualization is a simpler concept: what happens when your workload needs to access a large data repository to execute? Sure, it runs great when that repository is across the data center, but what about when it's on a different continent? Does it really make sense to leverage additional resources that are a great distance away if the price you pay for network latency (speed of light is a bummer) outweigh the performance benefits of adding more servers? At the simplest level, data virtualization is a way to make the data appear local to the computing resource. If the benefits of that aren't immediately obvious, you've probably logged on to the wrong blog.

Last, but certainly not leas let's explore application virtualization. Like middleware, it lacks a well-accepted definition, so we'll attempt to keep it simple. Application virtualization technologies specialize in the packaging and deployment of complete application run-time environments (think web, application, and DB) independent of any particular execution platform. In terms of execution platforms, think x86 servers running Linux, Microsoft, Solaris, other proprietary Unix platforms, or even a public cloud IaaS service like EC2. Wouldn't it be nice to package once and provision anywhere, and to do so manually or automatically based on time-of-day or real-time events like a failed resource?

In closing, we would like to re-emphasize a couple of points:

• Virtualization does not equal cloud
• Virtualization is much more than VMware

Virtualization at all levels - what we affectionately term holistic virtualization - can significantly increase the resource efficiency, the responsiveness to demand fluctuations, and reduce the level of effort your team will need to put into supporting your cloud environment.

In our next post we'll explore the next topic on our list:  service dependencies.

• Business Value and Cloud Computing
• Adopting Virtualization is Not Without Friction
• Information Assurance Does Not Equal Information Security
• Cloud Migration Is Not Enough