Load Balancers vs. Application Delivery Controllers: When Each Belongs
A green dashboard can hide a broken application. We saw this on a recent engagement: every server in the pool showed as healthy, yet some users were stuck every few days. The load balancer only checked whether port 443 accepted connections. One server had a working web front end but a dead database connection, so it kept receiving its share of traffic. Traffic was being distributed, but the application was not being delivered.
What a load balancer does, and what an ADC adds
A Layer 4 load balancer spreads connections across servers based on address and port. It is fast and simple, and it is enough for many stateless internal services. An application delivery controller (ADC) works at Layer 7 and understands the application. It checks health with real requests, terminates TLS in one place, keeps user sessions on the same server when needed, routes requests by content, and can run a web application firewall on decrypted traffic.
A practical rule: if a service is stateless, internal, and low-impact, plain load balancing is usually enough. If it serves end users, keeps sessions, runs over HTTPS, or is reachable from outside the organization, you probably need an ADC.
Match the form factor to the environment
Data center and critical applications: an enterprise ADC, hardware or virtual, with strong TLS throughput and advanced health monitoring.
Private cloud: a software ADC with a central controller that adds service engines as load grows, so teams do not request new hardware for each application.
Containers and microservices: a lightweight proxy or ingress controller configured in the same deployment pipeline as the application.
Multiple sites: DNS-based global server load balancing that sends users to the healthiest site and fails over automatically.
Internet-facing applications also need a web application firewall, and high-volume entry points need protection against denial-of-service floods before traffic reaches the ADC.
Four common mistakes
Shallow health checks that confirm a server is powered on but not that the application works.
One shared ADC pair for everything, so a single small change carries risk for every application behind it.
Scattered certificates and outdated TLS, where expiry dates and legacy protocols are discovered late.
Forgetting the ADC itself. Its management interface should not be reachable from user networks or the internet, and its firmware needs the same patch discipline as any other edge device.
Five steps to choose
Inventory each application: where it runs, whether it keeps sessions, whether it is exposed, and what an outage costs.
Classify by need: stateless internal services, critical business applications, fast-changing virtual applications, and microservices.
Measure real numbers: concurrent connections, TLS transactions per second, and peak bandwidth. TLS capacity often runs out before bandwidth does.
Design for availability: paired devices or engines per site, and global load balancing between sites where needed. Test the failure scenario before go-live.
Integrate security and monitoring: send WAF policy, access logs, and health alerts to your security monitoring platform so the ADC also becomes a useful source of visibility.
In our experience, organizations suffer less from missing capabilities than from capabilities that were never configured. Many ADCs we have reviewed had deep health monitoring, centralized TLS, and a WAF available, yet were used only as an expensive simple load balancer.
For the full English guide, checklist, and details: Load Balancer vs. ADC: choosing the right application delivery model
— Kazem Mortazavi, independent network-security consultant