6 ms·

The author is talking about keeping things simple which is not a bad idea. I am genuinely interested in why etcd switched to gRPC?

m463 6y ago
It must speak gRPC before it can be subsumed by systemd. (joking)
KaiserPro 6y ago
the need for speed, or something.
alpb 6y ago
First of all etcd API is still available on a JSON interface. https://github.com/etcd-io/etcd/blob/master/Documentation/dev-guide/api_grpc_gateway.md https://github.com/etcd-io/etcd/blob/master/Documentation/de... and some historical discussion here: https://github.com/etcd-io/etcd/issues/1980 https://github.com/etcd-io/etcd/issues/1980 Many reasons to switch from JSON to gRPC: * gRPC uses HTTP/2 which means you can concurrently make multiple requests on a single TCP connection, while on a typical JSON API which probably uses http/1.1, you can't. * Type safety of protobuf types. * Bi-directional streaming e.g. Kubernetes controllers use the Watch API which notifies the object changes/add/deletes in etcd to the control plane. * Client libraries are automatically generated, and not error prone. * RPCs are already optimized for bytes on the wire efficiency, whereas JSON is not. This matters a great deal as Kubernetes objects get large in size/quantity over time but controllers still work effectively by not spending too much CPU on encoding/decoding like they do on JSON. * Similar to the previous point, most json decoders don't reuse objects, so every decoded object is a new alloc, whereas gRPC can Reset() and reuse the same object while decoding/encoding. * Builtin authentication primitives (such as JWT/tokens or even adding TLS to client and/or server). * gRPC has support for interceptors which are like middleware functions you can inject to requests/responses on both client and server-side for logging, authorizing etc. The list goes on, but something to note is that etcd was not developed by Google (and as far as I know, not by ex-Googlers). Both etcd and gRPC are owned by the same open source foundation, so it's natural that they make use of an existing technology.
- mcguire 6y ago
  "The gateway accepts a JSON mapping for etcd's protocol buffer message definitions." Was a "JSON mapping for etcd's protocol buffer message definitions" the original "HTTP API"? "A Critique of the Remote Procedure Call Paradigm" (https://pdfs.semanticscholar.org/e125/57a7582881a62040eee68bff0f51c4381473.pdf https://pdfs.semanticscholar.org/e125/57a7582881a62040eee68b...) "A Note on Distributed Computing" (https://github.com/papers-we-love/papers-we-love/blob/master/distributed_systems/a-note-on-distributed-computing.pdf https://github.com/papers-we-love/papers-we-love/blob/master...)
- brabel 6y ago
  > gRPC uses HTTP/2 ... while on a typical JSON API which probably uses http/1.1, you can't. What are you actually talking about? An HTTP API by itself doesn't actually care about which http version is used, that's something only the HTTP server that serves the API should care about (nowadays, pretty much any http server in any language supports HTTP/2 and 1.1). > Bi-directional streaming e.g. Kubernetes controllers use the Watch API which notifies the object changes/add/deletes in etcd to the control plane. Even HTTP/1.1 has mechanisms for that, like long polling and chunk encoding (which allows infinite streams to keep a dual channel of communication open where each chunk can be treated as a message - with "headers" and all). > Client libraries are automatically generated, and not error prone. This is true, but we've had similar technology since the SOAP days... you could easily do the same with a XML-based HTTP API. By the way, most of your points are against JSON, not a HTTP API per se, which usually would allow a number of formats , including XML and JSON at least. > Builtin authentication primitives... HTTP also has that when you include cookies and something like OAuth/OpenID. > gRPC has support for interceptors which are like middleware functions This kind of thing is better done by using the specific platform you're running on (depends on the language) so I don't see something like this as something desirable on the specific RPC framework you're using. With HTTP, caching, logging etc are trivial to do and one of the strongest advantages of using HTTP in the first place, so I think you're confusingly making a point for HTTP here, unless your focus is on the RPC side of things? In which case, you would have to make a case on why RPC is a better fit than HTTP for etcd, which you haven't. So all in all, I found your points utterly unconvincing, but presented with so much conviction that you're actually right that I could not resist to respond (even if I don't want at all to get into a pointless discussion on the merits of HTTP VS RPC or JSON VS Protobuffers)!
jnwatson 6y ago
Speed, efficiency, and type checking are the main reasons.

m463 6y ago

It must speak gRPC before it can be subsumed by systemd. (joking)

KaiserPro 6y ago

the need for speed, or something.

alpb 6y ago

First of all etcd API is still available on a JSON interface. https://github.com/etcd-io/etcd/blob/master/Documentation/dev-guide/api_grpc_gateway.md https://github.com/etcd-io/etcd/blob/master/Documentation/de... and some historical discussion here: https://github.com/etcd-io/etcd/issues/1980 https://github.com/etcd-io/etcd/issues/1980 Many reasons to switch from JSON to gRPC: * gRPC uses HTTP/2 which means you can concurrently make multiple requests on a single TCP connection, while on a typical JSON API which probably uses http/1.1, you can't. * Type safety of protobuf types. * Bi-directional streaming e.g. Kubernetes controllers use the Watch API which notifies the object changes/add/deletes in etcd to the control plane. * Client libraries are automatically generated, and not error prone. * RPCs are already optimized for bytes on the wire efficiency, whereas JSON is not. This matters a great deal as Kubernetes objects get large in size/quantity over time but controllers still work effectively by not spending too much CPU on encoding/decoding like they do on JSON. * Similar to the previous point, most json decoders don't reuse objects, so every decoded object is a new alloc, whereas gRPC can Reset() and reuse the same object while decoding/encoding. * Builtin authentication primitives (such as JWT/tokens or even adding TLS to client and/or server). * gRPC has support for interceptors which are like middleware functions you can inject to requests/responses on both client and server-side for logging, authorizing etc. The list goes on, but something to note is that etcd was not developed by Google (and as far as I know, not by ex-Googlers). Both etcd and gRPC are owned by the same open source foundation, so it's natural that they make use of an existing technology.

mcguire 6y ago
"The gateway accepts a JSON mapping for etcd's protocol buffer message definitions." Was a "JSON mapping for etcd's protocol buffer message definitions" the original "HTTP API"? "A Critique of the Remote Procedure Call Paradigm" (https://pdfs.semanticscholar.org/e125/57a7582881a62040eee68bff0f51c4381473.pdf https://pdfs.semanticscholar.org/e125/57a7582881a62040eee68b...) "A Note on Distributed Computing" (https://github.com/papers-we-love/papers-we-love/blob/master/distributed_systems/a-note-on-distributed-computing.pdf https://github.com/papers-we-love/papers-we-love/blob/master...)
brabel 6y ago
> gRPC uses HTTP/2 ... while on a typical JSON API which probably uses http/1.1, you can't. What are you actually talking about? An HTTP API by itself doesn't actually care about which http version is used, that's something only the HTTP server that serves the API should care about (nowadays, pretty much any http server in any language supports HTTP/2 and 1.1). > Bi-directional streaming e.g. Kubernetes controllers use the Watch API which notifies the object changes/add/deletes in etcd to the control plane. Even HTTP/1.1 has mechanisms for that, like long polling and chunk encoding (which allows infinite streams to keep a dual channel of communication open where each chunk can be treated as a message - with "headers" and all). > Client libraries are automatically generated, and not error prone. This is true, but we've had similar technology since the SOAP days... you could easily do the same with a XML-based HTTP API. By the way, most of your points are against JSON, not a HTTP API per se, which usually would allow a number of formats , including XML and JSON at least. > Builtin authentication primitives... HTTP also has that when you include cookies and something like OAuth/OpenID. > gRPC has support for interceptors which are like middleware functions This kind of thing is better done by using the specific platform you're running on (depends on the language) so I don't see something like this as something desirable on the specific RPC framework you're using. With HTTP, caching, logging etc are trivial to do and one of the strongest advantages of using HTTP in the first place, so I think you're confusingly making a point for HTTP here, unless your focus is on the RPC side of things? In which case, you would have to make a case on why RPC is a better fit than HTTP for etcd, which you haven't. So all in all, I found your points utterly unconvincing, but presented with so much conviction that you're actually right that I could not resist to respond (even if I don't want at all to get into a pointless discussion on the merits of HTTP VS RPC or JSON VS Protobuffers)!

jnwatson 6y ago

Speed, efficiency, and type checking are the main reasons.