HAProxy Enterprise Basic - Red Hat Enterprise Linux 9 AMI

My main use case for HAProxy  is as the Ingress controller for all my workloads sitting in Kubernetes , where anything entering from the public internet has to hit HAProxy  first. HAProxy makes the weighted routing for blue-green deployments and also some sort of request and header-based routing to different environments and different applications or microservices in the Kubernetes  clusters.

I used HAProxy mostly with the initial 1.5 or 1.6 Kubernetes clusters where it was the only solution compatible with NGINX , which I used for Kubernetes workloads and also for the monolithic architecture where the traffic comes from the external world, and we want to have a similar kind of configuration with a load balancer in place. I use the same HAProxy open source for on-premises to maintain similar toolsets, one from the commercial variant for the cloud and one for the on-premises variant.

A unique use case I would highlight is that initially, most API gateways or reverse proxies did not support all the functionalities we expect from an API gateway. For example, we needed rate limiting functionality not just on IP addresses but on a mix of multiple headers and content manipulations. I used HAProxy for rate limiting and integrated it with ModSecurity, our homegrown tool from open source, which we wanted to inline with HAProxy. Eventually, HAProxy introduced WAF  functionality for web application filtering, where we configured certain rules for acceptance and content enrichment, ensuring that X-Forwarded-For requests were sent to downstream applications for visibility and effective issue triage. We wrote some plugins for HAProxy and received significant help from the HAProxy team to empower our WAF  use cases over time.

In my experience, the best feature of HAProxy is its load balancing capabilities, as it provides various algorithms, stickiness, and configurations. I have extensively used HAProxy along with NGINX  over the years and found its load balancing feature to stand out. Configuration management is easy once you are familiar with deploying it, but it is not flexible enough to allow complete configuration from the UI. I have not used HAProxy in the last three to four years, but previously, its UI perspective was lacking, requiring manual adjustments. Though configuration management is not a primary focus, load balancing definitely stands out in terms of feature set. Flexibility-wise, we centralized multiple environments with a single HAProxy deployment, and its ability to handle billions of events amazed me. However, while security features have replaced WAF functionality, they are limited for smaller organizations that do not need dedicated load balancers or WAF capabilities. Built-in capabilities provide a core advantage from a cost perspective, especially for those starting out, and I recommend exploring Terraform  or Ansible  for configuration management, though it is still in an outdated style.

HAProxy positively impacted our organization by exceeding scalability expectations, initially projected at 200k requests but ultimately handling over 15 million transactions per second without any issues. We assume it can handle beyond 1 billion transactions per second since we encountered no performance hiccups. In terms of reliability, we have not experienced significant issues, though reliability concerns can arise during configuration management reloads. Cost savings are notable for startups needing minimal feature sets across WAF, API gateway, and load balancer functions, making HAProxy a cost-effective foundational tool that can save more than $100k per year for users.

One needed feature for HAProxy is a more robust API Gateway, which still has limitations despite many validations for Kubernetes, especially around ease of use and persona-based designs for different user roles. The existing functionalities around load balancing do not focus enough on security or configuration management aspects. The reloading functionality is effective as it allows soft reloads without interrupting traffic patterns, but configuration management should improve significantly, especially concerning UI and GitOps principles for easier management. While RBAC is implemented, it is not sufficiently granular for controlling access privileges, which should improve over time for managing distinct features.

A significant area for improvement in HAProxy is its tenancy model; managing multiple environments can be challenging, especially with mergers, acquisitions, or domain changes. It lacks centralized management capabilities for uniform configuration templates across regions. The tool should allow smooth version transitions and facilitate zero-touch deployments to streamline operations.

Enhancements in tooling and integration with technologies like eBPF are crucial for HAProxy. The customer support aspect also requires improvement, as their SLA responses are often not immediate enough for users who depend on HAProxy as a primary tool. Documentation can be better, particularly regarding configuration templates and best practices that fit diverse requirements.

I have been using HAProxy for almost four to five years during my career at Arista Networks and some portion at the Zeta as well, especially for the Kubernetes workload deployments from the marketplace.

HAProxy is generally stable in my experience, though issues can arise during configuration management when changes are necessary.

For scalability, HAProxy meets my needs, supporting our initial horizontal scaling and then adapting to vertical scaling in a VMware environment, utilizing Horizontal Pod Autoscaler (HPA) for Kubernetes and Vertical Pod Autoscaler (VPA) for the VM deployments.

My interactions with HAProxy's customer support were limited, but the feedback from my team indicated satisfactory service; however, SLAs were longer than our expectations.

