Application Load Balancers enables gRPC workloads with end to end HTTP/2 support • Hacker News Board

Re: Application Load Balancers enables gRPC workloads with end to end HTTP/2 support

#111

Post by random3 » Fri, Oct 30, 2020, 11:41 PM UTC

jeffbee wrote: post #68

malkia wrote: post #61

Used stubby at Google (mainly java), and was intimidated first, then saw the light - when almost everything uses the same way of talking, not only you get C++, java, python, go and other languages speaking freely to each other, but other extra benefits - for example each RPC can carry as a "tag" (key/value?) the user/group it came from, and this can be used for budgeting: For example - your internal backend A, calls…

Unfortch, gRPC brings none of these things. If you want delegated caller, originator, trace ID, or any other kind of baggage propagated down your RPC call graph, you are doing it yourself with metadata injectors and extractors at every service boundary.

jeffbee, actually, you do and it works well, you don't have to do more than use a library. You get it out of the box in GCP. It works with Opentelemetry / OpenCensus Dapper was not embedded in Stubby either.

Re: Application Load Balancers enables gRPC workloads with end to end HTTP/2 support

#112

Post by tveita » Fri, Oct 30, 2020, 11:51 PM UTC

Guthur wrote: post #84

coder543 wrote: post #71

Earlier quoted context omitted.

I'm not saying they're hard questions. They're annoying, pointless questions that I have to answer every single time I create or consume a REST API. Those pointless questions also create very real bugs that I have dealt with for years , because humans make mistakes. It's a complete waste of time and energy for everyone involved. Every one of these questions creates additional mental overhead and an opportunity for in…

If you're working in a group think conformist organisation with a single mono repo like Goolge then gRPC certainly has some allure. But if I'd like to remain a little more decoupled it's not very good at all. REST is definitely not a magic bullet either because more often than not we fail to do that hard modelling aspect well enough.

> But if I'd like to remain a little more decoupled it's not very good at all.

It works quite well, IME. Each service publishes its protobuf files to a repository or registry during the build step, and if you want to call it from another service you just import the protobuf file and get a defined and documented interface with little to no boilerplate required to use. Protobuf has clear rules on how to evolve the interface in a backwards compatible way, so services can usually stay on the old definition until you need some new functionality, at which point you import the newest definitions.

https://github.com/uber-archive/idl defines a good workflow for this, though the tool is sadly unmaintained. Done right it really reduces the pain of crossing repository boundaries.

Re: Application Load Balancers enables gRPC workloads with end to end HTTP/2 support

#113

Post by gravypod » Sat, Oct 31, 2020, 1:05 AM UTC

jeffbee wrote: post #68

malkia wrote: post #61

Used stubby at Google (mainly java), and was intimidated first, then saw the light - when almost everything uses the same way of talking, not only you get C++, java, python, go and other languages speaking freely to each other, but other extra benefits - for example each RPC can carry as a "tag" (key/value?) the user/group it came from, and this can be used for budgeting: For example - your internal backend A, calls…

Unfortch, gRPC brings none of these things. If you want delegated caller, originator, trace ID, or any other kind of baggage propagated down your RPC call graph, you are doing it yourself with metadata injectors and extractors at every service boundary.

I've started implementing some of this at my job. We have an internal proto that describes the config of a gRPC service. We then have a library for all of our languages that turns that proto into a Channel that's instrumented with everything from middlewares to low level socket settings (keep alive, idle timeouts, retries, hedging, etc). Makes our deployments super easy as well since every service is configured to talk to every other service in almost a 100% identical way.

Re: Application Load Balancers enables gRPC workloads with end to end HTTP/2 support

#114

Post by gravypod » Sat, Oct 31, 2020, 1:16 AM UTC

diogenesjunior wrote: post #4

Can somebody please explain to me why we would use gRPC?

My main reasons:

1. It's standardized all the implementation for each language is roughly similar and has the same feature sets (middlewares, stubs, retry, hedging, timeouts, deadlines, etc).

2. High performance framework/webserver in "every" language. No more "should I use flask or the built in http server or gunicorn or waitress or..."

3. Tooling can be built around schemas as code. There's a great talk that I highly recommend about some of the magic you can do [0].

