Should you build or buy Application Delivery Controller & Load Balancing?
An application delivery controller balances and secures traffic to application servers: load balancing, TLS termination, health checks, and often a web application firewall. Enterprises use ADCs, hardware appliances or software, to keep sites and APIs available and to route traffic across data centers and regions.
Do not renew on autopilot. DoubleVerify, Booking.com, Pinterest and Snowflake all run software proxies as their production edge, and the reported cost gap versus appliances runs from 74% to 90% in the published cases. Keep hardware where measured TLS handshake load, a FIPS 140-3 boundary or GSLB failover genuinely needs it, and move the rest to HAProxy, NGINX or Envoy with either commercial support or an SRE team that owns the fleet.
Build it, buy it, or bridge?
When building makes sense
Software load balancing at appliance-replacing scale is documented and it isn't a fringe move. DoubleVerify moved off F5 VIPRION hardware to HAProxy Enterprise running on commodity servers after facing a $5.2 million renewal quote, and now handles over five billion requests a day at 595,000 requests per second peak, a tenth of its prior infrastructure cost. Pinterest has moved all of its production edge traffic to Envoy, and Snowflake runs Envoy Layer 7 fleets that carry a growing share of traffic per region, so DoubleVerify's move isn't an outlier. Booking.com went further and built its own control plane on top of HAProxy, the Balancer API, that now runs hundreds of load balancers across availability zones. Both DoubleVerify and Booking.com needed real engineering investment to get there. This build fits teams with the traffic volume and SRE capacity to run that kind of infrastructure long-term.
When buying makes sense
Keep hardware appliances specifically where their narrow advantages are load-bearing, and renegotiate everywhere else using the software alternative as real bargaining power. F5 advertises hardware TLS offload handling 200,000 RSA-2K handshakes a second, and NetScaler sells FIPS 140-3 Level 2 validated platforms, both genuine capabilities that matter for specific compliance or extreme-handshake-volume situations. But a Fortune 500 bank reportedly cut total cost of ownership 74% after replacing 24 F5 balancers with Avi, and DoubleVerify's own move to HAProxy cut its costs to a tenth, so the appliance renewal is an expensive default rather than a necessary one for most traffic. Buy or keep hardware for the specific workloads where TLS handshake volume, a FIPS boundary or a support contract with real accountability genuinely matters, and treat everything else as a candidate for migration or at minimum a price negotiation grounded in what software proxies now demonstrably do at scale.
The desk read
Build-versus-buy analysis for Application Delivery Controller & Load Balancing is being written. In the meantime, the framework that drives every B4 call is on the B4 Index page.
Frequently asked
What does an application delivery controller actually do?
It sits in front of application servers and decides which one handles each request, terminates and re-encrypts TLS, checks server health, and often filters malicious traffic through a built-in web application firewall. Whether that logic runs on a dedicated appliance or as software on commodity servers is the whole build-versus-buy question for this category.
Has anyone actually replaced hardware load balancers with software at real scale?
Yes. Pinterest moved all of its production edge traffic to an Envoy-based proxy layer, and eBay Classifieds runs its edge on Traefik at a peak of 22,000 requests a second with hundreds of services behind it. These are ordinary production systems now, not one-off experiments.
When does a hardware appliance still make sense?
When TLS handshake volume, a FIPS-validated compliance boundary, or vendor support with real accountability genuinely matters. F5 and NetScaler's remaining edge is hardware offload performance and certified platforms, not load-balancing capability itself.
What does it actually take to replace an appliance with software?
Real engineering investment: tuning process and CPU-mapping configuration for the actual traffic pattern, and eventually a control plane to manage a growing fleet of software proxies across availability zones as scale increases. Nobody who has done this at scale describes it as a weekend project.