A question I often hear is “Why don’t you just move load balancing/application delivery into a virtual appliance model?” My answer is almost always “That’s the wrong question.” The question that should be asked is “What are the potential impacts to the infrastructure and application?” Because the whole point of deploying an application delivery solution – virtual appliance or hardware – is about improving some facet of the infrastructure in order to better deliver your applications. So in order to determine whether using a virtual appliance is a good idea or not you have to ask what the impacts might be to both the infrastructure and the applications it should be delivering, and go from there.


As noted by analyst John Abbot of the 451 Group in his report, “Break Point – Virtualization and Availability” there is a danger in starting a virtualization project without an availability strategy because the likelihood of downtime actually increases with virtualization because more work relies on fewer (physical) servers.

It’s kind of like Christmas lights – if one physical server goes down due to hardware failure (and that’s inevitable, by the way, given enough time) all the applications/workloads hosted on that server whether virtual or not are going down. Hard.

Thus it makes it fairly hard to swallow an architecture that puts critical infrastructure in a virtual appliance on the same physical hardware.  

Assuming you don’t use the same physical hardware (and that you have control over that when deploying in a cloud-based environment, which is not a given at all) then you may  not need to worry about that but you do need to worry about other impacts.


Not even diving into the difference between hardware accelerated and software-driven application delivery functions (and do not start with the “quad core servers can do it just as fast as hardware” because in a virtualized cloud environment you aren’t getting compute resources based on performance, you’re getting it based on capacity) the question of overall application performance (not to mention costs) via such an architecture must be questioned.

Imad Mouline offers an excellent overview on Why Assumptions About Cloud Performance Can Be Dangerous:

Availability and security concerns have dominated this discussion, but the performance of the Cloud - the response time or speed at which services are delivered to an end user - may, in practical terms, be one of the most important risks to your business.

Also hard to swallow is the fact that by deploying critical infrastructure as a virtual appliance you end up building out a second layer of infrastructure. Because the core infrastructure responsible for routing requests to the virtual core infrastructure needs must still exist.


Let’s assume for a minute that you do go and deploy your load balancers and other infrastructure as virtual appliances in the cloud. What is load balancing the load balancers? Cause when it comes down to it one of the major advantages of load balancers as virtual appliances is scalability. It’s easy to scale out, not infinitely of course but I’d dare say as high as most organizations would need to go, using virtual appliances. Need more capacity? Deploy another virtual appliance. Done.

But what is load balancing the load balancers? One of the virtual appliance load balancers? And how does that scale up at higher volumes? And do you have control over the physical deployment of that controlling controller? Cause what if two instances of critical network infrastructure deployed as virtual appliances end up on the same physical machine and something happens to that machine? And then we have to go back and answer the questions about performance and availability regarding this particular architecture.


And if the virtual appliances aren’t on the same hardware, then it makes it hard to swallow the additional cost incurred by requiring multiple instances in order to build out this architecture. How many instances do you need? And how much is each of them going to cost? Cause really, this is the ideal model for the service provider but not necessarily for you and your budget. Every additional virtual machine is $$$ in the service provider’s pocket. There’s very little impetus to find alternative methods of providing the critical control customers will need over core infrastructure. Deploying core network and network application infrastructure as virtual appliances is like service-provider heaven. Management, configuration, support are all the concern of the customer then, and the revenue just keeps adding up as new virtual appliances need to be launched in order to scale such solutions.


I don’t have one, at the moment. No, no, that’s okay – I’ll wait while you pick yourself up off the floor.

There are certainly advantages to the virtual appliance model and I understand why they’re being relied upon in the cloud to deliver application and infrastructure-oriented functionality, but there are certainly disadvantages as well. The same is true for the hardware model accepted as standard fare for building and maintaining a reliable core network and application network infrastructure. That doesn’t mean that there isn’t a place for virtual appliances. As I said, that’s the wrong question. The question we should be asking is how will it impact the functionality the solution is supposed to be providing, as well as the rest of the infrastructure/architecture, and do the advantages outweigh the risk/disadvantages for my business and technical needs? 

Here’s the real question to think about when you’re talking about virtual appliances: Did you ever notice that cloud providers don’t build out their infrastructure using virtual appliances? 


Follow me on TwitterView Lori's profile on SlideShare friendfeedicon_facebook AddThis Feed Button Bookmark and Share

Related articles & blogs: