Tuesday, July 26, 2005

The Right Way to Build Distributed Systems: API or Messages? How should you build distributed sytems: API or messages? This post by Eric Armstrong says messages -- http://www.artima.com/forums/flat.jsp?forum=106&;thread=120669 -- and I couldn't agree more. APIs create a tight a binding between the protocol functionality and your code. If they use a certain libary then so do you. If their API conflicts with your code then you are out of luck. If their API corrupts the heap then you are out of luck. If their API can't handle interrupts, semaphores, queuing, memory contraints, priority, or a host of other issues properly then you are out of luck. Your code can't evolve independently from the API which makes your system less functional, more dependent, and more brittle than when a protocol is used. That's too high a price to pay when your butt is on the line to get something working and to keep it working. Another key advantage of using a protocol is that it can be implemented in any language. You don't have to wait for a vendor to create a language binding for your language version and operating version. This can take forever. If you are on an unconventional OS like VxWorks, you'll probably never see an API. You don't have to wait for bug fixes either. And you don't have to worry about how to include their code in your build system. When using a a protocol as long you can stuff rightly formatted bits down the TCP, UDP or whatever socket then you are in. For example, I was able to quickly make a sweet load test system in Perl for a set-top box network because a protocol was used and it was easy to compose bits together in Perl. If I had to wait for a Perl binding to the API I would still be waiting and the load testing system may never have been attempted. Look how quickly HTTP took off. HTTP is a relatively simple protocol spec normal people can implement in their favorite language. HTTP never had to change while HTTP implementations sprouted in many fertile language subculture. Sure, you get a wide variety of largely incompatible implementations, but that's a small price to pay for ubiquity. If you want to your protocol to take off you need to take advantage of viral marketing and network effects, which means you need a simple protocol that can be implemented. As a counter example take a look at FTP. It's a protocol, but how many implementations do you see? Not many. That's because it's complex. If you really want your protocol to take off then provide an API too. Aren't I contradicting myself? Not at all. Make adoption as easy as possible. Write the simplest protocol you can. This is not easy, so do a good job. Then write a simple API that supports both sync and async modes. Hit the major languages and operating systems of your primary customers. This strategy allows people who want to make the extra effort of writing protocol code to create the perfect interface for their system. For the people who just want to get something working then they can use the API. Don't tie them together. Release and develop them separately. Let them evolve separately and you can have the best of all worlds. comment[] 3:26:30 PM

© Copyright 2006 todd hoff. Last update: 7/11/2006; 12:44:33 PM.