So… what are RPCs in Software Engineering and Distributed Computing (2024)

Understanding Remote Procedure Calls and their benefits to modern system design

Devansh

In today’s interconnected world, systems communication plays a vital role in enabling seamless interactions between various components. Remote Procedure Calls (RPCs) have emerged as a fundamental mechanism for communication b/w processes in modern systems design. In today’s edition of Tech Made Simple, we will explore what RPCs are, why they are prevalent in modern system architectures, and how they work.

So… what are RPCs in Software Engineering and Distributed Computing (3)

Important announcement: We started an AI Made Simple Subreddit. Come join us over here- https://www.reddit.com/r/AIMadeSimple/

My message is not that HTTP/REST is better than RPC. If the goal of your API is to enable communication between two distributed components that you own and control, and processing efficiency is a major concern, then I think that RPC in general and gRPC in particular might be excellent choices for designing and implementing your API.
However, if your primary objective is to make your software more malleable by breaking it down into components that are better isolated from each others’ assumptions, or if your purpose is to open up your systems for future integration by other teams, then you should focus your efforts on HTTP/JSON APIs — provided you learn to use HTTP as simply and directly as possible. That way, anyone who knows HTTP from the standards documents or a multitude of less formal tutorials will be able to use your API, with no more documentation than a description of the API’s entity model and a little bit of query syntax. I think that’s a worthy goal.
-REST vs RPC: What problems are you trying to solve with your APIs?, Google Cloud Blog

Join 150K+ tech leaders and get insights on the most important ideas in AI straight to your inbox through my free newsletter- AI Made Simple

What are RPCs?- To quote Wikipedia, “In distributed computing, a remote procedure call (RPC) is when a computer program causes a procedure (subroutine) to execute in a different address space (commonly on another computer on a shared network), which is written as if it were a normal (local) procedure call, without the programmer explicitly writing the details for the remote interaction. That is, the programmer writes essentially the same code whether the subroutine is local to the executing program, or remote.” In a world with specialized hardware, this is a huge deal.

RPCs have been a mainstay in modern systems for a variety of reasons-

Modularity and Scalability: RPCs promote modularity by encapsulating functionality into independent services or modules. This modular design enables teams to develop and maintain individual components separately, leading to increased scalability and system flexibility.
Efficiency- The remote hosted nature of RPCs enables people to use specialized hardware for certain tasks. For example, hardware like CPUs and TPUs are very useful it comes to AI. You could leverage RPCs to call AI routines hosted on a server with this specialized hardware, and simply return the results.
Microservices and Distributed Computing: RPCs play a crucial role in microservices architectures, where systems are built as a collection of small, independent services. The ability to invoke remote procedures allows microservices to communicate and collaborate seamlessly, facilitating the development of complex, distributed systems.
Language and Platform Independence: RPC frameworks provide a language-agnostic and platform-independent communication mechanism. They allow systems developed in different programming languages or running on different platforms to interact with each other, promoting interoperability and integration.

How do RPCs Work? — Take a look at this chart by Microsoft in their blog How RPC Works. The linked article is a good (more detailed) overview of the topic. For our purposes, I will cover a simplified look at the system.

So… what are RPCs in Software Engineering and Distributed Computing (4)

RPCs operate as following-

The client program makes a call to the remote procedure, passing in any necessary parameters (this involves calling the stub).
The RPC system creates a request message containing the name of the procedure to be called and the parameters to be passed to the procedure.
The RPC system sends the request message to the server.
The server receives the request message and calls the specified procedure.
The procedure executes and returns a result.
The server creates a response message containing the result of the procedure call.
The server sends the response message back to the client.
The RPC system on the client receives the response message and returns the result to the client program.

As with all things RPCs have a few drawbacks that you might want to consider-

Costs- The additional steps (stubs, interacting b/w client server, memory locations) add to the overhead costs of the system.
Failure- As with any technique that requires communication over a network, network failures are always a demon you’ll have to dance with.
Lack of Uniformity- There is no one way to implement RPCs in a distributed system. This can lead to incompatible protocols and hard-to-spot failures, especially as your system grows in complexity.
False Sense of Security-This excellent Stack Overflow discussion on RPCs had this to say, “Waldo et al. describe the problem very well (seriously, it’s an excellent paper). Distributed systems have problems not found in standalone systems: latency; partial failure; different memory access models. These are the “hard parts” of distributed computing. RPC solves the “easy part”: marshalling and unmarshalling data, while papering over the hard parts, and most likely leading to a false sense of security.”

If you have a lot of free time/ a burning passion for RPCs, this is a pretty good read.

Overall, RPCs are a powerful tool for building distributed computing systems. They offer several advantages, such as efficiency, scalability, and flexibility. When appropriate, they can enable you to handle communication between various services in a fairly easy way. They’re a good tool to have in your tool belt.

That is it for this piece. I appreciate your time. As always, if you’re interested in working with me or checking out my other work, my links will be at the end of this email/post. If you like my writing, I would really appreciate an anonymous testimonial. You can drop it here. And if you found value in this write-up, I would appreciate you sharing it with more people. It is word-of-mouth referrals like yours that help me grow.

Save the time, energy, and money you would burn by going through all those videos, courses, products, and ‘coaches’ and easily find all your needs met in one place at ‘Tech Made Simple’! Stay ahead of the curve in AI, software engineering, and the tech industry with expert insights, tips, and resources. 20% off for new subscribers by clicking this link. Subscribe now and simplify your tech journey!