gRPC Conf 2019

gRPC provides powerful capabilities for teams building distributed computing systems. This power comes with a wide variety of footguns, and your team only has so many feet! In this session we'll discuss several pitfalls we've encountered using gRPC at LightStep and the practices we've implemented to help all of our engineers use gRPC effectively.

We'll talk about client load balancing strategies (and when to avoid using client-side load balancing!), service discovery setups that work at small and medium scales, and observability configurations that help you build understandable systems. We'll talk about a few mistakes LightStep's made so you can avoid some of the holes we stepped in.

Historically, Indeed has used Boxcar (Indeed’s proprietary framework) to build distributed systems. Over the last year, we have been shifting several of our systems to use gRPC. The first question product teams often ask is “How does gRPC compare to Boxcar?” In this presentation, I put the two frameworks head to head and present the results. I show how my team established some common workloads and gathered metrics to better inform other engineers. We learned a lot about how to optimize the gRPC Java library when performing this analysis. In closing, I present the lessons that we learned performance tuning gRPC services and how you can leverage this information for your own services.

"gRPC is the worst form of APIs, except for all the others."

Those may not have been Churchill's *exact* words, but the point stands. gRPC has warts, yet I miss it when it's gone.

I'll delve into some war stories experienced as an end user of both gRPC and various alternatives, as well as some nontraditional practices (whether "best" or not is left as an exercise to the reader) I've developed as workarounds for various problems. Ultimately, I'll posit some dreams for the next big version of gRPC.

Expect to walk away thinking about what gRPC's future could hold - and what to do in the mean time!