Neutral

Before HAProxy, I initially used NGINX and switched due to scaling and reliability needs, finding HAProxy more maintainable and user-friendly with better documentation.

We purchased HAProxy via the AWS Marketplace , deploying it with our own methods using the provided Helm charts.

I estimate seeing a return on investment with HAProxy, as it significantly reduced staff requirements and enhanced scaling capabilities, particularly when transitioning from NGINX, which faced issues. Although HAProxy simplified the transition to Kubernetes, operational differences remained minimal over time.

My experience with HAProxy's pricing was positive, though I do not remember the exact figures as it was a few years ago. The pricing remains competitive compared to other vendors, and the service is somewhat aligned with recent tooling developments, although pricing structures may require re-evaluation for future offerings.

I considered NGINX during my selection process and also looked into Kong, which I find to be a robust API gateway with better functionality alongside Envoy .

We measured transaction rates and cost savings by comparing alternatives like dedicated tools for WAF, such as Cloudflare WAF  or AWS WAF , noting their costs and estimating a 30% to 40% saving. We evaluated metrics with Prometheus, analyzed through Grafana , and created custom metrics that confirmed our handling of requests without any performance issues during our scale-up period. Cost-wise, we determined HAProxy was a tool that could replace WAF, load balancer, and reverse proxy capabilities in a unified solution.

I would rate HAProxy an eight out of ten because of concerns around configuration management, the need for better management of multiple environments, a single source of truth, UI enhancements, and the potential for more frequent updates and support. Once these areas are improved, HAProxy could easily become a nine or ten out of ten.

My advice to new users is to pre-plan their intended feature use, clearly define limitations, and understand compatibility to avoid scalability issues. It is also crucial to benchmark in real-time environments. Overall, HAProxy is a great product; thorough evaluation is important to ensure that it meets user expectations before fully committing.

My main use case for HAProxy  is for my project, which focuses on full high availability. I use HAProxy  for load balancing between my two apps while connecting to Keepalived. HAProxy is very helpful for myself and my team, utilized primarily for load balancing as it is powerful for that purpose.

The best feature that HAProxy offers is load balancing, as the ability to balance both transport TCP and application HTTP or HTTPS layers gives much flexibility. SSL termination is also essential, handling SSL efficiently as HAProxy supports dynamic certificate storage. Moreover, health check functionality is significant, as HAProxy constantly checks backend servers to ensure they are healthy and pulls them out of rotation if not, preventing server traffic issues.

One of the biggest wins with HAProxy has been SSL termination, as before using HAProxy, I had to install and renew SSL certificates on each backend server individually, which was time-consuming and error-prone. By moving all SSL termination to the load balancer, I now manage certificates in a single place, and I can also utilize Let's Encrypt with HAProxy's built-in ACME support, making renewal automatic. For example, we had a small cluster of app servers for a client project where each server served the same domain. Originally, every server had its own cert, leading to issues when scaling up or replacing instances, but after offloading SSL to HAProxy, the backend servers only need to communicate via plain HTTP, while HAProxy handles all the TLS handshakes.

HAProxy is already a robust solution, but there are a few areas for potential improvement, especially regarding configuration complexity. The configuration syntax is powerful yet can become overwhelming for newcomers; a more beginner-friendly interface or a native GUI without relying on third-party tools would ease the onboarding process. Built-in observability could be enhanced; while HAProxy features great logging and stats, utilizing Grafana , Prometheus, or external tools for in-depth insights is still necessary. Native service discovery could be improved; although dynamic scaling works, it generally requires DNS or runtime API scripting. More features in the Community Edition would be beneficial, as the Enterprise version contains advanced security, WAF , and bot protection that would be advantageous for smaller teams if included in the community build.

Another area that could see improvement is documentation and onboarding resources. HAProxy's documentation is very detailed but can feel dense for newcomers, and finding practical, step-by-step examples often requires sifting through mailing lists, GitHub  issues, or blog posts. More modernized guide tutorials and real-world playbooks would simplify getting started for beginners, so enhancing technical improvements to make HAProxy more approachable through better docs and a stronger community ecosystem would significantly assist in broader adoption.

Additionally, an important area for improvement is tighter integration with cloud ecosystems, particularly AWS . Native AWS  service discovery would be advantageous; currently, one usually relies on DNS or external scripts to register new EC2  instances in HAProxy, but direct hooks into AWS Auto Scaling  Groups, ECS, or EKS would facilitate automatic joining and leaving of instances without added glue code. Furthermore, direct integration with AWS Certificate Manager  or Secrets Manager could reduce manual steps surrounding SSL, TLS, and backend credentials management. Enhancing cloud-native integration, especially with AWS services, could significantly strengthen HAProxy's plug-and-play appeal in cloud environments.

