Isn't it time for us to have a blueprint for IT?

Blueprint4IT

Subscribe to Blueprint4IT: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Blueprint4IT: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Blueprint4IT Authors: Lee Cullom, Jeremy Geelan, James Houghton, Elizabeth White, Tony Bishop

Related Topics: Cloud Computing, Virtualization Magazine, Blueprint4IT

Blog Post

Virtualization Does Not a Cloud Make

Cloud Computing is not about any particular technology, but rather is a new operational model for the delivery of IT services

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.

More Stories By James Houghton

James Houghton is Co-Founder & Chief Technology Officer of Adaptivity. In his CTO capacity Jim interacts with key technology providers to evolve capabilities and partnerships that enable Adaptivity to offer its complete SOIT, RTI, and Utility Computing solutions. In addition, he engages with key clients to ensure successful leverage of the ADIOS methodology.

Most recently, Houghton was the SVP Architecture & Strategy Executive for the infrastructure organization at Bank of America, where he drove legacy infrastructure transformation initiatives across 40+ data centers. Prior to that he was the Head of Wachovia’s Utility Product Management, where he drove the design, services, and offering for SOA and Utility Computing for the technology division of Wachovia’s Corporate & Investment Bank. He has also led leading-edge consulting practices at IBM Global Technology Services and Deloitte Consulting.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.