I recently attended the Linux Foundation’s first ever gRPC Conference in Sunnyvale, California and gave a presentation on some work that I’ve been doing to connect the increasingly popular open source remote procedure call (RPC) system with Istio and Envoy. In this first of two blogs, I’ll briefly explain what gRPC does for those who don’t know it and offer some reflections on the conference. Next time, I’ll share a digest of the main points I made in my talk.
gRPC is a universal, high-performance, open source RPC framework based on HTTP/2. Essentially, it lets you easily define a service using Protocol Buffers (Protobufs), works across multiple languages and platforms, and is simple to set up and scale. All of that leads to better network performance and flexible API management. It started life as Google’s internal RPC protocol—hence the “g” in the name—which at the time was called Stubby. In 2015, Google open sourced it under the name gRPC.
gRPC was very much built with microservices in mind, but at the conference I learned that people are now using it for much more than that. For me, that’s always a sign that a project is making a significant contribution to the community. For example, I heard about a company that has been experimenting with using gRPC to connect a TV with their backend. Another is using it to control microphones while a third company is deploying it in hardware network switches.
Indeed, a major theme of the 10 or so talks at the conference was how teams are looking to benefit from moving away from their existing infrastructure to gRPC, as well as the challenges that they are facing as they transition. Among the biggest gains they report is being able to work with a standard interface definition language (IDL). They can define their entire API and data model in a single place and language. From that, gRPC’s protobuf generates the stubs and everything else they need without having to write it themselves.
Since gRPC is based on HTTP/2, they can also use channels to multiplex data, which offers major improvements in performance. gRPC is also helpful with client generation. When someone defines an API using Protobufs and uses gRPC to generate the stubs, they also get clients that they can then directly use in different sets of languages without having to implement the API client themselves.
In all, over 200 people attended the conference, including representatives from companies like Dropbox, Indeed, Verizon, Intuit and, of course, Google. So, while it wasn’t an enormous gathering, I also got the sense that this is definitely a productive and growing area to be working in. It was also great to meet some important gRPC contributors in-person, such as gRPC-Web maintainer Stanley Cheung and April Nassi, the community manager for both gRPC and Istio and a key organizer of the event. I learned a huge amount in the relatively short time that we were able to speak—a reminder of why it’s worth attending these kinds of events when you can.
In my next post, I’ll talk about my own presentation to the conference, which explored how web applications can benefit from gRPC by adding a service mesh like Istio to the mix. Stay tuned to the Open Source Blog and our Twitter (@vmwopensource) for when that post goes live.