I have been using HAProxy for maybe two or three months, as I just explored HAProxy and the configuration.

In my experience, HAProxy is remarkably stable; we haven't encountered crashes or unexpected downtime. Once running, it simply continues to operate without issues, and any downtime we've faced was linked only to planned upgrades or configuration changes, not the software itself. This reliability serves as a key reason for our choice, providing us with confidence even when faced with heavy traffic.

From my experience, HAProxy's scalability is excellent; as our traffic expands, it handles load increases effortlessly.

Our interaction has primarily been with community resources rather than the official support team. Since we are utilizing the open-source edition, community forums, mailing lists, and GitHub  have been invaluable, with typically someone having encountered the same problems we faced. We haven't needed to submit a ticket to HAProxy Technologies' support team, but based on feedback I've seen, they are responsive and knowledgeable. For now, the combination of the open-source community and documentation has sufficed in resolving our issues, so I would rate community support as strong, but if guaranteed SLAs or direct assistance are required, then enterprise support would be the go-to option.

Before adopting HAProxy, we relied on NGINX  as our primary reverse proxy and load balancer. NGINX  served our basic use cases adequately, but we faced challenges as our traffic increased. The first challenge was flexibility; HAProxy offered more advanced load-balancing algorithms and health checks than we configured in NGINX. Next, dynamic configuration was a concern, as reloading config in NGINX led to occasional connection drops. HAProxy's hitless reloads and runtime API represented a notable improvement. Lastly, in heavy traffic tests, HAProxy demonstrated superior performance when handling concurrent connections, yielding lower latency and higher throughput in our setup. The shift wasn't due to any deficiencies in NGINX—it's still a solid option—but HAProxy simply aligned better with our scaling and reliability requirements as our infrastructure evolved.

Since adopting HAProxy, we've seen some remarkable improvements backed by numbers, particularly in downtime reduction. Before using HAProxy, we experienced small outages almost monthly due to backend servers going offline during cert renewals, but after centralizing load balancing and SSL management in HAProxy, those incidents have dropped to near zero with our uptime becoming consistent. Our average response time during peak load dropped by about 20 percent with connection pooling and Keepalived.

We've definitely seen a clear return on investment from using HAProxy, even while sticking with the open-source edition. Time savings have been significant; previously, SSL cert renewals across multiple servers took a couple of hours each quarter. With centralized SSL termination and automated renewals now in place, that time requirement has dropped to nearly zero hours, translating to dozens of hours saved per year. Operational efficiency has improved; we no longer have staff consistently monitoring backend servers during deployment or scaling events, as HAProxy's health checks and hitless reloads allow us to push changes with minimal manual intervention. This has freed up our operations team for higher-value work. Lastly, improved uptime stands out, with our uptime statistics rising from around 98% to consistently above 99.900, meaning reduced SLA penalties while keeping our clients happier.

Our experience with pricing, setup costs, and licensing has been quite straightforward. Since we use the open-source edition, there are no licensing fees, with the main cost being the infrastructure running on EC2  instances in AWS, which helps maintain low expenses. Regarding the setup cost, the primary investment centers on time and expertise; while HAProxy is incredibly powerful, the initial setup requires a bit of a learning curve. However, once the configuration templates are established, adding new applications or backends becomes easy. We haven't opted for HAProxy Enterprise yet, so there are no licensing complexities. In summary, using the open-source version incurs low financial costs but requires an upfront effort to set up, resulting in an overall cost-effective experience.

We evaluated a few other options before deciding on HAProxy. The primary alternatives were AWS ELB and Application Load Balancer; while they are convenient and integrated, they are also less flexible and their costs add up when compared to operating HAProxy on our own instances.

My advice for others considering HAProxy is to not be dissuaded by its learning curve; it's wise to start with a simple load-balancing setup and gradually incorporate advanced features such as ACLs, SSL termination, or rate limiting as confidence grows. Additionally, leveraging community resources and example configurations can save substantial time. Furthermore, if you're managing mission-critical workloads, it may be worthwhile to contemplate whether HAProxy Enterprise could provide the additional support and features desired. My guidance is to initially keep things simple, rely on documentation or the community, and expand into the more powerful features once the foundational stability is established. I rate HAProxy 9 out of 10.

Neutral