4. Protos are great for serialization and not just over a network! Need to store configs or data in a range of formats (json, prototxt, binary, yaml)?

5. Streaming. It's truely amazing and can dramatically reduce latency if you need to do a lot of collection-of-things or as-soon-as-x processing.

6. Lower resource usage. Encoding/decoding protos is faster then encoding and decoding json. At high throughput that begins to matter.

7. Linting & standards can be defined and enforced programatically [1]

8. Pressures people to document things. You comment your .c or .java code, why not comment your .proto?

[0] - https://youtu.be/j6ow-UemzBc?t=435

[1] - https://google.aip.dev/

Re: Application Load Balancers enables gRPC workloads with end to end HTTP/2 support

#115

Post by gravypod » Sat, Oct 31, 2020, 1:20 AM UTC

Guthur wrote: post #69

coder543 wrote: post #26

Earlier quoted context omitted.

Things I "love" about REST APIs: - How should I pass an argument? Let me count the many ways: 1. Path parameters 2. Query parameters in the URL 3. Query parameters in the body of the request 4. JSON/YAML/etc. in the body of the request 5. Request headers (yes, people use these for API tokens, API versions, and other things sometimes) - There's also the REST verb that is often super arbitrary. PUT vs POST vs PATCH...…

Because all those questions are the easy ones. gRPC is not a magic bullet for the problems of state management. It'll have all the same issues RPC has had for the last 30 years in that it enforces no discipline where it counts, state management. The real problem with REST is that state management across a distributed system is hard, real hard. So hard actually that we decide to ignore that it's a problem at all and i…

gRPC is a great way to implement a RESTful API [0]. Instead of saying `POST /thing` or `POST /things` or actually `PUT /thing` and maybe `POST /thing/1` you can say:

    service ThingService {
      rpc CreateThing(CreateThingRequest) returns (Thing);
      rpc DeleteThing(DeleteThingRequest) returns (ThingDeleted); // No arguing about if this is within the HTTP spec and supported as it just works :)
      rpc UpdateThing(...) returns (Thing); 
      rpc ListThings(...) returns (stream Thing);
    }

[1] - https://google.aip.dev/121

Re: Application Load Balancers enables gRPC workloads with end to end HTTP/2 support

#116

Post by gravypod » Sat, Oct 31, 2020, 1:29 AM UTC

jwalton wrote: post #95

q3k wrote: post #10

Earlier quoted context omitted.

Sure. You would use gRPC when: - You want to have inter-service RPC. - You want not only unary calls, but also bidirectional streaming. - You want a well-defined schema for your RPC data and methods. - You want a cross-language solution that guarantees interoperability (no more JSON parsing differences! [1]) [1] - http://seriot.ch/parsing_json.php

In other words, when you want to use ASN.1[0], but you don't know what ASN.1 is so you use something the overly complicated version Google made instead. ;) [0]( https://en.wikipedia.org/wiki/Asn.1 )

Do you have any code samples that demonstrate the code generator, instrumentation, and observability tools for ASN.1?

How do I code gen clients/servers for Java, Python, Golang, C++, Node, PHP, etc. How can I instrument distributed tracing for requests? How do I talk to these services from my web frontend (grpc web equivalent)? How do I talk to these from my embedded system (proto lite equivalent)?

Re: Application Load Balancers enables gRPC workloads with end to end HTTP/2 support

#117

Post by jwalton » Sat, Oct 31, 2020, 1:34 AM UTC

wahern wrote: post #104

jwalton wrote: post #95

Earlier quoted context omitted.

In other words, when you want to use ASN.1[0], but you don't know what ASN.1 is so you use something the overly complicated version Google made instead. ;) [0]( https://en.wikipedia.org/wiki/Asn.1 )

To be fair, in practice people don't choose gRPC as a protocol and serialization standard so much as they choose preexisting gRPC libraries and code generators. Open source ASN.1 tooling sucks while Google maintains gRPC tooling for a great many languages. This is why gRPC, Thrift, etc have so much more mindshare than ASN.1 in the open source community. The only good open source ASN.1 (DER, PER, etc) code generator f…

