3 ms·
Even with scarce IPv4 you could currently do that just running backends on different ports It's common to do internal services that way but you can't control h
by nijave 5y ago
Even with scarce IPv4 you could currently do that just running backends on different ports
It's common to do internal services that way but you can't control how or who or the internet might try to connect to your service so the load balancer offers a layer of protection so servers can't be picked off individually.
They can also offer an abstraction/routing layer so you can do things like canaries and controlled rollouts which would be much more difficult just advertising IPs directly to the client.
- bullen 5y agoI'm going to reply to all of you here: You cannot use different ports from the client, it has to be 80 for HTTP, I meant; do you own loadbalancing from the client! So f.ex. the browser would load parts of the site from another server via javascript or redirect to another dns with another IPv6 address. To have a bottleneck between all your clients and all your servers is not good architecture.
- toast0 5y ago> To have a bottleneck between all your clients and all your servers is not good architecture. Maybe not, but everyone else is doing it. If your clients are web browsers, it's hard to convince them to do useful things like notice servers have changed; much easier to focus their attention on a handful of load balancers on static IPs and figure it out from there.