From what Steve says it certainly sounds like this year's QCon London was fun. This year Steve was talking on the history of RPC, which has some overlaps with what I was saying at QCon London last year. But Steve goes in to a lot more detail and I recommend people checking it out.
One slight caveat though: as I've said many times in the past (so many that I leave it as an exercise to the reader to find the entries in my blog) RPC isn't dead and isn't something you should ignore. (I don't think Steve thinks that either.) Look around you and you'll see examples of old and new systems based on it. Are they all wrong to do so? No, of course not. Are some of them wrong to do so? Most probably yes. I know of several small and large-scale systems that are being developed in academia (no vendor pressure there) and industry (maybe some pressure) that are being based on RPC. In all cases those guys did their homework and understand the trade-offs that they're making in using RPC.
BTW I'm not a RPC fanboy by any means. Yes, I've used them and helped develop them, but I've also used and developed other approaches too.
What I'm trying to say is that RPC has its place. But a bit like ACID transactions, it can be (and has been) easily misused. There are better approaches these days for many of the things we'd once have considered the domain of RPC. But that doesn't mean RPC can't and shouldn't be used. As with everything, such as which language to use, which database, which communication protocol etc., you need to be aware of the pros and cons. This is an education problem more than a technical problem.
I also agree with Steve around Erlang (in fact it was Steve who put me on to it a while back). A very nice language. Now if only I could find the time to get back to it.
2 comments:
The question for me is just how do we define RPC?
Certainly the original RPC implementations were not at all nice as they hid the cross-network nature of the interaction. Certain of the more modern implementations have addressed that issue and many permit (by accident or design) multiple versions of an interface and other good things.
For the most part, when I've seen these arguments around RPC being bad it's been more in the context of the original implementations. The criticisms are thus rendered correct but apply less well to some modern implementations.
Dan
http://www.dancres.org/
Actually many of the initial RPC implementations didn't hide the distributed aspect at all well. Sometimes that was deliberate. Sometimes it was accidental.
Post a Comment