Re-Reading Tanenbaum’s Critique of RPC 30 Years Later
I’m mostly lost on the discussion of RPC. This article delves into the historical and more abstract &#x2F; academic ideas of RPC. By the time I started working in industry, I only know about RPC in practice rather than theory. I’ve never bothered to know the details of RPC, but the main idea ( in practice ) is one computer calling another. Servers have some identifier &#x2F; address, and the RPC call involves some agreement on the message format. In other words, an API contract + some infrastructure on how to resolve computer names. If it was external, we call it an API over HTTP.  Nowadays, we just call the RPC topology as microservices, which is usually an HTTP API, just not on the public internet.<p>I found these bits to be golden:<p>&gt; There is a widespread tendency in computing to adopt more important sounding names for something than is either warranted or is just plain wrong, such as, calling the graph of a network, a topology; calling the chief engineer on a project, the architect; calling a protocol, an API; calling almost anything a new paradigm; etc. There seems to be some deep-seated insecurity in the field that feels a need to inflate the importance of the concepts we work with.<p>&gt;  About every decade or so, we have to recycle all of the bad ideas of the previous generation.