8
DevOps
Central load balancer vs service-level routing for 18 microservices
Central distribution ↔ Application-aware routing
Context
Route traffic between 18 services, with canary releases on the roadmap.
We run 18 services on Kubernetes. North-south traffic goes through an NGINX ingress; east-west calls go straight to Kubernetes Services.
We want canary releases, per-route timeouts and better tracing. Two paths:
- Keep central load balancing: ingress plus a progressive-delivery tool for canaries.
- Adopt service-level routing: a service mesh (Istio or Linkerd) so every call is routed, retried and observed by sidecars.
Two platform engineers. What would you do?
Constraints
- Services
- 18, mostly HTTP, a few gRPC
- Need
- Canary releases and per-route timeouts
- Platform team
- 2 engineers
Central L7 load balancer / ingressvsService-level routing (mesh or client-side)
Community verdict
Central L7 load balancer / ingress 60%Service-level routing (mesh or client-side) 40%
10 engineers · 5 opinions
With these constraints, what would you choose?
One choice per engineer. You can change it any time.
Central L7 load balancer / ingress
Service-level routing (mesh or client-side)
Simplicity →
Trade-offs
Dimensions
Central L7 load balancer / ingressService-level routing (mesh or client-side)out of 5
- Simplicity
- 5Central L7 load balancer / ingress scores 5 of 52Service-level routing (mesh or client-side) scores 2 of 5
- Routing flexibility
- 3Central L7 load balancer / ingress scores 3 of 55Service-level routing (mesh or client-side) scores 5 of 5
- Observability
Community discussion
5 comments
Have you made this decision in production? Share your reasoning.
Sign in to commentWith two platform engineers, every new control plane is an on-call liability. Prove you need application-aware routing on real incidents first.
East-west visibility is where we were blind. A mesh gave us per-call latency, retries and error rates between services without touching code. Linkerd was far lighter to run than we feared.
And mTLS by default. For us the security posture alone justified it.
Start central. Most canary needs are north-south: the ingress or Gateway API can split traffic by weight, and tools like Argo Rollouts drive it from metrics. That covers 80% of what people buy a mesh for.
Adopt a mesh when you need mTLS between services or fine-grained east-west policy, not before.
Gateway API weighted routes are a good middle step. Keeps us on one control plane.