The TL;DR is that google built a system to shard client requests into different services/task by some largish shard key. The example they provide is to shard requests into ML model services by the underlying language (English vs Chinese) as different languages need different models.
Rather than requiring each product team to manage sharding, google built a custom layer to do it for any team to use. In practice it's not used by that many teams (~20 services at Google use it).
Was gonna say, this is the most popular HN thread about slicer ever. I'll admit it has its shortcomings (as someone who built a tool that was theoretically almost perfect for slicer, but didn't quite fit it), and has some other limitations for potential large clients. But I think it gets more mindshare within Google than without (especially today).
Ok maybe it hasn’t taken HN by storm but at three large, public companies in my post-google experience they all had re-implemented slicer, but they all lacked other, simpler and more generally useful rpc directors that are much more common, but don’t have papers to go with them.
The TL;DR is that google built a system to shard client requests into different services/task by some largish shard key. The example they provide is to shard requests into ML model services by the underlying language (English vs Chinese) as different languages need different models.
Rather than requiring each product team to manage sharding, google built a custom layer to do it for any team to use. In practice it's not used by that many teams (~20 services at Google use it).