logo

Egenera has numerous hosting clients that use the Processing Area Network (PAN) architecture (and PAN Manager software specifically) to improve competitive advantage for their businesses. One of our largest customers leverages Egenera as part of the foundation for the fastest growing segment of their business - ascending to the top spot in Gartner's Magic Quadrant. When I ask system administrators about their biggest challenges in deploying virtualization within their hosting infrastructure, they tell me it all comes down to politics and misconceptions. "Many application owners want their apps hosted on dedicated boxes" is a common response. They want dedicated servers that they can point to and say, “That server is mine. It will never go down because no other application can touch it. Performance will be good because there is no hypervisor overhead. It’s mine, all mine!" The problem with this philosophy is that it is bad for business and even worse for the application owner. Let me clarify:

1. Dedicated hardware leads to server sprawl, underutilized CPU and memory. Multiply this dedicated hardware by 100 or 1000 and now you have a big mess. In the long run this mess (multiple cables, switches, disks, HBAs, KVMs, tape drives, etc.) brings overall availability of dedicated hardware to below shared hardware. Shared hardware is consolidated down where physical mess is replaced with easy to manage software.
2. Dedicated hardware costs money. Lots of money. Not just the capital expense of the box itself but the power/cooling and operating expense associated with managing all the complexity around it. IDC says for every $1 spent on hardware it costs $0.50 to power and cool it yearly.
3. Dedicated hardware cannot grow capacity as the application requires it. If your application is on a 2-way dual core 8GB machine, it may take months of downtime to get an extra 4 cores and 8GBs of more memory.
4. Dedicated hardware is ineffective for disaster recovery. If your application is tied to a specific box and cannot easily move to another server that is different (CPU, memory, driver, chip vendor, network and SAN cabling varies), verifiable DR is nearly impossible. Basically you are doubling physical complexity and doubling the management headache. Every time system administrators need to conduct a change control it has to happen twice. 70% of DR plans today require 100+ steps to accomplish a single server replication. This is because of physical complexity tied to the dedicated box.
5. Dedicated hardware is not necessarily faster than shared pools of resources within a single box. For example the Xen hypervisor provides close to bare metal performance. Most apps are not CPU bound but IO and memory bound. Certain hypervisors out there play well with this type of profile.
6. Dedicated hardware is not necessarily better for high availability. If your application is tied to a specific box, model, make and speed and if that box fails and you do not have complicated clustering in place, you may be down for days.
7. Dedicated hardware is not necessarily better for security. A little lonely box just wouldn't get the same kind of attention that the big honker in the corner gets. The issue could be in the partitioning though. But a bare metal hypervisor resolves that by isolating one server from another. If one crashes the others are unaffected.

Bottom line is that system administrators are burdened to educate the business on how virtualization can decrease expenses, provide a competitive advantage and take data centers from cost to profit centers. There is no silver bullet to solving this challenge. What I suggest system administrators do is deploy an architecture that can allow applications to go from physical to virtual (VMs that are bare metal partitions and NOT hypervisors) and back quickly and with little downtime. Do not tie applications to a specific box or box type. Remove the state from the equation. If you can do this, then you can persuade your application owners to first try deployment on bare metal partitions (we call them vBlades). They get verifiable DR, better management, better asset utilization monitoring, and capacity on demand in minutes out of the box. If the application owner decides that they really really need a physical box later (and the monitoring data that you have in hand proves it), you can move them over to that setup quickly. It all comes down to deploying that next wave of virtualization ("think Virtualization 2.0") infrastructure and taking the time to educate your end clients!