Load balancers & application delivery
A load balancer spreads traffic over several servers and sends it only to those that are healthy. A Layer 4 balancer decides on addresses and ports and passes TCP or UDP through; a Layer 7 balancer reads the request (host, path, headers, cookies) and can route, rewrite, cache and apply security rules. Many designs use both: a fast L4 front, L7 behind it. We choose by what the application needs, not by brand.
What we do
- L4 and L7 balancer design with health-check strategy
- TLS offload and certificate lifecycle for balancers
- HA pairs, GSLB and multi-site failover
- Zero-downtime deployments with draining and canaries
- WAF and rate-limit placement
- F5, NetScaler and HAProxy migrations to current platforms
- Cloud balancer and ingress configuration
- Pool and latency monitoring with alerting
Health checks decide whether the design survives a failure. Passive checks watch real traffic for errors; active checks send their own probes on a schedule. Open-source NGINX marks a server failed after observed errors, while active health checks are an NGINX Plus feature; Envoy combines active checks with outlier detection. TLS offload moves encryption to the balancer, so we also plan certificate renewal, re-encryption to the back end where policy requires it, and what the balancer is allowed to see.
We work with hardware and virtual application delivery controllers (F5 BIG-IP, NetScaler), software proxies (HAProxy, NGINX, Envoy) and the cloud balancers from the big providers, including AWS Elastic Load Balancing. Around them we design persistence, global traffic management, WAF placement, connection draining for deployments and the monitoring that tells you a pool is down before users do. Part of our network and cloud practice.
Leading platforms we work with
- F5 BIG-IP
- HAProxy
- NGINX
- Envoy
- NetScaler
- AWS Elastic Load Balancing
- Kemp
- A10 Networks
- Traefik
- Google Cloud Load Balancing
- Azure Application Gateway
- Radware
- Cloudflare Load Balancing
Platforms and practices
- Layer 4 and Layer 7 load balancing
- Active and passive health checks
- TLS termination, offload and re-encryption
- Session persistence
- Global server load balancing (GSLB)
- Blue-green and canary routing
- Connection draining
- WAF and rate limiting at the edge
- Service mesh sidecars and ingress
- High availability pairs and VRRP
References
- F5 BIG-IP application services
- HAProxy
- NGINX: HTTP load balancing
- Envoy: what is Envoy
- NetScaler documentation
- AWS: what is Elastic Load Balancing
Sources last checked .
Product names are trademarks of their owners and are listed to describe our experience; they do not imply endorsement or partnership.
One address, three places, no outage
The same /24 is announced from three points of presence. Each user reaches the closest one. When a PoP fails its health check it withdraws the route, and BGP sends its users to the next closest PoP with no change on their side.
How we use Load balancers & application delivery for clients
Managed IT Services
We run your IT day to day so it stays secure: help desk, devices, Microsoft 365, Exchange, Active Directory, backups, networks and monitoring.
Learn moreCloud Management
Cloud cost review and management, without compromising on quality or security.
Learn moreCybersecurity
We find out whether everything you run is safe from attackers, then we fix it.
Learn moreFrequently asked questions
Direct answers to the questions we hear most. Something else on your mind?
Send us a messageWhat is the difference between Layer 4 and Layer 7 load balancing?
A Layer 4 balancer decides on addresses and ports and passes TCP or UDP traffic through. A Layer 7 balancer reads the request (host, path, headers, cookies) and can route, rewrite, cache and apply security rules. Many designs use a fast L4 front and L7 behind it.
Do we need an expensive hardware ADC?
Not always. We choose by what the application needs, not by brand. Software proxies such as HAProxy, NGINX and Envoy, or the cloud balancers from the big providers, often fit. Hardware or virtual appliances such as F5 BIG-IP and NetScaler make sense when you need their feature set.
How do health checks decide whether the design survives a failure?
Passive checks watch real traffic for errors. Active checks send their own probes on a schedule. Open-source NGINX marks a server failed after observed errors, and active health checks are an NGINX Plus feature, while Envoy combines active checks with outlier detection. We test failure, not just configuration.
Who handles TLS and certificate renewal on the balancer?
We plan it up front. TLS offload moves encryption to the balancer, so we cover certificate renewal, re-encryption to the back end where policy requires it, and what the balancer is allowed to see. Renewal should be automated so that a certificate expiry does not take the front door down.
Can you deploy without dropping user sessions?
That is the aim. We design connection draining so that existing requests finish before a server leaves the pool, and blue-green or canary routing so that a bad release reaches few users. Session persistence is used only where the application needs it, because it complicates failover.
How will we know a pool is down before users do?
We build monitoring around the balancer: pool health, error rates and latency, with alerts to the team that owns the service. High availability pairs, redundant paths and tested failover cover the balancer itself. This is part of our network and cloud practice, and we do not resell the products.