6 ms·

I’m mostly lost on the discussion of RPC. This article delves into the historical and more abstract / academic ideas of RPC. By the time I started working in in

I’m mostly lost on the discussion of RPC. This article delves into the historical and more abstract / 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 / 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. I found these bits to be golden: > 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. > About every decade or so, we have to recycle all of the bad ideas of the previous generation.

phicoh 5y ago
It seems to me that in every group of people where a certain concept is often used, that concept will get a short name. You are not going to write out many times 'the chief engineer on a project'. So let's take a mostly unused term, like architect and stick with that. (Read 'The meaning Liff' where Douglas Adams is having fun with the reverse of this) Same thing with RPC, you need to have a term for sending a message to a remote process asking it to execute a particular 'function' and send back the result. At the same time, you don't want write a lot of code in each application to marshall arguments, send a message, wait for the reply, decode the result. So it seems obvious to generate those functions from a description file. And then you have something that looks a bit like a procedure call that is remote. Of course at some point the discussion derails and people start claiming that the RPC is basis of distributed computing. And then other people start writing critiques. That doesn't change the fact that a RPC is a nice concept, as long as you keep in mind what it really is, and what its limitations are.
- alephnan 5y ago
  > marshall arguments, send a message, wait for the reply, decode the result In the case of Protobuf, Google considers Protobuf as merely being focused on marshaling arguments then decoding results, and is otherwise decoupled from gRPC which is the layer and software to relay 1s and 0s.
  - dekhn 5y ago
    Note that protobufs actually have a "service" section to define RPC endpoints: https://developers.google.com/protocol-buffers/docs/proto#services https://developers.google.com/protocol-buffers/docs/proto#se...
- drewcoo 5y ago
  > in every group of people where a certain concept is often used, that concept will get a short name. His point is not name length, it's the inherent pompousness of the new names. We generally lack credentials. We puff up the terms for everything we do, making them seem important and official. What would Freud say?
  - Thiez 5y ago
    Is a term like 'architect' pompous? What short, existing word would you use to describe who decides how something is going to be built? Is abbreviating "remote procedure call" to RPC pompous? I think the words 'graph' and 'topology' are about equally as likely to make normal peoples eyes glaze over.
    - inkblotuniverse 5y ago
      Software Chief