I gather the protobuf/gRPC implementations are quite good for a lot of languages, but I can tell you typescript doesn't seem to be one of them. There's an etcd client for node which doesn't seem to be actively maintained, and I only needed a few things out of etcd, so I figured I'd just generate a gRPC client and build my own library [0] to do what I needed. This was not fun. I got all kinds of crazy errors about missing definitions, and I ended up having to copy paste .proto files from a bunch of random google projects into my repo to make this all work. Maybe I'm just doing it completely wrong? :P

[0](https://github.com/jwalton/etcd3-ts)

Re: Application Load Balancers enables gRPC workloads with end to end HTTP/2 support

#118

Post by gravypod » Sat, Oct 31, 2020, 1:36 AM UTC

q3k wrote: post #19

k__ wrote: post #16

Earlier quoted context omitted.

I see, cool. So the spec already includes versioning?

No, gRPC/protobuf instead provides you with ways to evolve your schema easily in the IDL and the result on the wire, without breaking either side. You can rename fields (but keep the tag number and therefore wire format compatibility), add fields (which will be ignored by the other side), remove fields (as all are explicitly optional so every consumer explicitly checks for their presence anyway), ignore unset fields…

Another important part about forward-and-backward-compat is that protos support passing unknown fields. If I add a new field into a shared proto that A, B, and C all use if A and C have been updated but B was never updated as long as B uses the proto correctly it will have the new field delivered to C.

I use this at my current job where our client is a hardware appliance that we are not at all allowed to update so, if we need to add new data for our backend to handle that the client downloads locally we can and we don't need to worry about pushing new client code to do it.

This is magic for anyone who has been using Retrofit or something similar and sees fields dropping as normal.

Re: Application Load Balancers enables gRPC workloads with end to end HTTP/2 support

#119

Post by jwalton » Sat, Oct 31, 2020, 1:37 AM UTC

sagarm wrote: post #102

jwalton wrote: post #95

Earlier quoted context omitted.

In other words, when you want to use ASN.1[0], but you don't know what ASN.1 is so you use something the overly complicated version Google made instead. ;) [0]( https://en.wikipedia.org/wiki/Asn.1 )

This seems like a very high level spec, not a library or toolkit. There's also zero mention of practical concerns like protocol evolution, a canonical wire encoding etc.

ASN.1 is indeed a spec. You'd need to find a library to use it, and there are more in C than in whatever fancy modern language you're probably using. But, there are lots to choose from.

There's multiple canonical wire encodings. XER is the "XML encoding rules" if you want something human readable. "BER" is the binary format, although it has some ambiguities so there's "DER", the Distinguished Encoding Rules, which resolves a lot of that by using essentially a subset of BER and specifying how you should behave in various corner cases. In practice, you want to write your messages as DER, but accept messages from other parties using the full BER.

It's an older standard, but it's used heavily in telecom. To pick an example, if you make a cell phone call, especially out in the sticks somewhere, there's probably going to be a media gateway controller that figures out how to route your call without decompressing and recompressing it a bunch of times, and it talks to the various devices routing your call over H.248, which is specified entirely in ASN.1.

Re: Application Load Balancers enables gRPC workloads with end to end HTTP/2 support

#120

Post by tootie » Sat, Oct 31, 2020, 1:51 AM UTC

Guthur wrote: post #69

coder543 wrote: post #26

Earlier quoted context omitted.

Things I "love" about REST APIs: - How should I pass an argument? Let me count the many ways: 1. Path parameters 2. Query parameters in the URL 3. Query parameters in the body of the request 4. JSON/YAML/etc. in the body of the request 5. Request headers (yes, people use these for API tokens, API versions, and other things sometimes) - There's also the REST verb that is often super arbitrary. PUT vs POST vs PATCH...…

Because all those questions are the easy ones. gRPC is not a magic bullet for the problems of state management. It'll have all the same issues RPC has had for the last 30 years in that it enforces no discipline where it counts, state management. The real problem with REST is that state management across a distributed system is hard, real hard. So hard actually that we decide to ignore that it's a problem at all and i…

Protobuf, thrift, avro, cap'n proto just off the top of my head. There is no shortage of RPC protocols and implementations and none of them have very wide adoption.