“An entire group of people who had just been told how to profile, when faced with a problem and a deadline, abandoned all reason and just started hacking at the code.” There is more to development than code.
Steve has a very tight definition for RPC as per Note On Distributed Computing and RFC 707. Unfortunately most real-world RPC mechanisms do not fit with this definition. Yet he still critiques them as if they did fit.
This entry was posted on Wednesday, July 23rd, 2008 at 2:31 am and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.
Dan, even if most real-world RPC mechanisms do not strictly fit that definition, they still fit the original primary motivations for RPC, which were easiness, simplicity, and the familiarity of the procedure call model. Despite its convenience, the procedure call model remans an unsuitable abstraction for distributed computing because no matter how you go about it, the approach ultimately attempts to fold distributed operations under the guise of local ones, thereby hiding important network-scale issues like caching, intermediation, partial failure, idempotency, etc. Given the fact that there are better programming languages available for distribution than the tired old general-purpose ones, and given there are better network programming abstractions available than RPC that don’t try to hide the important stuff, there’s simply no excuse anymore for professional developers to favor the convenience of RPC over correctness.
Thanks for the clarity: I think I now understand where you’re coming from. However I (and others it seems) have managed to construct systems built atop RPC-a-like mechanisms that do account for all of these issues (caching, intermediation, partial failure, idempotency) thus I would be interested to hear more on how you view correctness in this refined context.
[ Implementation note: building these systems has required a substantial revision of the stub concept with support for dynamic discovery of endpoints at runtime etc ]
I think there may be some interesting convenience arguments from the opposite perspective: maybe using something other than RPC is quicker to implement for example. What do you think?
Hi Dan, as you might imagine, working on CORBA and its successors for over 15 years means that I’ve implemented just about everything imaginable within the RPC space. It’s why I feel very qualified to tackle this topic. 🙂
Yes, caching, intermediation etc. can be handled in such systems, but in my experience it’s not at all straightforward or extensible, primarily because of the interface and method specialization that RPC approaches encourage. You end up working extra hard to work around the abstractions RPC imposes in the first place, which is generally a good indicator that the abstractions are wrong for what you’re attempting to do.
As for other things being quicker to implement, it depends, and it’s why I said that choice of language is important. Let’s face it, people reach for RPC in languages like Java and C++ because it’s common, handy and easy, at least if they’re ignoring some of the fundamental problems with the abstraction. But if they try to tackle those shortcomings, then the RPC framework gets more complicated and harder to use, and some of that convenience is lost. But for other languages, like my current favorite, Erlang, I would never reach for RPC because it’s simply not needed given what the language already gives me. I get convenience without having to give up correctness.
“primarily because of the interface and method specialization that RPC approaches encourage.”
Mmmm, so I think you’re meeting maybe an impedance mismatch of your own here 🙂 I’m strongly suspecting that those of us who “succeed” with RPC-a-like things don’t fall into this trap.
Another interesting aspect for me is that I don’t really have an RPC framework – more a toolbox of composable bits. I think also that at least some of the things I do don’t actually belong in the RPC framework, thus I put them in the “application-level”.
On the choice of Erlang or any other language, I appreciate you like the way the abstractions are packaged up, it is elegant (I wouldn’t argue otherwise) but of course one trades this for shortcomings or less elegance elsewhere. Right tool for right job I guess.
All in all, I think we’re beholden to describe how to build distributed systems in terms of patterns, do’s and don’ts, guidelines etc. Then we have to leave people to choose the right tools for the job with these things in mind. And the big deal in this is that such a book has never been written, there’s plenty of papers around, lots of advice and several good references on the theory but nothing that would qualify as a practitioners reference book.
Dan Creswell's Linkblog 
Dan, even if most real-world RPC mechanisms do not strictly fit that definition, they still fit the original primary motivations for RPC, which were easiness, simplicity, and the familiarity of the procedure call model. Despite its convenience, the procedure call model remans an unsuitable abstraction for distributed computing because no matter how you go about it, the approach ultimately attempts to fold distributed operations under the guise of local ones, thereby hiding important network-scale issues like caching, intermediation, partial failure, idempotency, etc. Given the fact that there are better programming languages available for distribution than the tired old general-purpose ones, and given there are better network programming abstractions available than RPC that don’t try to hide the important stuff, there’s simply no excuse anymore for professional developers to favor the convenience of RPC over correctness.
HI Steve,
Thanks for the clarity: I think I now understand where you’re coming from. However I (and others it seems) have managed to construct systems built atop RPC-a-like mechanisms that do account for all of these issues (caching, intermediation, partial failure, idempotency) thus I would be interested to hear more on how you view correctness in this refined context.
[ Implementation note: building these systems has required a substantial revision of the stub concept with support for dynamic discovery of endpoints at runtime etc ]
I think there may be some interesting convenience arguments from the opposite perspective: maybe using something other than RPC is quicker to implement for example. What do you think?
Hi Dan, as you might imagine, working on CORBA and its successors for over 15 years means that I’ve implemented just about everything imaginable within the RPC space. It’s why I feel very qualified to tackle this topic. 🙂
Yes, caching, intermediation etc. can be handled in such systems, but in my experience it’s not at all straightforward or extensible, primarily because of the interface and method specialization that RPC approaches encourage. You end up working extra hard to work around the abstractions RPC imposes in the first place, which is generally a good indicator that the abstractions are wrong for what you’re attempting to do.
As for other things being quicker to implement, it depends, and it’s why I said that choice of language is important. Let’s face it, people reach for RPC in languages like Java and C++ because it’s common, handy and easy, at least if they’re ignoring some of the fundamental problems with the abstraction. But if they try to tackle those shortcomings, then the RPC framework gets more complicated and harder to use, and some of that convenience is lost. But for other languages, like my current favorite, Erlang, I would never reach for RPC because it’s simply not needed given what the language already gives me. I get convenience without having to give up correctness.
HI Steve,
“primarily because of the interface and method specialization that RPC approaches encourage.”
Mmmm, so I think you’re meeting maybe an impedance mismatch of your own here 🙂 I’m strongly suspecting that those of us who “succeed” with RPC-a-like things don’t fall into this trap.
Another interesting aspect for me is that I don’t really have an RPC framework – more a toolbox of composable bits. I think also that at least some of the things I do don’t actually belong in the RPC framework, thus I put them in the “application-level”.
On the choice of Erlang or any other language, I appreciate you like the way the abstractions are packaged up, it is elegant (I wouldn’t argue otherwise) but of course one trades this for shortcomings or less elegance elsewhere. Right tool for right job I guess.
All in all, I think we’re beholden to describe how to build distributed systems in terms of patterns, do’s and don’ts, guidelines etc. Then we have to leave people to choose the right tools for the job with these things in mind. And the big deal in this is that such a book has never been written, there’s plenty of papers around, lots of advice and several good references on the theory but nothing that would qualify as a practitioners reference book.
Agreed. So when are you going to write it? 🙂