How to get load balancing right
The advice here is unglamorous, which is probably why it gets skipped. The short answer to load balancing is that it is mostly a sequence of small decisions, not one big one.
Operability is a feature, and it has to be built rather than bought. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.
What it costs to ignore
Health checks decide whether load balancing helps or hurts. The teams that handle this well are rarely the ones with the biggest budgets. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.
The steps
- Establish what you have today before changing anything
- Sticky sessions quietly limit how far you can scale
- Test what happens when one instance is slow rather than dead
- Write down the decision so the next person does not re-litigate it
Test what happens when one instance is slow rather than dead. The cost of getting this wrong is rarely visible on the day it happens. Assume whoever inherits this will have half your context and none of your patience.
Where to go from here
How to tell if yours is fine
Cloud work rewards teams who automate early and punishes teams who click through consoles. Three things worth confirming about load balancing before you move on:
- Someone can say what the current setup is without going to look
- Sticky sessions quietly limit how far you can scale — and you know whether that is true here
- There is a way to tell whether the last change to this helped
Most of the value here comes from doing the first two things, not all of them.