
Show HN: Endpoints - client-side load balancer library for Kubernetes - kelseyhightower
https://github.com/kelseyhightower/endpoints
======
eudoxus
What do you see as being the advantage of moving the lb functionality for
kubernetes from either the KubeDNS or other internal lb systems (ie sidecars
or internal reverse proxy), to being baked into the application code?

~~~
kelseyhightower
I think sidecars accomplish similar goals by moving the LB logic closer to the
application. So now the question is: Why would you want to move this kind of
thing closer to the application?

Control.

Client-side load balancing enables you to adopt application specific LB logic.
For example, when using a RPC framework like gRPC your application MAY prefer
reconnecting to the same backend when a temporary failure occurs while
streaming between two endpoints.

Client-side load balancing MAY give you more flexibility in terms of adopting
a different LB strategy per application. I know some centralized LBs support
this, but that often requires configuration changes and MAY impact other
applications sharing the centralized LB. A new LB configuration may require
more memory or trigger some obscure bug. This all or nothing approach usually
means most applications standardize on a one-size fits all solution.

For some people client-side load balancing is much easier to understand. While
many platforms hide internal proxies, DNS lookups, etc, those things MUST be
understood to fully support any application that pushes data through them.
Everything is fine until something goes wrong or when performance does not met
your business requirements.

Client-side load balancing does not solve every problem, but it's a tradeoff
that MAY yield improved performance and reduce total complexity.

