Thread by @colmmacc

@bhoflack @danluu We rejected a Maglev-like design because probabilistic LB doesn't work for the vast majority of workloads. Most customers have only 2 LB targets, they're also often slow, and subject to garbage-collection pauses. Probabilistic LB increases utilization way too much.

@bhoflack @danluu It's a design that works well when you have lots of very fast, very consistent targets. You could say it worked well at Google then, but I'm not sure I'd agree. It also imposes that constraint tax on your ecosystem; teams may be forced to optimize way earlier.

@bhoflack @danluu Our world view of load balancers is that they primarily an organizational tool designed to free teams from problems and complexity. Helps you not work as much on HA, GC, or long-tail latency, quite as much. The paper reads like awesome bin-packing is what LB is about.

@bhoflack @danluu ALTS shares many of the problems I put in my rant about mTLS.

https://twitter.com/colmmacc/status/1057017343438540801

Though ALTS is mTLS done about as well as it can be. We put our weight behind SIGv4 instead, even internally, and I think it's much much better.

@bhoflack @danluu The pre-auth TCB of SIGv4 is basically SHA256. The pre-auth TCB of ALTS includes Protobufs. And it's a layering violation that puts AAA in a layer where request-smuggling can happen. Anyway, it's something now fixed AIUI, and gRPC is a good example of something better.

@bhoflack @danluu Spanner relies on assumptions about network reliability and clock reliability that simply aren't true ... and have now been born out by at least one outage.

https://twitter.com/colmmacc/status/1136888583233581056

@bhoflack @danluu You can build fancy atomic clocks in data-centers, and cool PTP networks to servers (we do all this too!) , but there's still quartz and clock-cycles where the TX actually happens, and the CAP theorem still holds about networks.