4 ms·

I was hoping to see something about xDS. I've seen a lot of work being done on adding support for it in gRPC on git but (as usual with gRPC) the docs and blog p

I was hoping to see something about xDS. I've seen a lot of work being done on adding support for it in gRPC on git but (as usual with gRPC) the docs and blog posts seem to be rare and terse, so I haven't had a chance to learn it yet. Also, does anybody know how gRPC is used at Google? Why do they support its development (other than GCP clients)? I'm under the impression Stubby is a completely different codebase and is far superior and fully integrated in their stack.

rockwotj 5y ago
IIRC, right before I left Google at the end of 2019 you could be added to an allowlist to use gRPC internally. I believe they want to eventually replace Stubby with gRPC. Someone who still works at Google would have to comment on the current state of the world or if my memory is failing. As for Stubby it is a completely different codebase and is tightly integrated with a lot of internal tooling and features. One other thing I miss from Stubby C++ compared to gRPC is that async stubby is super opinionated about it's threading model and came with batteries included, where I find the completion queue approach very hard to use. Lastly, as far as load balancing goes. I think some load balancers with native gRPC support allows you to let different servers get different individual requests instead of requiring all requests go to the same server. Of course this only really works for unary RPC calls. But load balancing HTTP/2 isn't unique to gRPC nor keep alive http/1.1 connections. (Outside of the streaming RPCs of course, but there is an equivalent of websockets)
- z77dj3kl 5y ago
  Thank you! Do you know why they were looking to replace Stubby with gRPC? It doesn't seem to me that gRPC is quite customizable enough currently to hook in all the monitoring and tooling that I imagine Google has. And yes, the completion queue approach is pretty cumbersome, would be very interesting to see how stubby went about it :P
  - rockwotj 5y ago
    > Do you know why they were looking to replace Stubby? Likely to maintain less code long term. It's nice to have a primative like this open source so you can use it everywhere (even on mobile). I'm not sure about the claim that gRPC isn't customizable enough, I think there are a lot of hooks in place. For example Open Census does a lot of the instrumentation that you get for free at Google with Stubby, but for gRPC: https://opencensus.io/zpages/ https://opencensus.io/zpages/ > How stubby went about it: Stubby is a lot closer to the experimental callback API talked about here: https://github.com/grpc/proposal/pull/180 https://github.com/grpc/proposal/pull/180

rockwotj 5y ago

IIRC, right before I left Google at the end of 2019 you could be added to an allowlist to use gRPC internally. I believe they want to eventually replace Stubby with gRPC. Someone who still works at Google would have to comment on the current state of the world or if my memory is failing. As for Stubby it is a completely different codebase and is tightly integrated with a lot of internal tooling and features. One other thing I miss from Stubby C++ compared to gRPC is that async stubby is super opinionated about it's threading model and came with batteries included, where I find the completion queue approach very hard to use. Lastly, as far as load balancing goes. I think some load balancers with native gRPC support allows you to let different servers get different individual requests instead of requiring all requests go to the same server. Of course this only really works for unary RPC calls. But load balancing HTTP/2 isn't unique to gRPC nor keep alive http/1.1 connections. (Outside of the streaming RPCs of course, but there is an equivalent of websockets)

z77dj3kl 5y ago
Thank you! Do you know why they were looking to replace Stubby with gRPC? It doesn't seem to me that gRPC is quite customizable enough currently to hook in all the monitoring and tooling that I imagine Google has. And yes, the completion queue approach is pretty cumbersome, would be very interesting to see how stubby went about it :P
- rockwotj 5y ago
  > Do you know why they were looking to replace Stubby? Likely to maintain less code long term. It's nice to have a primative like this open source so you can use it everywhere (even on mobile). I'm not sure about the claim that gRPC isn't customizable enough, I think there are a lot of hooks in place. For example Open Census does a lot of the instrumentation that you get for free at Google with Stubby, but for gRPC: https://opencensus.io/zpages/ https://opencensus.io/zpages/ > How stubby went about it: Stubby is a lot closer to the experimental callback API talked about here: https://github.com/grpc/proposal/pull/180 https://github.com/grpc/proposal/pull/180