Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Setting yourself up for gRPC success

Joe
March 21, 2019

Setting yourself up for gRPC success

Joe

March 21, 2019
Tweet

More Decks by Joe

Other Decks in Programming

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. 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
  5. - 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!?
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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!
  15. 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
  16. 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.