Client-side load balancing in practice seems to be almost the same as server-side load balancing. Is that so?

Question

In server-side load balancing, the clients call an intermediate server, which then decides which instance of the actual server (or microservice) to call.

In client-side load balancing also, the clients call an intermediate server (the API gateway - Zuul for instance, configured with a load-balancer - Ribbon for instance and a naming server - Eureka for instance), which then decides which instance of the microservice to call.

Unless we include the API gateway as part of the client, the client still doesn't know the IP address of the exact server to which it should send the request. Seems to me, to be a lot like server-side load-balancing. Is there something I'm missing?

(Including the API gateway as part of client seems weird, since its usually deployed on a different server from the client)

Prom

This may help - #29730810 – Wrenn

@SundararajGovindasamy It still not clear to me how its the clients that're making the load-balancing decision, when its clearly Ribbon placed on the API gateway, that does so – Prom

You don't have to call an intermediate server. You can use a RestTEmplate and have that in a loadbalanced fashion. You don't need/require ZUUL for that. You can use Ribbon directly in your client. In your case you have emulated server-side load balancing instead of using client-side load balancing. – Inez

@M.Deinum So, it means that if we use an API gateway like Zuul, the entire architecture can no longer be said to be following client-side load balancing? – Prom

Exactly, unless you consider your api-gateway to be a client, then you could say that that is doing client-side load balancing (although a bit far fetched). – Inez

Answer 1

In Client Side load balancing, the Client is doing the heavy lifting of discovery and connection to the origin server. The client may reference a lookup (Eureka, Consul, maybe DDNS), to discover what the end destination is and the registry will dole out a valid origin. The communication is direct, client to server without a middle man.

In Server Side load balancing, the client is dumb, and makes a call to a predetermined address (usually DNS or static IP). That device then either proxies (TCP or protocol level) the connection to the origin server based on either a lookup, heartbeat, etc.

I've seen benefits in client side routing in that as long as you have IP connectivity between client and server, the work of the infrastructure is trivial to add new services, locations, products, apps, etc. As long as the new server can "register" with the registry, and the client has IP access to the server, it just works and IT does not have to be involved in rolling out your new service.

The drawback is it makes the client a little more heavy, it does require IP access direct from client to server, and may be confusing for traditional IT folks and auditors. Each client needs to be aware of the registry and have code to make calls (or use a sidecar/sidekick).

I've seen it in practice where a group started to transition their apps to a Docker environment, and they were able to run their Docker based apps along side their non-docker versions at the same time w/o having to get IT involved and do a lot of experimentation and testing quickly and autonomously.

If you have autonomous teams, are highly advanced on the devops spectrum, and have a lot of trust with your teams, Client Side routing and load balancing may be a good experience for you.

Alcaide