Technology, Cloud

Cloud computing does not require virtualization

Blog-post by,

Nearly everything I read about cloud computing talks about starting your journey to cloud by virtualizing your environment. But it is not the only way to build a cloud. In fact, there has been a long-running mini-feud, albeit a polite one, between VMware and Google regarding virtualization for cloud computing. VMware claims that the cloud must start with virtualization.  

Google has long said it doesn’t virtualize. And for sure Google knows a little bit about cloud. They run their images directly on hardware. Why?  Performance.

Virtualization adds another layer of software. And every layer takes cycles to execute and therefore impacts performance. In addition, IO performance is the commonly mentioned sufferer of virtualization performance.  In Microsoft's blog post Hyper-V performance tests (SharePoint Foundation 2010) they document the performance degradation of using Hyper-V, their virtualization solution.

In his blog post, VMware Knows the Cloud Doesn’t Need Server Virtualization Gigaom’s Simeon Simeonov points out that VMware own tests show 8 to 12 percent overhead because server virtualization. He also notes that when virtual machines are competing for resources on the same server the overhead is “substantially higher.”

Automating the process of bringing up an image directly on a server is called "bare metal provisioning." So if your application requires maximum performance but you still want the advantages of cloud, you can have both.

A large US banking user I know provisions servers directly rather than virtualizing for a different reason. When you use an image it is only as compliant to your policies as the day the image was created. If the image is two months old and policies have changed, you need to provision those changes on the virtual image. This bank found it just as fast to provision the hardware from scratch as it was to load an image and adjust it.

Of course the real question that CIOs must ask when weighing this issue is:  What will be the most cost effective and bring the most productivity to my IT shop?  In many cases virtualization makes sense.  For other applications bare metal provisioning is the best answer.   


(2) (2)

Discussion
Would you like to comment on this content? Log in or Register.
cebess
Charles Bess 84 Points | Mon, 03/28/2011 - 14:06

I find it interesting how cloud is being thrown around like it has a single definition. Unfortunately, cloud means many things to many people and may require a bit of definition before its first use in any article. Fortunitely, in your title you stated you were talking about cloud computing. Some folks then go on to talk about Google Apps... which to me goes outside the relatively narrow range of cloud computing into the SaaS space.

Although I agree that Cloud does not require Virtualization, I do believe it does require abstraction, either at the hardware level (Virtualization) or at the software level (through SOA) or at the personnel and process level (through business process outsourcing techniques). I have probably just stretched the definition of cloud to the breaking point for some, but even BPO is multi-tenant, bill for use... It may or may not have hardware Virtualization under the covers. It definitely has a level of abstraction to put the needed veneer of consummation required to make it useful for the consuming organization.

If we're focused on computing only, the use of virtualization seems to be almost essential for most organization to get the abstraction needed.

adamson
Walter Adamson 0 Points | Sun, 03/27/2011 - 22:22

I appreciate Tom Henderson's points, even though I'm apparently on the other side of the generation gap he mentions as being part of the difference in understanding. 

I particularly like his nailing of Google Docs as "classic SaaS" "which isn't really cloud". Because when I hear people, particularly sales people, say cloud is nothing new and use Hotmail and Google Docs as examples it annoys me. Of course that is the sales pitch - nothing new, risk averse, we'll sell you some more tin and you can live happily ever after.

However here is the catch-22. I refer to Facebook as more representative of cloud, in it being a platform with high applications connectivity e.g. APIs and the Social Graph. But Facebook doesn't use virtualisation.

So where do I stand now? In Facebook's case Michael Procopio's arguments completely apply. But Henderson's cloud definition, which I said I like, means Facebook isn't cloud.

Who can help?

Walter @adamson
http://xeesm.com/walter 

jdodge
John Dodge 1368 Points | Thu, 03/24/2011 - 13:14

Welcome to the Enterprise CIO Forum, Michael.

Great post! Although you did not come right out and say it, I sensed you think Google's approach (if one cloud size fit all and of course it doesn't), avoiding virtualization can be more efficient and less complex. That 8-12% virtualization tax, if you will, is considerable.

Am I reading you right?

MichaelProcopio
Michael Procopio 18 Points | Thu, 03/24/2011 - 21:13

I'm nuetral on which is used. As Tom points out below if you can't keep a server busy virtualization is the way to go. But if you have 20 machines running the same application is might be a different story.

Tom Henderson
Tom Henderson 4 Points | Thu, 03/24/2011 - 17:09

I have to disagree categorically, and maybe it's a generation gap problem.

The cloud is conceptually made of "disposable hardware". Dedicated bare metal isn't cloud, in fact, it's the antithesis of cloud. Bare metal means you're using multi-core machines and wasting their CPU power, sucking electricity, and wasting resources. You took a long time to provision the machine on bare metal, because you're forced to iteratively patch first the OS and secure it, load the app platform and secure *that*, then load the application code and data. Not using a VM is like using eleven unions to change your tires.

Google hosts applications, which is a variant of cloud, e.g., hosting of persistent applications. It's not really cloud, as part of cloud mandates disposability. GoogleDocs are just hosted, on-demand office automation applications. You *could* go away when you're done using GoogleDocs, but more likely, you'll continue to use them contextually in your organization's daily work life. It's classic SaaS, which really isn't cloud-- it's hosted app-on-the-hoof.

Virtualization is mandatory in the cloud because the currency of the cloud relies on rapidly deployed instances that are optionally snapshot, then disposed of in the classic job-control sense. Persistent jobs can be hosted but they follow a different concept. NONE OF THEM imply bare metal. Bare metal hosting is used for persistent apps only; VMs are used for load balancing, libraries, non-persistent apps, development, patch/fix testing, and so on. 

Servers today come most efficiently in multicore platforms; most OS platforms can't use the cores efficiently for a single instance. These servers are designed and built with virtualization in mind, and using bare metal for single instances is a huge waste of their musculature. 

Bottom line, SaaS isn't really cloud-- it's just another name for hosted applications that are generally persistent in their usage model. True clouds rain, and evaporate. You fire up VMs, do work, get the data, then the VMs get archived where necessary and the hardware substrate becomes once again available for something else.

MichaelProcopio
Michael Procopio 18 Points | Thu, 03/24/2011 - 21:26

Tom,

Thanks for commenting. Good points, particularly the one on Google.

As I mentioned in my reply to John, if you have an application that fully consumes X servers but at times you need to expand that to more servers, bare metal provisioning is a good choice. One could call that SaaS versus cloud. In my original post on the same topic I note that NIST's definition of cloud never mentions the word virtualization.

To your point on provisioning, I think the times to get the system would be about the same; that's certainly what the user told me. Consider that if you create a VM of a system patched to 1 Feb, how is that different than creating a hardware bootable image of the same system?  As we get to 1 March, 1 April etc -- you either have to add patches when you bring it up or take a new snapshot.

Clearly if you have applications that can't keep a single server busy full time you are complete correct.