views:

81

answers:

3

I work for a small company with a .NET product that was acquired by a medium sized company with "big iron" products. Recently, the medium-sized part of the company acquired another small company with a similar .NET product and management went to have a look at their technology. They make heavy use of virtualization in their production environment and it's been decided that we will too.

Our product was not designed to be run in a virtual environment, but some accommodations can be made. For instance; there are times when we're resource bound due to customer initiated processes. This initiation is "bursty" by nature, but the processing can be made asynchronous and throttled. This is something that would need to be done for scalability anyway.

But there is other processing that we do that isn't so easily modified because we're resource bound for extended periods of time.

How do I convince management that heavy use of virtualization is probably not appropriate for us?

+6  A: 

If I were your manager, and heard your argument (above), I'd assume that you're just resistant to change. I'd challenge you to show me the data. You haven't really made a case against virtualization. You say that your product "was not designed to be run in a virtual environment". You're in good company, very few apps ARE designed that way. It usually "just works". And if it's too slow, they just throw more resources at it. If they need to move it, make it fault tolerant, expand or contract, it's all transparent. Poorly-behaved apps can be firewalled from other environments, without having to have dedicated hardware. etc., etc.,. What's not to like about that?

You should prepare a better argument, backed up with data from testing. Or you should prepare to be steamrolled by an organization with a lot of time, $$$, and momentum invested in (insert favorite technology here).

Chris Thornton
Thanks for the tough love; and for the humor.
uncle brad
The fact that you accepted this answer, tells me that you're do just fine. Good luck, and best wishes. Report back here in a year and tell us how it worked out! And thanks!
Chris Thornton
+2  A: 

Don't fight the methods, specify requirements.

Do some benchmarks on different sized platforms and establish a rough requirement guideline. If possible, don't say 'this is the minimum needed'; it's better to say "with X resources, we do Y work units per hour, with X', we do Y'. A host that costs Z$ can hold W virtual machines of X' resources", then the bean counters will have beans to count. If after all they decide that virtualization is cost-effective, they might be right.

Javier
You are correct about specifying requirements. I'm just concerned that specifying the requirements is going to be a "beat down". We currently run our build, dev, and QA in a virtualized environment; but this is very different than our production environment. My main concern is the effort required to be demonstrate/measure how well virtualization will scale.
uncle brad
+3  A: 

It sounds like you're confused about how virtualization works.

You still need to provide enough resources for your virtual machines, the real benefit of virtualization is consolidating 5 machines that only run at 10-15% CPU onto a single machine that will run at 50-75% CPU and which still leaves you 25-50% overhead for those "bursty" times.

If your "bursty" application is slowing down other VM's, then you need to put resource limits in place (e.g. VM#1 can't use more than 3Ghz CPU) and ensure that there are enough resources.

I've seen this in a production environment, where 20 machines were virtualized but each was using as much CPU as it could. This caused problems as a machine was trying to use more Ghz than a single core could provide but the VM would only show a single core. Once we throttled the CPU usage of each VM to the maximum available from any single core, performance skyrocketed. I've seen the same with overallocation of RAM and where the hypervisor keeps paging to disk and killing performance.

Virtualization works, given sufficient resources.

sascha
Your fourth paragraph is an eye opener for me. Thanks, I'm slightly less concerned now.
uncle brad
Was a real eye-opener for us once we figured out what was going on :)
sascha