The distinction between "hardware" and "software" load balancers is no longer meaningful. A so-called "hardware" load balancer is a PC class CPU, network interfaces with packet processing capabilities, and some software to bind it all together. A "software" load balancer realized on a good server with modern NICs is ... the same.
What you get with high-end commercial offerings like F5 or Citrix Netscaler is:
A rich and deep feature set. Their solution is mature and can quickly handle all common needs and some uncommon ones as well.
Excellent statistics. Management types love statistics, and network techs realize that stats can be useful in troubleshooting too.
A single vendor to choke when something isn't working, i.e. support contract directly with the solution vendor.
Lower salary costs. The appliance mostly just works, and managing one doesn't take that many hours.
With (open source) software load balancers is you don't get the opposite, what you get depends on the software you choose and how you go about it. That said, typically you'll see:
Longer time to set up the initial solution. Especially if you need more than just load balancing, fx caching + content rewriting + HA, then setting up open source software takes more manhours.
You build it, you own it. If your company sets up open source software load balancers with inhouse techs, then you're 100% responsible for the solution yourself. Documentation, upgrade path, disaster recovery etc will all need to be considered and perhaps be implemented by you.
The differentiation isn't really on "hardware" versus "software". It is on "buy a proven technology stack as an appliance" versus "build it yourself". There are of course many variables to consider when making the final decision (costs, inhouse skill sets, tolerance for downtime, future growth etc).
Hardware load balancers typically have a richer set of features, especially when you get to the big ones such as F5. You also have the added benefit of greater scalability because of hardware offloading.
On the other hand, if you know your traffic won't be too high, software load balancers actually perform quite well. If you can make due with having a Layer 4 LB, Linux LVS + Keepalived is a very good option. If you need the power of a Layer 7 LB, you can give HAProxy a go.
So in summary, HW LBs typically scale better than SW LBs.
Pro: the machine you run the load balancer on could have much more powerful hardware so would be faster and impose less extra latency (though depending on the speed of your links to the outside world this may make little difference).
Con: a hardware load balancer will likely have no more computing power than it needs (it may run on an Atom or ARM-based chip rather than a chunky high-end Intel/AMD CPU for instance) so will consume less power and generate less heat.
Pro: installing your own software load balancer arrangement may give you more flexibility in configuration and later upgrades/changes, where a hardware solution may be much more of a closed "black box" solution. Though if you are buying a managed service to implement the software balancer this will make little difference.
Con: if you are not managing the software balancer (i.e. the task is outsourced, or you are purchasing the service as part of a larger managed hosting arrangement) you might find the admin fees for maintaining the setup mean an off-the-shelf hardware solution would be cheaper in the long run. Also, remember to factor in in your time into any costings if you or your company will be managing the load balancer.
If the company has an IT department with a network specialist, then a Hardware LB might help to reduce the maintenance load from the development team.
Sometimes, specially for big companies, adopting a new hardware that no one knows how to operate, implies in hiring expensive consultants or even a new employ.
The development team will hate a Hardware solution if they are planning to stress the features of the load balancer, like for example, to adopt continuous deployment.
The distinction between "hardware" and "software" load balancers is no longer meaningful. A so-called "hardware" load balancer is a PC class CPU, network interfaces with packet processing capabilities, and some software to bind it all together. A "software" load balancer realized on a good server with modern NICs is ... the same.
What you get with high-end commercial offerings like F5 or Citrix Netscaler is:
With (open source) software load balancers is you don't get the opposite, what you get depends on the software you choose and how you go about it. That said, typically you'll see:
The differentiation isn't really on "hardware" versus "software". It is on "buy a proven technology stack as an appliance" versus "build it yourself". There are of course many variables to consider when making the final decision (costs, inhouse skill sets, tolerance for downtime, future growth etc).
Hardware load balancers typically have a richer set of features, especially when you get to the big ones such as F5. You also have the added benefit of greater scalability because of hardware offloading.
On the other hand, if you know your traffic won't be too high, software load balancers actually perform quite well. If you can make due with having a Layer 4 LB, Linux LVS + Keepalived is a very good option. If you need the power of a Layer 7 LB, you can give HAProxy a go.
So in summary, HW LBs typically scale better than SW LBs.
Hope this helps!
A few thoughts:
Pro: the machine you run the load balancer on could have much more powerful hardware so would be faster and impose less extra latency (though depending on the speed of your links to the outside world this may make little difference).
Con: a hardware load balancer will likely have no more computing power than it needs (it may run on an Atom or ARM-based chip rather than a chunky high-end Intel/AMD CPU for instance) so will consume less power and generate less heat.
Pro: installing your own software load balancer arrangement may give you more flexibility in configuration and later upgrades/changes, where a hardware solution may be much more of a closed "black box" solution. Though if you are buying a managed service to implement the software balancer this will make little difference.
Con: if you are not managing the software balancer (i.e. the task is outsourced, or you are purchasing the service as part of a larger managed hosting arrangement) you might find the admin fees for maintaining the setup mean an off-the-shelf hardware solution would be cheaper in the long run. Also, remember to factor in in your time into any costings if you or your company will be managing the load balancer.
I would take into account these points, as well:
If the company has an IT department with a network specialist, then a Hardware LB might help to reduce the maintenance load from the development team.
Sometimes, specially for big companies, adopting a new hardware that no one knows how to operate, implies in hiring expensive consultants or even a new employ.
The development team will hate a Hardware solution if they are planning to stress the features of the load balancer, like for example, to adopt continuous deployment.
Apparently HW LBs can improve handling SSL connections and therefore reduce the overall number of app servers required:
http://highscalability.com/blog/2010/8/12/strategy-terminate-ssl-connections-in-hardware-and-reduce-se.html