HAProxy (High Availability Proxy) is open source proxy and load balancing server software. It provides high availability at the network (TCP) and application (HTTP/S) layers, improving speed and performance by distributing workload across multiple servers.
HAProxy runs on Linux, FreeBSD and Solaris operating systems.
HAProxy configurations vs on-edge load balancing – use case comparisons
|HAProxy||On-Edge Load Balancer|
|URI/URL based load balancing||Yes||Yes|
|Protocols||Application and network layers||Application layer|
|Global/geo server load balancing||No||Yes|
|Algorithms||Network layer||Network and application layers|
|Installation and maintenance||Extensive||Minimal|
|Single point of failure||Likely (if on premises)||Unlikely|
|Cost||Free||Medium to high|
Now let’s break it down.
URI/URL based load balancing
Both HAProxy and on-edge load balancers provide URI/URL based load balancing.
HAProxy logs provide a variety of data, including:
- Sum of requests per second reaching your front-end server
- Average of request response times logged over a minute
- Top URI requests regarding 4xx and 5xx errors
- Reasons for a session ending with an abnormal termination state
On-edge server data logs provide similar data to that offered by HAProxy. Additionally, as an end to end service, on-edge load balancers offer both cross data center and in data center traffic logs.
A number of on-edge load balancers also offer integrated logs for security events.
HAProxy provides load balancing at the network and application layers. This means you’re able to set up backend clusters for an entire website, or specify different backends based on the content of client requests.
In contrast, on-edge load balancers only manage the distribution of application layer (OSI layer 7) traffic.
While HAProxy SSL termination is possible, doing so requires additional configurations.
On-edge load balancers delivered through CDNs manage and maintain SSL certificates with no additional configurations.
Both HAProxy and on-edge load balancers can be configured to distribute requests with session stickiness.
Geo-load balancing and global server load balancing (GSLB)
On-edge load balancing services can be used to distribute traffic across multiple data centers located throughout the world. Many services also enable routing policies based on geo-location, e.g., to ensure that EU based visitors are only served by locally positioned backend servers. Among other benefits, this helps achieve compliance with local information privacy regulations (e.g., GDPR).
HAProxy, on the other hand, is not equipped to handle multi-data center scenarios unless integrated with a third-party service (e.g., anycast DNS service). The integration process can be cumbersome, requiring additional resources and technical know-how for setup and maintenance.
Such setups also require a HAProxy load balancer in each of your data centers, which might complicate implementation and lead to ongoing maintenance chores.
On-edge load balancers provided by a CDN offer near-limitless scalability. Bandwidth caps and other resources can be expanded based on the level of demand, often without any manual tweaking.
HAProxy, when used as an on-prem solution, is capped by the processing capabilities of the server it’s installed on and the network’s uplink. This prevents the load balancer from handling unforeseen traffic spikes—exactly when load distribution mechanisms are needed the most.
When installed in the cloud, HAProxy can be integrated with external services (e.g., AWS Auto Scaling) to overcome scalability limitations. Such setups require scripting and come with added costs.
HAProxy provides a diverse set of network layer algorithms to control traffic distribution between load balancing servers, including:
- Round robin – Each load balancing server is assigned requests in turn, using a static sequence.
- Least connection – New requests are assigned to the server having the fewest current connection requests.
- Source – New requests are assigned to the server that previously responded to the same client.
In addition to these, on-edge load balancers also support application layer algorithms that enable additional visibility into traffic flows.
The most popular application layer algorithm is least pending requests (LPR), which individually monitors the amount of pending HTTP/S requests on each server. This provides an accurate view into the current server workload, enabling a significantly more data-driven and effective load distribution.
Installation and maintenance
HAProxy requires in-house expertise to set up and maintain. This is especially true if you need to install HAProxy on multiple machines within your network, with the more complex setups requiring the help of external experts, even for IT-savvy organizations.
In contrast, most on-edge load balancers can be deployed within minutes, usually via a change to your DNS settings and require no ongoing maintenance due to their managed service model.
Single point of failure
Cloud-based solutions, especially those offered through CDNs, use a multi-node topology to ensure resiliency through redundancy. As a result, active nodes keep your service up and running during multiple server failures. Even if your entire data center goes down, traffic can still be diverted to other available nodes or a backup site.
When installed on a single on premise server, as it often is, HAProxy is a single point of failure. When used in a cloud service, such as AWS, multiple HAProxys can be installed on separate EC2 services in different availability zones and connected using a third party DNS routing service to reroute traffic during a server failure. It’s a complex setup that provides solid redundancy, albeit with significantly increased costs.
HAProxy is a free and open source application. It’s included in some Linux distributions or can be downloaded on its own. The setup is at times complicated and might require hiring outside expertise.
A CDN-provided load balancer requires a monthly or yearly subscription fee, but relieves the organization of many hidden costs associated with hardware, deployment and ongoing maintenance.
HAProxy is a narrowly focused load balancing solution. While it can be integrated with other services, (e.g., CloudWatch and Amazon AutoScaling), doing so is often complex, costly and prone to error.
By contrast, many on-edge load balancers have the advantage of being a part of a consolidated application delivery controller (ADC) solution that addresses such needs as:
This is why it’s not uncommon to see on-edge load balancers used in conjunction with HAProxy, with the former handling caching, filtering and routing tasks at the CDN layer and the latter managing logic and configurations on the application layer (e.g. on premise caching).
How to choose a load balancer
Depending on your requirements and resources, both HAProxy and an on-edge load balancer can be viable options.
For organizations looking for a network layer load balancing solutions, or those operating a single data center, HAProxy is a suitable and cost-effective choice.
However, for companies who manage a multi-data center environments, or need to scale dynamically and provide their service worldwide, an on-edge load balancer is a much more efficient solution.