What's Really Hard?

by coatta 5/30/2010 7:18:00 PM

In a CTO roundtable hosted by ACM Queue (http://queue.acm.org/detail.cfm?id=1551646) Lew Tucker said:

 "An important shift has been to use basic HTTP, in the form of REST (representational state transfer) APIs, as an easier-to-use SOA framework. Everything that made services hard before, such as CORBA, IDL, etc., went away when we said, “Let’s do it all over HTTP."

What is really hard about "services" is not the infrastructure that you use to build them. Building distributed systems invovles challenges that are not faced when building monolithic applications:

  • accounting explicitly for the effects of latency 
  • variations in latency and bandwidth that affect performance
  • network partitions that makes some, but not all parts of the system, unavailable
  • race conditions and attendant issues in consistency, like those which occur in mutlithreaded programming

Any single one of these is substantially more challenging to deal with than the infrastructure that one chooses to build a system on top of. CORBA has its weaknesses, but anyone who had difficulty understanding IDL really shouldn't be building distributed systems anyways.

RESTful Lies (Part 2)

by coatta 1/24/2010 10:35:00 AM

I've been continuing to make my way through a book on REST, and come across the following, in which the author is arguing that one of the advantages of REST is that it reduces the burden of API design:

"... the advantage of the uniform interface of REST ... is that it frees us from having to create a new interface every time a new service is created."

I think that the author is conflating the design of different levels of the system. This is perhaps not surprising because he points out elsewhere that while SOAP is designed to run over a variety of different trnasport protocols, REST is intimately associated with HTTP. In spite of this, I think it is still reasonable to assert that HTTP is the transport protocol for REST. Furthermore, there is absolutely no doubt in my mind that the design of the transport protocol is not the same thing as the design of the application protocol. The fact that a REST-based system will use HTTP GET. PUT, DELETE, and POST in well-defined ways does not eliminate the significant task of designing the application level protocol.

To be specific, in a REST-based system, you still need to determine the entities which will make up the system. You still need to determine the right set of attributes for each and the relationships between them. You still need to determine what processes will effect these entities and how they will be changed. This is what the design of the application protocol is concerned with and all of this is a much more challenging design task than sorting out that the DELETE request should delete something.

In my last posting, I noted that we software developers often suffer from the desire to believe that whatever new approach we have adopted is the finally the right one. We need to stop this. Grandiose claims of how much better approach A is over approach B cloud the reality of the situation which makes actual forward progress more challenging. There is no silver bullet. Get used to it.


Calendar

<<  November 2017  >>
MoTuWeThFrSaSu
303112345
6789101112
13141516171819
20212223242526
27282930123
45678910

View posts in large calendar

Disclaimer

My opinions are my own, but you can borrow them if you like.

© Copyright 2017

Sign in