Hardware is now the new software. Well, at least some hardware-based network appliances (e.g. load balancers, routers and VPNs) are now available as virtual appliances leveraging off-the-shelf servers. This discernable push toward software form factors is occurring rapidly because rather than supporting commercial operating systems, appliance vendors are simply making their code available as virtual machines. Great. The more choices the better.
Next question: What hypervisor is supported? Ah, there’s the rub. Some virtual appliances only support a single hypervisor, and often only specific versions. If you’ve standardized on Xen, for example, but your virtual appliance of choice only supports ESX, then you have two options – neither of which is particularly attractive.
First, you can throw away your investment in Xen and migrate all workloads to ESX. Not very appealing. Alternatively, you can run a hybrid environment with a mix of hypervisors. Xen for some workloads, ESX for others. Perhaps more palatable, but still constraining. You’ll certainly fall short of achieving the holy grail of ‘any workload on any server.’ More practically, you’ll have to learn and support different management consoles, and may end up with pools of heterogeneous virtual resources.
The hypervisor is now the dog, and the virtual appliance is the tail. Sound backwards? It is!
Virtual appliance vendors should never dictate to customers what hypervisors they should deploy in their environment. The virtual appliance should accommodate the customer’s hypervisor, not vice versa. This not only preserves the customer’s investment in a particular technology, but it maintains the resource homogeneity promised by server virtualization.
Vendors will get there. But in the meantime, don’t let the hypervisor wag the virtual appliance.