Share your experience using Venusense ADC

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.

Our clients are using Fortinet FortiADC primarily for load balancing, which serves as the application server load balancer. We have worked with one or two cases of Fortinet FortiADC. For application load balancer solutions, we prefer either A10, which is a leader product present in Gartner leader and Forrester leader, or Radware. We worked with a customer who was in the Fortinet environment, so we suggested Fortinet FortiADC, which helps integrate with FortiWeb, a WAF solution.

For integration purposes, we implemented Fortinet FortiADC, and they had around four applications and 20 servers. We were able to do the load balancing based on the round robin method in that ADC, which was the use case objective of having the ADC solution. It was placed behind the WAF solution, so SSL offloading and transitions were taken care of in the SLB part, specifically Fortinet FortiADC.

Regarding SSL offloading, we had the same use case since they need the certificate for external communications, but for internal communications, they had a separate certificate. We just offloaded the SSL in WAF, and we do the SSL transition in the Fortinet FortiADC part.

When speaking about load balancing, this refers to GSLB, which stands for Global Server Load Balancing. The use case was to balance the loads in a hospital environment with one main application and other side applications supporting doctors, the database for their medical equipment, and related systems. The main application was an online consulting application. The task of Fortinet FortiADC was to load balance the number of hits based on the round robin algorithm and manage the balances between the four or five servers allocated to the application.

In terms of analytics and reporting capability, when integrated, we integrated with FortiAnalyzer. As a standalone solution, it doesn't show much impact, but when integrated with FortiAnalyzer, it has much more significance.

Some customers need custom management for handling their applications across the servers. Instead of having a predefined solution, if we had space for custom-based algorithms to load balance the traffic, it would be better. We have faced such cases with A10, where we can leverage many custom scripts and do much more. Even though A10 primarily focuses on SMBs, they have also ventured into the enterprise market. Fortinet has been a pioneer for enterprise solutions, such as firewalls, SASE, ZTNA, and SD-WAN solutions, and they are in a leader quadrant. Therefore, they should have more options.

From a pricing perspective, it is expensive.

Fortinet FortiADC has been a stable product until now; however, lately we are facing some small issues. It cannot be classified as unstable since they have good support. Overall, it has been good; in the past it was very good, and now it is still performing well.

Even though it is on-premise, there might be some limitations with scalability. Fortinet FortiADC has both virtual and physical appliance options. For those opting for a SaaS or cloud solution, there is scalability and flexibility. Additionally, FortiGSLB cloud integrations provide maximum service availability and some flexible licensing options. Apart from the physical on-premise model, everything else regarding scalability and functionality is excellent.

Technical support from Fortinet is satisfactory. It varies depending on the engineer assigned; in most cases, we resolve issues on the first attempt. There have been one or two rare instances where they fail to provide complete support, but it's not solely their fault; overall, the support is good.

On a scale from one to ten, the support deserves an eight.

Positive

When comparing Fortinet to other competitors such as SentinelOne, Trend Micro, and Trellix, Fortinet provides a comprehensive platform that goes beyond just solutions; it creates an end-to-end security platform. You can have mail security, web security, and firewall perimeter security. In contrast, Trellix and Trend Micro mostly focus on endpoint security levels and occasionally offer secure web gateway or mail security solutions. Rarely do they cover as much as Fortinet. SentinelOne focuses heavily on the attacking path regarding endpoint security and identity security. Their roadmap is extending to data DLP, data security, and cloud security. They have begun working on cloud security and their product is promising. Ultimately, Fortinet constructs every solution needed for each defense layer, making it comparatively better than Trellix, Trend Micro, or SentinelOne.

The installation of Fortinet FortiADC rates around six or seven out of ten in terms of difficulty.

Our clients typically have the solution on-premise. I would rate Fortinet FortiADC a seven out of ten overall as a product.