Let’s see. We’ve got the newly released Protocol Buffers, courtesy of Google. I’m guessing to counter-weight Facebook’s Thrift? Guess who else has RPC? Hadoop, of Yahoo fame. And so does Cisco, with Etch.
What do all four have in common? A thirst for bandwidth and big networks for one. Also, a keen interest in social software networking. Yes, Cisco too.
Waiting for the MySpace shoe to drop.
I don’t know if the interest in social networking is indicative or just a coincidence, but if you like to explore the soft (as in human) side of software, I’d start there. It might tell us more about this renewed interest than any discussion over network fallacies and architecture styles.
Don’t shave this Yak
At least three of these companies are doing REST big time. We’re talking breadth, billions of pages served, and depth, both UIs, APIs and crawlers.
Still, convenience over correctness. (Apologies, Steve, I owe you beer)
I’m working on an interesting project right now. We want to make sure the front-end scales, and by scale I don’t mean page views, but the ability to lay different clients and usage patterns on top of it. It has to be human-facing too (doh), so REST is given. And REST does machine-machine very well, so there’s no reason to use anything but.
There’s also some back-end processing going on, and I think that part is using DRb for now. But maybe the next update it will switch over to RMI or UNIX pipes or whatever. I don’t much care because the library does the talking, and besides, it’s only distributed in the sense that we have two pieces of code running with different PIDs. Not particularly important what’s happening on the wire, as long as it’s fast.
Convenience.
And I’m going to bet this is not an edge case. And I’m not the first, if anything, I’m fashionably late to this party. If you’re working with Ruby, you’re probably already running REST in the front and RPC in the back and not giving it a second though. Other languages too.
Of course you can’t have an architecture, no matter how banal or obvious, without picking up a name for it. How else would you draw a diagram? So I’ll call this one Rullet. It should be obvious why.
No SOAP touching my Rullet!
As much as we’d hate to admit it — can’t we all just get along? — protocol stacks are a zero sum game. You’re spending all this energy building a fancy UI, and you look at the framework, and it winks at you: “hey, buddy, add a line here, I’ll throw in the API for free”. Sure.
We’re all lazy and you wouldn’t want to build the same stuff twice, and you get more out of REST anyway, so why SOAP? Frameworks that do REST well don’t leave room for SOAP in the front.
That part is convenience. The other part is convenience, too. Don’t care what happens in the back, as long as I don’t have to use tools that suck the life out of me. And given the options, SOAP is not necessarily the best preference.
I don’t consider two machines strapped together with an ethernet cable (or any N>1 extrapolation of that) as an interesting distributed problem requiring more thinking that whatever RPC happens easily to me.
Just let it grow
Here’s another thing that’s common to Protocol Buffers, Thrift and Etch.
REST is all about the protocol: many in theory, HTTP in practice. Besides, most people looking at REST are actually obsessing over the HTTP parts, not the hypermedia, so I’ll sin for a minute and lump them both together. SOAP is all about the protocol: it solved CORBA by thoughtfully mixing XML with HTTP.
Those all happened a decade ago. What else happened a decade ago? A lot of people obsessing over interoperability and fearing vendor dominance. So we got coopetition, and enough working groups to fill up the yellow pages.
From SOAP we learned two lessons. One, don’t pick an acronym that’s supposed to stand for something. The other, premature standardization is the root of all evil.
Check those press releases again. There’s no mention of fast tracking anything through the W3C, OASIS or IETF. Working groups might happen, but they’re not where the action is. If you want a dance partner for this party, bring some code.
Thirft does C++, C#, Erlang, Haskell, Java, Objective C, OCaml, Perl, PHP, Python, Ruby, and Squeakr. Phew. Etch does C# and Java, and promises Ruby, Python and C. Protocol Buffer does all the three Google languages, but I wouldn’t worry about the small set size. Give it a week. I bet twenty projects started to fill the gap before I’m done writing this post.
And don’t forget JSON(-RPC) which is ramping up language support, even without big vendor help.
If your language is easily supported, the runtime fits on a floppy disk, and it costs $0 in licensing and support contracts, do you care what the protocol looks like?
I don’t.
Interesting thing is happening in the post-SOAP world. RPC is no longer a protocol. RPC is the absence of one.
Which is not entirely a bad thing when all you care for is convenience. REST in the front, RPC in the back. It might be ugly, but if it just works …
Patrick Mueller
Assaf