Fallacies of Distributed Computing Explained Notes in this article.

8 Fallacies of Distributed computing

  1. The network is reliable.
  2. Latency is zero.
  3. Bandwidth is infinite.
  4. The network is secure.
  5. Topology doesn’t change.
  6. There is one administrator.
  7. Transport cost is zero.
  8. The network is homogeneous.

Let’s start with the first one

1. The network is reliable

The network is not reliable, so we need to consider when designing software

  • retry
  • acknowledge important messages
  • Identify /ignore Duplicates or idempotent
  • Reorder Messages
  • Verify message integrity

2. Latency is zero

Delay is an index of how long it takes for data to travel from one place to another

Bandwidth determines how much data can be transmitted at the same time

Latency is how much time it takes for data to move from one place to another

bandwidth which is how much data we can transfer during that time

Latency is harder to solve than bandwidth. Latency is determined by the speed at which information travels, and the speed of light is constant, meaning the low bound of latency is fixed

“B ut I think that it’s really interesting to see that the end-to-end bandwidth increased by 1468 times within the last 11 years while the latency (the time a single ping takes) has only been improved tenfold. If this w wouldn’t be enough, there is even a natural cap on latency. The minimum round-trip time between two points of this earth is determined by the maximum speed of information transmission: The speed of light. At Roughly 300,000 kilometers per second (3.6 * 10E12 teraangstrom per fortnight), it will always take at least 30 milliseconds to send a ping from Europe to the US and back, even if the processing would be done in real time.”

Since latency is inevitable, we can only minimize message transfers as much as possible.

Taking latency into consideration means you should strive to make as few as possible calls and assuming you have enough bandwidth (which will talk about next time) you’d want to move as much data out in each of this calls.

3. Bandwidth is infinite

There are two main reasons for the infinite bandwidth fallacy:

  • As bandwidth grows, so does the amount of data we transmit;
  • Packet loss problem

One is that while the bandwidth grows, so does the amount of information we try to squeeze through it. VoIP, videos, and IPTV are some of the newer applications that take up bandwidth

The other force at work to lower bandwidth is packet loss (along with frame size).

The fact that bandwidth is not unlimited allows us to reduce the transmission of information, but the delay is unavoidable, and the best we can do is to send as much data as possible.

4. The Network is Secure

You don’t have to be a security expert to be an architect, but you do need to understand it and know how to solve it.

Security is usually a multi-layered solution that is handled on the network, infrastructure, and application levels.

5. The Topology doesn ‘t change

Maybe the fallacy comes from the fact that Topology does not change only in an experimental environment.

“Topology doesn’t change.” That’s right, it doesn’t –as long as it stays in the test lab.

Implications for us:

  • Do not rely on specific routes or nodes
  • You need to provide both location transparency and discovery services

Try not to depend on specific endpoints or routes, if you can’t be prepared to renegotiate endpoints.

You would want to either provide location transparency (e.g. using an ESB, multicast) or provide discovery services (e.g. a Active Directory/JNDI/LDAP).

6. There is one administrator

When there are no problems, we don’t care if there are multiple administrators, but when there are problems, you go crazy.

“Okay, there is more than one administrator. But why should I care?” Well, as long as everything works, maybe you don’t care. You do care, however, when things go astray and there is a need to pinpoint a problem (and solve it).

To prevent administrators problems, we need to note:

  • Tools are provided to monitor system operations when the system is small

A proactive approach is to also include tools for monitoring on-going operations as well;

To sum up, when we deal with multiple Administrators, we are bound to receive constraints from administrators, and what we can do is help them manage their applications.

To sum up, when there is more than one administrator (unless we are talking about a simple system and even that can evolve later if it is successful), you need to remember that administrators can constrain your options (administrators that sets disk quotas, limited privileges, limited ports and protocols and so on), and that you need to help them manage your applications.

7. Transport cost is zero

We can explain the fallacy of the above conclusion in a number of ways

One of the things we do is we pass data from the application layer to the transport layer, and we need to encode the data, which consumes time and resources

One way is that going from the application level to the transport level is free. This is a fallacy since we have to do marshaling (serialize information into bits) to get data unto the wire, which takes both computer resources and adds to the latency

The second way is to set up and run the network need to cost, we need a lot of money to buy buy!

The second way to interpret the statement is that the costs (as in cash money) for setting and running the network are free. This is also far from being true. There are costs–costs for buying the routers, costs for securing the network, costs for leasing the bandwidth for internet connections, and costs for operating and maintaining the network running. Someone, somewhere will have to pick the tab and pay these costs.

8. The network is homogeneous

The last fallacy is that networks are isomorphic. We need to be careful not to rely on some proprietary protocols, which will lead to big problems in the later integration.

It is worthwhile to pay attention to the fact the network is not homogeneous at the application level

Do not rely on proprietary protocols–it would be harder to integrate them later

conclusion

Distributed systems have been around for years, but there are still a lot of problems. Unfortunately, many architects still ignore some of these problems when designing. Hopefully, the fallacies listed above will help architects avoid some of these problems when designing.