We’ve made it our mission to provide you with the best (and only the best) tools to work with the cloud. That’s why our Top 10 CNCF projects to look out for in 2023 list is being untangled in our blog, explaining each technology and why we are die-hard fans of it. Take a look at the rest of the series!
gRPC is a modern open-source high-performance Remote Procedure Call (RPC) framework that can run in any environment. It can efficiently connect services in and across data centers with pluggable support for load balancing, tracing, health checking, and authentication. It is also applicable in the last mile of distributed computing to connect devices, mobile applications, and browsers to backend services.
What is it?
gRPC was initially created by Google, which used a single general-purpose RPC infrastructure called Stubby to connect the large number of microservices running within and across its data centers from about 2001. In March 2015, Google decided to build the next version of Stubby and make it open source, creating gRPC.
gRPC offers a refreshed take on the old RPC design method by making it interoperable, modern, and efficient using such technologies as Protocol Buffers and HTTP/2. The following benefits make it a solid candidate for replacing REST in some operations.
- Lightweight messages. Depending on the type of call, gRPC-specific messages can be up to 30 percent smaller in size than JSON messages.
- High performance. By different evaluations, gRPC is 5, 7, and even 8 times faster than REST+JSON communication.
- Built-in code generation. gRPC has automated code generation in different programming languages including Java, C++, Python, Go, Dart, Objective-C, Ruby, and more.
- More connection options. While REST focuses on request-response architecture, gRPC provides support for data streaming with event-driven architectures: server-side streaming, client-side streaming, and bidirectional streaming.
The scenarios where gRPC shines best are:
- Efficiently connecting polyglot services in a microservices style architecture.
- Connecting mobile devices, browser clients, and IoT devices to backend services.
- Generating efficient client libraries.
How does it work?
gRPC is unanimously accepted as the best option for communication between internal microservices thanks to two things: unmatched performance and its polyglot nature.
One of the greatest strengths of microservices contrasted with monolithic architecture is the ability to use different technologies for each independent service — whichever would fit best. Microservices must agree on the API to exchange data, data format, error patterns, load balancing, and more. And since gRPC allows for describing a service contract in a binary format, programmers can have a standard way to specify those contracts, independent of any language, that ensures interoperability.
The example of microservices in the online retail case with internal services communication performed via gRPC and external communication using REST or GraphQL Source: TheNewStack
Besides, the ability to transmit multiple concurrent messages without a network overload makes gRPC a great choice for microservice-to-microservice communication that requires superfast message exchange, although REST or GraphQL is still recommended to use for external-facing microservices because of their text-based messaging directed at human consumers.
Napptive enables developer self-service. We encourage you to try our playground and experience accelerated cloud-native development. It’s completely free, all you need to do is simply sign up and get started!
Where can I see it working?
There are many companies successfully using gRPC, but maybe the two examples that illustrate the true power of this tool the most are Salesforce and Nulab.
Salesforce was looking for a tool that allowed them to establish a unified interoperability strategy across the company, with backward compatibility built from the beginning and an understanding of different languages (since the organization is formed by different companies acquired over the years, their codebase is written in a plethora of programming languages).
They decided to try gRPC for its contract-driven development practices and the technical features that it offers over basic HTTP and JSON, and found that it works beautifully with a service mesh for distributing service contracts so that teams can have a very well-understood, well-defined interface between each other over the network. Also, the fact that it’s a binary protocol over HTTP2 makes it more flexible for designing streaming services and push notification-type services. gRPC has improved developer velocity and allowed dramatic changes to be made with just a handful of people on the team. Their plan is to go full CNCF, incorporating their Kubernetes-based stack Istio with Envoy and gRPC.
On the other hand, Nulab had some challenges on its own: their monolith legacy Java application for its diagramming product, Cacoo, was hampering productivity because the technology was too old and adding new features took too long. Also, as the company expanded to offices on three continents, engineers needed to be able to develop the same application across time zones. They broke down their monolith into microservices, in a Kubernetes stack with Prometheus, Envoy, and gRPC, and the improvement was quick to follow: the deployment of new code to production is now 6 times faster than before, since deployments that before took 40 minutes or more now are reduced to 6 minutes tops. The satisfaction of the dev team has improved too, and even onboarding new engineers now takes a day instead of a week. They started migrating their legacy monolith to microservices, but the spectacular success has given them the push they needed to adopt a microservice architecture in other teams across the whole organization.
In case you have not yet tried Napptive, we encourage you to sign up for free and discover how we are helping propel the development of cloud-native apps.
