Setting yourself up for gRPC success

Transcript

1. Setting Yourself Up for gRPC Success gRPC Conf, 22 March 2019 Joe Blubaugh (@joeblubaugh, @LightStepHQ)
2. My short career with RPC systems 2010: CORBA (jacORB & PolyORB) 2011: Stubby (proto2) 2013: http/json (play framework) 2014: Finagle + Twitter Thrift 2016-Present: Apache Thrift -> gRPC My a r e f .
3. My current RPC life Engineering @ LightStep ~30 programmers ~15 Go services client libs in 10+ languages hybrid on-prem releases monorepo
4. yay, gRPC! yay, gRPC? some lessons from experience Agenda
5. yay, grpc!
6. RPCs that feel like file reads or other slow system calls. - You & your callers understand all the RPCs your service exposes. - RPCs use system resources responsibly. - It’s easy to call RPCs the “right way” for your service. - You don’t break the system when you evolve your API. - You get good monitoring information from your RPCs. - Errors are sensible & easy to handle. RPC Shambhala
7. - Write some straightforward protobuf definitions - You & Your clients rely on these as listed API methods - Run a compiler per language to get codecs, network code, and function definitions! - Implement your stub handlers with native data types. - Callers get function defintions that hide the nitty-gritty. gRPC gets us *close* Wha SO /W L, bu d!?
8. yay, grpc?
9. Especially as a client! - client-side load-balancing is tricky to configure - most server-side load balancing won’t work very well! (http2 support is *still young* - kube doesn’t even work out-of-the box) No default deadline out-of-the box. I wish there were safer defaults. gRPC is still *full* of surprises
10. Don’t require gRPC for end-users (on the public internet, consuming your SDK) to talk to your API. In Java we can shade our JARS, other langs have similarly painful workarounds that will make your buildcop *love* you. We wrote a custom binary serializer for a customer to get around this once. (Offer an HTTP/JSON endpoint as well!) gRPC Client Dependency Hell
11. But also as a server! You can’t do admission control *before* deserializing your messages - it would be great if there were interceptors that could run before deserialization. gRPC is still *full* of surprises
12. Still fairly coupled, especially in polyglot environments - Writing your own stub generator is necessary for other IDLs - No other IDL is truly supported across many languages. protoc presents a lot of development annoyances: - package names lead to nasty code results in Go - Installing, compiling, running protoc is gRPC and protoc
13. Also, you get to muck around with oneof message AssemblySpec { oneof charter { uint64 span_id = 1; uint64 trace_id = 2; lightstep.common.AnnotatedSpan span = 3; } } This turns into ~150 lines of Go and 4 “bonus” types. gRPC and protoc
14. RPC frameworks put you pretty far away from your machine. Dev overhead ↘, Ops overhead ↗ (Why the heck are “All SubConns in transient failure”!!!) Things you used to get, you don’t get anymore. Idempotent content caching is not well-supported. Compression is complex, many clients don’t support many algorithms. Spooky Action at a Distance
15. some lessons we’ve learned
16. gRPC won’t stop you from writing confusing APIs! In fact, its flexibility may *help you* write confusing APIs. You could do a lot worse than: https://cloud.google.com/apis/design/ Many of the lessons of REST still apply! Establish an API Design Guide
17. No exceptions! (Someone will always argue for an exception.) - no reusing or changing field numbers. - no downgrading a repeated field If you’re going to support JSON or YAML, you better get even stricter! (Envoy’s rules for frozen APIs are great for this) Simple rules, unfortunately, are not as simple as we think from a first look. (Oh, and stay away from oneof!) Get strict about API evolution rules
18. In fact, there are quite a few client options you’re always going to want configured. Write your company some shared utilities sooner rather than later… You might want to write a linter... Always set a client deadline!
19. Clients somehow always run in *weird* environments where HTTP 1 may be the only reliable networking stack they have access to. If you’re shipping an SDK (or shipping on-prem!), provide a gRPC alternative, too. Own both ends of the channel
20. Read the code! It will surprise you otherwise! At least read the server code for all your languages - they behave differently, sometimes drastically differently, from language to language. Develop in-house expertise.
21. Thanks!