Intro to Cloud Native Remote Procedure Call Services

Even though cloud services have achieved mainstream adoption over the last decade, their growth continues at an impressive rate. Gartner’s recent projections indicate that the public cloud services market will grow another 17% in 2020.

Of course, the shift means developers need to adapt. Cloud native applications require a more modular, agile, and scalable approach to development. As a result, developers need a new set of tools which address the unique challenges of cloud application delivery.

The CNCF’s (Cloud Native Computing Foundation) interactive cloud native landscape is an excellent tool for filtering popular services for cloud native development. However, without context it can be difficult to fully grasp. Mantas Levinas’ The Complete Overview of DevOps Cloud Native Tools Landscape helps make the landscape more accessible and easier to navigate. In this piece, I’ll dive into the specifics of the cloud native remote procedure call (RPC) subcategory. By the end of this piece, you’ll have an idea of what RPC is, how it works, its benefits, and some of the most popular services for implementing it.

#Intro to Cloud Native Remote Procedure Call Services

What is RPC exactly? In short, a remote procedure call is a way for a local program to execute a procedure from a different address space (e.g. a different container).

RPC isn’t new. In fact, developers have been using services such as DCE/RPC (Distributed Computing Environment / Remote Procedure Calls) for a couple of decades now. Cloud native remote procedure calls are different from legacy implementations in a few ways. First, protocol incompatibility limited the extensibility of legacy RPC technology. Modern RPCs are also generally more lightweight and performant. Further, older approaches to remote procedure calls don’t offer support for modern functionality such as streams.

Most cloud native RPC implementations use a client/server model for communications. There are a variety of different implementations and flavors of RPC, but they all follow the same basic workflow. The client sends a call with specific parameters, and the server returns the result. Additionally, RPC makes it easy for microsystems written in different languages to communicate; for example, by using protocol buffers.

#Is gRPC better than REST?

One of the more common questions developers new to cloud native RPCs ask is: “why use RPC instead of REST?”. This is particularly true of the Google-developed gRPC (gRPC Remote Procedure Calls). In fact, “Why is gRPC better/worse than REST?” is an FAQ on gPRC’s website. However, viewing these questions through the lens of one being better or worse isn’t the right way to go. Choosing between RPC and REST for a given use case is all about selecting the right tool for the job.

Phil Sturgeon took an unbiased approach to the topic of REST vs RPC in his Understanding RPC Vs REST For HTTP APIs article, and I’ll provide a condensed version here. REST works well to provide CRUD (create, read, update, delete) operations on a data set. RPC is often a better choice in scenarios where triggering actions, such as sending a message to a user, is a large chunk of the requirements. Additionally, gRPC’s use of Protobuf messages can deliver payloads in a more efficient manner than plaintext JSON format common to REST implementations.

#Streaming & Request Response

In addition to a standard request and response approach to communication, RPC implementations that support HTTP/2, like gRPC, enable streaming. For example, gRPC calls out four discrete service methods:

• Unary RPCs - The traditional single request client/server model. A client sends a request and gets a single response from the server.
• Server streaming RPCs - A client sends a request and gets a stream of messages back. In this model, the client reads until messages are no longer sent. gRPC takes care of the messaging sequence within discrete calls.
• Client streaming RPCs - A client creates a message stream and sends it to the server. The client waits for a server response after all messages are sent. gRPC takes care of the messaging sequence within discrete calls.
• Bidirectional streaming RPCs - Both the server and the client send messages via a read/write stream. The individual streams are independent allowing servers and clients to read or write messages however they choose. gRPC ensures proper ordering of messages in a given stream.

#Benefits of cloud native remote procedure calls

As a result of their lightweight, performant, and polyglot nature, Cloud native remote procedure calls offer a number of benefits, including:

• Protocol Buffers enable language-neutrality;
• Streaming support;
• Efficient data transport thanks to binary data formats (compared to textual JSON formats).

This makes cloud native RPC services useful for applications such as microservices and polyglot applications where many languages are used.

#Popular Cloud Native Remote Procedure Call Services

With the basics of RPC out of the way, let’s review some of the services in the CNCF’s Remote Procedure Call subcategory.

#gRPC

gRPC is the industry darling in this category. It is an open source RPC service that was initially developed by Google. It has grown to be one of the most popular RPC services for cloud native applications. gRPC can run in effectively any environment and supports load balancing, health checks, and authentication. Once up and running, the gRPC framework can support millions of remote procedure calls per second. Organizations including Netflix, Cisco, and Juniper all trust gRPC in production environments.

#Apache Thrift

Apache Thrift was initially developed at Facebook and is now open source under the Apache License 2.0. Thrift has many similarities to gRPC, but there are a few notable differences. For example, where gRPC uses Protocol Buffers, Thrift uses .thrift files. Additionally, Thrift has support for more languages “out of the box”, while gRPC is known for better documentation and better performance.

#Dubbo

Apache Dubbo is an open source Java-based RPC framework developed by Alibaba Group. The framework emphasizes performance and extensibility. It has a large user base and has more stars on GitHub than the widely popular gRPC. The most common use case for Dubbo is within the Spring Framework for Java enterprise applications. Dubbo’s features include intelligent load balancing, traffic routing at runtime, automatic service registration and discovery, and service governance tools.

#SOFARPC

SOFARPC is an open source Java-based RPC framework targeted to the financial industry. It is one of several SOFASTACK projects targeting the sector. Ant Financial open sourced SOFARPC and continues to use the framework for their own remote procedure calls as well. SOFARPC supports multiple underlying protocols, including Dubbo. SOFARPC features include load balancing, link tracing, fault removal, and traffic forwarding.

#Final thoughts

We hope you found our explanation of cloud native remote procedure calls useful. These tools can help you create more efficient, lightweight, and performant cloud native apps. If you’d like to learn more about cloud native, subscribe to our blog or reach out to our team of experts today!