HAProxy Enterprise Ingress Controller

My main use case for HAProxy  is to serve web pages, call backend applications, and serve customer queries. On HAProxy , we have different rules to accept user requests and redirect them to either Nginx in the backend for proxy pass or reverse proxy, or we give it to the Tomcat  application, a Tomcat  Java application, to serve the request and give the response back to the customer.

Regarding how those rules work, for example, let's talk about serving static content. We have a rule, such as /static or some node URLs. Based on that, we give the request to Nginx to serve the static content. Static content is hosted on the local server or maybe some S3  bucket. Similarly, if there's a Java application URL for various purposes, such as reporting, transactions, payments, or order booking, all those requests, based on whatever rules we have, go to the backend Tomcat application where we've configured multiple servers for high availability. We have also kept HAProxy in the backend to the application load balancer, so we can manage multiple HAProxy servers with a single application load balancer and from there manage multiple Tomcat Java application servers, multiple Node servers, or multiple static content Nginx servers.

The best features HAProxy offers include the reverse proxy feature, which I find to be the best. The second is that the rules and templates are very easy to understand, read, and write. Another great feature is that HAProxy supports SSL, the certificates and all for multiple domains. This is also great and while it is available in other web servers, HAProxy includes it here, which is useful. The simplicity of the rules is another advantage which I mentioned earlier, and the logging of HAProxy has in-depth printing that can be very useful. We can pass those logs later for our analytics purpose.

Regarding logging, we log the X-Forwarded-For IP, the original client IP from where the request lands to HAProxy so that we can see which IP is hitting how many requests with what action or what URL. This helps us identify potential spamming attacks or scraping on our platform. We parse all these logs or forward them to a centralized logging server so that the other team can review and take action. For example, we can block it in our firewall or web application firewall, or we can implement rate limiting based on this logging analysis. As for the rules, we can mention multiple domains' configurations with actions or rules and redirect them to any backend server, whether it is a Java application, Next.js application, or any Node application. This way, they will be served better.

I think HAProxy is good as it stands now, but I believe there could be improvements. gRPC has recently been implemented, which is great, along with TLS 1.2 and 1.3 support, and HTTP 2.0 is also available. However, I'm unsure about the benchmark of those HTTP 2.0 requests on HAProxy. If there were any other protocol with better performance than HTTP 2.0, or perhaps mTLS and other similar features, including that in HAProxy would be really great.

For improvements, I think that during setup and configuration, the steps provided are neat and clear. Anyone can easily install and configure it. There are many kernel tuning parameters also available, which is great. For specific improvement, in terms of logging, I think printing the full object of the request may help, or if there's a way to reference two requests, it would be beneficial to find a complete session history from a logged-in customer, as it would help analyze customer and user analytics.

HAProxy is something we started using somewhere in 2013, almost 12 years back.

HAProxy has helped with performance and uptime. Before HAProxy, we had Apache web servers. The performance of HAProxy is awesome; I would say it's far better. We have reduced a lot of servers, replacing them with one or two HAProxy servers which deliver better performance, accuracy, and an almost 100% success rate with requests coming from customers or other sources, and there are no loopholes, disconnects, or gaps in the entire data flow.

HAProxy's scalability is excellent. We have multiple HAProxy servers, and we've achieved load balancing based on CPU utilization, CPU load average, and memory. We manage an automatic load balancing feature where we add HAProxy servers dynamically behind the application load balancer to handle more traffic. At low peak levels, we remove HAProxy servers after completing in-flight requests, managing our scalability efficiently.

So far, we haven't needed to reach out for customer support for HAProxy. We have utilized all the features provided without requiring assistance.

Positive

We were previously using Apache web servers before implementing HAProxy, and we switched because Apache gave us many issues with customer user queries. It would time out, slow responses, and even throttle requests in a heavily loaded environment. We haven't seen those issues with HAProxy. HAProxy performs well with proper CPU utilization and maintains great accuracy with a high success rate.

Before choosing HAProxy, we evaluated other options. When we experienced challenges with Apache web servers, we considered whether to go with HAProxy or Nginx, but we chose HAProxy due to the benchmark results with our rule sets showing it winning in most cases. That's why we have been using HAProxy in production for the last 12 to 13 years.

In terms of my setup of HAProxy, we have the open-source HAProxy latest 3.0 on Linux, Amazon Linux  OS server. By the way, we have multiple HAProxy servers. We follow the standard configuration on the Linux platform along with high tuning parameters and kernel tuning parameters so that it can serve multiple connections parallelly without any connection overhead or taking much resources. We do a lot of kernel tuning parameters for HAProxy to serve with better performance, fast, and accurate.

I can share one use case in terms of ROI related to money and time saved. We had multiple Linux servers for Apache web servers, which we replaced with a few HAProxy servers. This resulted in a drastic decrease in costs and, at the same time, the accuracy of the hits coming on HAProxy was almost around 100% or 99.99%. This was not the case with the other web servers in our heavily loaded environment.

I find the pricing, setup costs, and licensing for HAProxy to be acceptable. The setup cost is fine since we understand the logic and concepts behind it. We should explore how licenses can be further improved, but I believe the offerings of HAProxy are really good, and I don't see any concerns or challenges regarding pricing.

For the backend configuration, there are a lot of features provided by HAProxy, including multiple connections and timeout settings.

HAProxy has positively impacted our organization as we serve many domains. We use rules to serve our B2B domains, which include numerous B2B websites served through HAProxy based on requests and other requirements. All these B2B platforms handle regular order bookings, payments, different analytics, and MIS reports, among many other activities. It's one of the best; we don't use any other web server apart from HAProxy.

My advice for others considering using HAProxy is that it should be based on their specific requirements and challenges within their environment. I recommend conducting benchmarking and testing in their staging or performance testing environments. HAProxy is one of the best web servers known for its drastic scalability, performance, and accuracy, as mentioned earlier. I also suggest focusing on the simplicity of use and debugging, making HAProxy a favorable option.

I think HAProxy is good, and I can see that many new versions are being released. There is a proper release mechanism or SDLC life cycle for HAProxy versions, which is commendable. Overall, I believe in using it as it is. I would rate this solution a 10 out of 10.