jerf 5y ago
Normally an article would include a summary of the original paper. In this case it may be justified not to do that, but at least a link would have been helpful. So, first, here's this: https://www.win.tue.nl/~johanl/educ/2II45/2010/Lit/Tanenbaum%20RPC%2088.pdf https://www.win.tue.nl/~johanl/educ/2II45/2010/Lit/Tanenbaum... Second, to understand the critique I think it's helpful to understand what I would perceive as the chewing on that paper by the community over time, which can be summarized as this: The distinguishing characteristic of an "RPC call", in the sense that Tanenbaum meant, is an attempt to make a network transaction have the exact same semantics as a function call. Importantly, you should read this strictly; the idea isn't that it should be "functionish", or have some syntax sugar around a network transaction that looks a lot like a function in your language, but the idea is that it is providing an abstraction that is fully as reliable as a normal function call within that language, and can, in every way, be treated as a function call. It is a "procedure call" that just happens to be remote, but the abstraction is so complete that you can stop thinking about it entirely as a programmer. If you add that perspective to a reading of the PDF I linked, you'll probably understand the objections made more deeply. You now live in a world where Tanenbaum "won", because he is objectively correct that such a thing is simply not possible, so it is much harder to understand what he's banging on about here in 2022. The network "RPC" calls you're used to have backed down the promises they made, and in most languages aren't as simple as a function call. Many modern things that call themselves "RPC" instead focus on having a function-like flow in the happy case, but don't promise to magically make problems with local vs. remote references go away, and instead of jumping through hoops to try to solve the problems just have you deal with them. I caught the tail end of the RPC world at the beginning of my programmer career. It was a horrible place. You'd have these horrifyingly complex manifests of what the remote RPC call could do, and then they might get compiled into your code like "functions", and then problems as simple as "the remote function call was lost and you never got a reply" would just be a function you called that hung your program forever. Dealing with this was awful and hacky and ugly, because the function abstration they were trying to jam themselves so hard into simply didn't have a place for handling "the function you're trying to call is missing", so you might have to declare "handlers" elsewhere that ran in entirely different contexts or who knows what garbage. Total mess. In the process of trying to make things easier than they could possibly be, they made handling errors incredibly difficult. The sloppiest modern "I vaguely take some JSON and return some other JSON" HTTP API is much preferable to this mess. One of the interesting lessons of software engineering is that just because something is impossible in general doesn't mean you can't still try, and get something that sorta sometimes works some of the time if all the stars align, and then get people selling that as the next hot thing that is the most important thing in programming ever. Despite what you may cynically think, I actually don't have any current tech in mind as I type that. It may just be a lack of perspective as I'm as embedded in the present as anyone else, but I don't feel like there's a lot of extant techs right now in the general programming space promising the impossible. Closest I can think of is the machine learning space, but my perception is that it isn't so much that machine learning is promising the impossible as that there are a lot of people who expect it to do the impossible, which isn't quite what I mean. I mean more like people selling database technology that, in order to exist, must completely break the CAP theorem (and I don't just mean shading around the edges and playing math games, but breaking it), or RPCs that fundamentally only work if all 8 fallacies of distributed computing [1] were in fact true, or techs that don't work unless time can be absolutely and completely synchronized between all nodes, and so on. I'm sure there's little bits of those here and there, but there was a time when this sort of impossible RPC was thought of as the future of programming. The software engineering space has become too diverse for things that are essentially fads to take over the whole of it like things could in the 1980s and 1990s. (See also OO, which also has a similar story where if you learn OO in 2022, you're learning a genteel and tamed OO that has been forced to tone down its promises and adapt to the real world. The OO dogma of the 1980s and 1990s was bad and essentially impossible, and only a faint trace of it remains. Unfortunately, that "faint trace" is still in a few college programs, so it has an outsized effect, but for the most part the real world seems to break new grads of it fairly quickly nowadays.) Finally, this should be contrasted with the modern answer that is continuing to grow, which is message passing systems. A message passage system loosens the restrictions and offers fewer guarantees, and as such, can do more. You can always layer an RPC system for your convenience on top of a message passing system, but you can't use an RPC system to implement a message passing system with the correct semantics, because the RPC system implements too much. I personally view "RPC", in the looser modern form, as a convenient particular design pattern for message passing, but not as the fundamental abstraction lens you should view your system through. Even the modern genteel form of RPC imposes too many things, because sometimes you need a stream, sometimes you need an RPC, sometimes you just need a best-effort flinging of data, etc. When you have a place you need RPC's guarantees, by all means use an established library for it if you can, but when you need something it can't do, drop it immediately and use the lower-level message bus you should have access to. [1]: https://www.simpleorientedarchitecture.com/8-fallacies-of-distributed-systems/ https://www.simpleorientedarchitecture.com/8-fallacies-of-di...
tenebrisalietum 5y ago
RPC is literally calling a remote function over the network without the infrastructure of HTTP - you implement it in your code not too different from a normal function call (you do have to use an Interface Description Language to mark some parameters as "in" and "out"). It's a substandard way to implement distributed computing, because: - it assumes you and the remote end are in lockstep which is hard to guarantee at scale; - if you and your remote end are not in lockstep you get weird hangs in your program because you are pretending code is on your machine when it's not; - an infrastructure must exist to make sure you are calling the remote code you intend, including things like component registration, etc. and for the amount of work required to make that work well, you might as well write a TCP/IP server. With TLS and other authentication mechanisms, current CPU speeds and JSON and HTTP becoming de facto messaging formats you might as well use all of that for remote API access instead of literally trying to send what's pretty much raw function calls over a wire.
- gpderetta 5y ago
  It seems that your first two points are an argument against synchronous RPC. These days asynchronous functions are frequently used in-process, so RPC calls that use the same async abstractions seem appropriate. I guess the historical background is that the RPC syntactic sugar implied sync calls. Regarding your last point, there is no reason why a language level RPC implementation cannot map to TLS/HTTP/JSON as the transport layer and encoding. The real issue with RPC is that only a small subset of all the types supported in a language can be sanely supported, and it just ends up being syntactic sugar for message passing plus matching of replies to requests. There is nothing wrong with this, but it is indeed a leaky abstraction.
  - sebastos 5y ago
    Yes - I see other posters trying to spin the article to make it only an argument against "old" RPC solutions (CORBA I guess?). This seems to be an attempt to leave an escape hatch for their pet RPC solutions that happen to be more modern. When I first joined my workplace, some of the resident engineers were overly disposed to cargo culting google practices. I had a robotics application that just screamed for using something like ROS, but I was encouraged to use gRPC to underpin these microservices. I was inexperienced enough to assume they knew something I didn't, but I kept scratching my head trying to figure out why this was supposed to be better than a simple pub-sub system. It felt like a huge impedance mismatch with what was actually happening at the message level. When I asked myself whether I could use gRPC in a simpler, pub-sub-like mode, I instead found a bunch of janky projects where people were trying to build pub-sub on TOP of gRPC (?!) It wasn't until later when some of the cargo-culters left and new folks with a robotics background joined the company that I realized I had been right all along. Reading this article was cathartic because it expressed a truth I didn't know I was allowed to think - I don't _want_ a procedure-like interface! It is simultaneously simpler and more correct to think in terms of message-oriented IPC. RPC seems to be about letting people think in a lazy away about how their distributed application works... but you inevitably end up saddling them with a long tail of things that were brushed under the rug.
jacquesm 5y ago
> Nowadays, we just call the RPC topology as microservices, which is usually an HTTP API, just not on the public internet. That's not necessarily true, though there are plenty of places that do it that way. But there are a whole slew of pub/sub mechanisms and various transports (message buses, for instance) used in the implementation as alternatives to HTTP(S).
moomin 5y ago
The problem with that last bit is it’s just a prescriptivist rant. You can complain as loud as you like that people are using language wrong, if enough people use it like that the dictionary gets updated.

phicoh 5y ago

It seems to me that in every group of people where a certain concept is often used, that concept will get a short name. You are not going to write out many times 'the chief engineer on a project'. So let's take a mostly unused term, like architect and stick with that. (Read 'The meaning Liff' where Douglas Adams is having fun with the reverse of this) Same thing with RPC, you need to have a term for sending a message to a remote process asking it to execute a particular 'function' and send back the result. At the same time, you don't want write a lot of code in each application to marshall arguments, send a message, wait for the reply, decode the result. So it seems obvious to generate those functions from a description file. And then you have something that looks a bit like a procedure call that is remote. Of course at some point the discussion derails and people start claiming that the RPC is basis of distributed computing. And then other people start writing critiques. That doesn't change the fact that a RPC is a nice concept, as long as you keep in mind what it really is, and what its limitations are.

alephnan 5y ago
> marshall arguments, send a message, wait for the reply, decode the result In the case of Protobuf, Google considers Protobuf as merely being focused on marshaling arguments then decoding results, and is otherwise decoupled from gRPC which is the layer and software to relay 1s and 0s.
- dekhn 5y ago
  Note that protobufs actually have a "service" section to define RPC endpoints: https://developers.google.com/protocol-buffers/docs/proto#services https://developers.google.com/protocol-buffers/docs/proto#se...
drewcoo 5y ago
> in every group of people where a certain concept is often used, that concept will get a short name. His point is not name length, it's the inherent pompousness of the new names. We generally lack credentials. We puff up the terms for everything we do, making them seem important and official. What would Freud say?
- Thiez 5y ago
  Is a term like 'architect' pompous? What short, existing word would you use to describe who decides how something is going to be built? Is abbreviating "remote procedure call" to RPC pompous? I think the words 'graph' and 'topology' are about equally as likely to make normal peoples eyes glaze over.
  - inkblotuniverse 5y ago
    Software Chief

jerf 5y ago

Normally an article would include a summary of the original paper. In this case it may be justified not to do that, but at least a link would have been helpful. So, first, here's this: https://www.win.tue.nl/~johanl/educ/2II45/2010/Lit/Tanenbaum%20RPC%2088.pdf https://www.win.tue.nl/~johanl/educ/2II45/2010/Lit/Tanenbaum... Second, to understand the critique I think it's helpful to understand what I would perceive as the chewing on that paper by the community over time, which can be summarized as this: The distinguishing characteristic of an "RPC call", in the sense that Tanenbaum meant, is an attempt to make a network transaction have the exact same semantics as a function call. Importantly, you should read this strictly; the idea isn't that it should be "functionish", or have some syntax sugar around a network transaction that looks a lot like a function in your language, but the idea is that it is providing an abstraction that is fully as reliable as a normal function call within that language, and can, in every way, be treated as a function call. It is a "procedure call" that just happens to be remote, but the abstraction is so complete that you can stop thinking about it entirely as a programmer. If you add that perspective to a reading of the PDF I linked, you'll probably understand the objections made more deeply. You now live in a world where Tanenbaum "won", because he is objectively correct that such a thing is simply not possible, so it is much harder to understand what he's banging on about here in 2022. The network "RPC" calls you're used to have backed down the promises they made, and in most languages aren't as simple as a function call. Many modern things that call themselves "RPC" instead focus on having a function-like flow in the happy case, but don't promise to magically make problems with local vs. remote references go away, and instead of jumping through hoops to try to solve the problems just have you deal with them. I caught the tail end of the RPC world at the beginning of my programmer career. It was a horrible place. You'd have these horrifyingly complex manifests of what the remote RPC call could do, and then they might get compiled into your code like "functions", and then problems as simple as "the remote function call was lost and you never got a reply" would just be a function you called that hung your program forever. Dealing with this was awful and hacky and ugly, because the function abstration they were trying to jam themselves so hard into simply didn't have a place for handling "the function you're trying to call is missing", so you might have to declare "handlers" elsewhere that ran in entirely different contexts or who knows what garbage. Total mess. In the process of trying to make things easier than they could possibly be, they made handling errors incredibly difficult. The sloppiest modern "I vaguely take some JSON and return some other JSON" HTTP API is much preferable to this mess. One of the interesting lessons of software engineering is that just because something is impossible in general doesn't mean you can't still try, and get something that sorta sometimes works some of the time if all the stars align, and then get people selling that as the next hot thing that is the most important thing in programming ever. Despite what you may cynically think, I actually don't have any current tech in mind as I type that. It may just be a lack of perspective as I'm as embedded in the present as anyone else, but I don't feel like there's a lot of extant techs right now in the general programming space promising the impossible. Closest I can think of is the machine learning space, but my perception is that it isn't so much that machine learning is promising the impossible as that there are a lot of people who expect it to do the impossible, which isn't quite what I mean. I mean more like people selling database technology that, in order to exist, must completely break the CAP theorem (and I don't just mean shading around the edges and playing math games, but breaking it), or RPCs that fundamentally only work if all 8 fallacies of distributed computing [1] were in fact true, or techs that don't work unless time can be absolutely and completely synchronized between all nodes, and so on. I'm sure there's little bits of those here and there, but there was a time when this sort of impossible RPC was thought of as the future of programming. The software engineering space has become too diverse for things that are essentially fads to take over the whole of it like things could in the 1980s and 1990s. (See also OO, which also has a similar story where if you learn OO in 2022, you're learning a genteel and tamed OO that has been forced to tone down its promises and adapt to the real world. The OO dogma of the 1980s and 1990s was bad and essentially impossible, and only a faint trace of it remains. Unfortunately, that "faint trace" is still in a few college programs, so it has an outsized effect, but for the most part the real world seems to break new grads of it fairly quickly nowadays.) Finally, this should be contrasted with the modern answer that is continuing to grow, which is message passing systems. A message passage system loosens the restrictions and offers fewer guarantees, and as such, can do more. You can always layer an RPC system for your convenience on top of a message passing system, but you can't use an RPC system to implement a message passing system with the correct semantics, because the RPC system implements too much. I personally view "RPC", in the looser modern form, as a convenient particular design pattern for message passing, but not as the fundamental abstraction lens you should view your system through. Even the modern genteel form of RPC imposes too many things, because sometimes you need a stream, sometimes you need an RPC, sometimes you just need a best-effort flinging of data, etc. When you have a place you need RPC's guarantees, by all means use an established library for it if you can, but when you need something it can't do, drop it immediately and use the lower-level message bus you should have access to. [1]: https://www.simpleorientedarchitecture.com/8-fallacies-of-distributed-systems/ https://www.simpleorientedarchitecture.com/8-fallacies-of-di...

tenebrisalietum 5y ago

RPC is literally calling a remote function over the network without the infrastructure of HTTP - you implement it in your code not too different from a normal function call (you do have to use an Interface Description Language to mark some parameters as "in" and "out"). It's a substandard way to implement distributed computing, because: - it assumes you and the remote end are in lockstep which is hard to guarantee at scale; - if you and your remote end are not in lockstep you get weird hangs in your program because you are pretending code is on your machine when it's not; - an infrastructure must exist to make sure you are calling the remote code you intend, including things like component registration, etc. and for the amount of work required to make that work well, you might as well write a TCP/IP server. With TLS and other authentication mechanisms, current CPU speeds and JSON and HTTP becoming de facto messaging formats you might as well use all of that for remote API access instead of literally trying to send what's pretty much raw function calls over a wire.

gpderetta 5y ago
It seems that your first two points are an argument against synchronous RPC. These days asynchronous functions are frequently used in-process, so RPC calls that use the same async abstractions seem appropriate. I guess the historical background is that the RPC syntactic sugar implied sync calls. Regarding your last point, there is no reason why a language level RPC implementation cannot map to TLS/HTTP/JSON as the transport layer and encoding. The real issue with RPC is that only a small subset of all the types supported in a language can be sanely supported, and it just ends up being syntactic sugar for message passing plus matching of replies to requests. There is nothing wrong with this, but it is indeed a leaky abstraction.
- sebastos 5y ago
  Yes - I see other posters trying to spin the article to make it only an argument against "old" RPC solutions (CORBA I guess?). This seems to be an attempt to leave an escape hatch for their pet RPC solutions that happen to be more modern. When I first joined my workplace, some of the resident engineers were overly disposed to cargo culting google practices. I had a robotics application that just screamed for using something like ROS, but I was encouraged to use gRPC to underpin these microservices. I was inexperienced enough to assume they knew something I didn't, but I kept scratching my head trying to figure out why this was supposed to be better than a simple pub-sub system. It felt like a huge impedance mismatch with what was actually happening at the message level. When I asked myself whether I could use gRPC in a simpler, pub-sub-like mode, I instead found a bunch of janky projects where people were trying to build pub-sub on TOP of gRPC (?!) It wasn't until later when some of the cargo-culters left and new folks with a robotics background joined the company that I realized I had been right all along. Reading this article was cathartic because it expressed a truth I didn't know I was allowed to think - I don't _want_ a procedure-like interface! It is simultaneously simpler and more correct to think in terms of message-oriented IPC. RPC seems to be about letting people think in a lazy away about how their distributed application works... but you inevitably end up saddling them with a long tail of things that were brushed under the rug.

jacquesm 5y ago

> Nowadays, we just call the RPC topology as microservices, which is usually an HTTP API, just not on the public internet. That's not necessarily true, though there are plenty of places that do it that way. But there are a whole slew of pub/sub mechanisms and various transports (message buses, for instance) used in the implementation as alternatives to HTTP(S).

moomin 5y ago

The problem with that last bit is it’s just a prescriptivist rant. You can complain as loud as you like that people are using language wrong, if enough people use it like that the dictionary gets updated.