Discussions

News: Why is Distributed so Hard?

  1. Why is Distributed so Hard? (5 messages)

    Dale Asberry talks about some reasons why he feels distributed systems are so hard to work with.

    Introduction
    In one sentence, here's why: humans are notoriously bad at keeping "self" distinct from "other". Egomania, projection (transference), and enmeshment are well-known symptoms of this problem. OK, so I hear you saying, "yeah, but what does this have to do with programming?" It certainly seems absurd to suggest that if we are bad at something we know the most about (our "selves"), how could we possibly say that we have a good approach for the programming analogues - objects, modules, etc.
    Conclusion
    Hopefully it isn't too difficult to see that people are bad at recognizing differences between self and others. It should also not be too hard to see that these difficulties would spill over into programming.

    We should also recognize that other factors aggravate the problem and further discourage decoupling. One, it's a hard problem to see, let alone, to solve. Two, if developers don't keep on top of, and continually remove, dependencies, the harder it gets to remove them. Third, these problems are exacerbated by the fact that the original team (and especially consultants) leave the project taking hard-learned domain expertise with them sometimes to avoid the negative consequences of blame.

    Distributed applications are particularly hard-hit by these things. Distributed applications are inherently more difficult than "standard" applications because they simply cannot be built without making them very decoupled. (See Carlos' coupling table above).

    On the positive side, many very bright people have seen solutions to overcoming these dependency problems. The solutions are subtle and complex which means that they can't be applied in cookie-cutter fashion. If developers assimilate these solutions into their personal knowledge base then all types of applications can be taken to the next level of complexity.
    Read Why is Distributed so Hard?

    Threaded Messages (5)

  2. Why is Distributed so Hard?[ Go to top ]

    I disagree with the concept of "self" and "other" being
    the source of strife with regard to Distributed Computing.

    I also don't go for the anthropomorphic (egomania, transference)
    mumbo, jumbo.

    It is more (in my mind) a concept of "here" and "there".

    When designing and implementing distributed applications,
    architects and developers need to understand the concepts
    and the fundemental differences between a logical application
    and a physical deployment.

    Whilst designing a distributed application from the logical
    sense, everthing happens in one place, i.e. a single address
    space. However, when it come to deployment, the single logical
    application should be able to be "split" with its various parts
    physically residing in multiple address spaces.

    It is still a single logical application, but physical distributed.

    J2EE helps in a large part to make this location transparency
    possible and distributed computing (in the Java sense) practical.

    Design as if everything happens "here". Implement with a mind
    to it actually happening "here" and (possibly) "there".

    With that said, it has been my experience that some (not all)
    organisations I have come across actually do not do distributed
    computing.

    Case 1. An application is completely self-contained in a single EAR
    file deployed on a single server. Single address space. May be on a remote
    server, but it does not qualify as distributed computing.

    Case 2. An application is completely self-contained in a single EAR
    file and deployed to every node in a cluster. Still single address
    space (on a single node) and thus does qualify as distributed. Just
    like Case 2, just n times, but more available.

    Case 3. A (single logical) application composed of two or more
    EAR files is depolyed on different nodes. This is distributed computing.
    It is here that issues such as serialisation become very important. That
    "bread crumbs" you persisted locally in component X which is needed
    by component Y may not be found because it is not running "locally"...

    It not a matter of "self" and "other", but "here" not being where
    you put it, or expected it, because "here" is now "there".

    Just my thoughts.
  3. Why is Distributed so Hard?[ Go to top ]

    Ahhhh!

    In my own post I noticed that I dropped
    an important word. The word "not".

    The phrase in Case 2 "...and thus does qualify..."
    should have read "...and thus does not qualify...".

    Too quick on the "send" button.
  4. Because ...[ Go to top ]

    Jim Waldo, et al answered this question in 1994:

    http://research.sun.com/techrep/1994/smli_tr-94-29.pdf

    Read and learn.

    ... WkH
  5. Why is Distributed so Hard?[ Go to top ]

    I'd strongly recommend people take a look at Erlang's model for developing concurrent and distributed applications. No thread, no shared state, only message passing, concurrent activities are modeled with lightweight processes. Each process is easier to write, reason and maintain.

    http://c2.com/cgi/wiki?ErlangLanguage.
  6. The end of metaphysics[ Go to top ]

    I don't really think the philosophical concepts of 'self' and 'other' apply to distributed computing. I can see why you'd want to use them but it doesn't make sense.

    One of the typical arguments regarding personal identity theory, existentialism, etc., etc., is the fact the we can't really divulge the purposes within another's mind. Levinas is fairly much a great thinker in this regard.

    Using an API, which charts the behaviour of an interface, in a business orientated machine is far different. It states purpose.

    Nick