Fallacies of Distributed Architectures

Distributed architectures offer many highly-ranking characteristics such as availability and scalability.

Due to this they have earned a good reputation and are constantly being advocated for by many, however, it is often the case that all positives are highlighted with no mention of trade-offs.

“If an architect thinks they have discovered something that isn’t a trade-off, more likely they just haven’t identified the trade-off yet.” - Mark Richards and Neal Ford

Therefore it is important to conduct a cost-benefit analysis before making architectural decisions, this allows for more informed decision-making as the cost may outweigh the benefit, although one problem may be solved by a decision, that same decision may spawn more significant problems than it addresses.

A good way to bring some of the trade-offs into light is by reviewing the assertions made by L. Peter Deutsch and others at Sun Microsystems in 1996. These assertions describe false assumptions that are made in relation to distributed computing, these assumptions still hold even with the technological advancements of today!

1 – The Network is reliable: All distributed systems rely on networks for communication between services, while networks have become more reliable over time they are still prone to failure, certain approaches can be adopted to minimize the impact such as adopting circuit breakers and timeouts.

2 - Latency is zero: Calls over a network via a remote access protocol are more costly than calls made locally such as those via functions. Therefore it is best to keep in mind the average round-trip latency for calls. For example, a request may be handled by 10 calls spread across 10 service, each consuming 100ms will result in a round trip of 1s, how would this impact the performance of your system?

3 - Bandwidth is infinite: The amount of data that flows within a network at a given time is limited, this can lead to performance suffering when the bandwidth is overloaded, Imagine how a call returning a merely 500kb data can impact system performance if called 2,000 times a second, this consumes 1gb of data per second! This problem is often made worse by Stamp Coupling.

4 – The Network is secure: Vulnerabilities can always be found no matter how many firewalls or VPNs exist, requiring security to be applied at multiple layers and now that your system consists of individually deployable units, each unit must be secured adding an additional overhead to the processing of each deployable unit as it will apply authentication logic to each call it receives.

5 – Topology does not change: Network topologies often change, the most minor of changes can lead to increased latency which leads to the triggering of circuit breakers and timeouts therefore it is best for network changes to be made in consultation with system architects,

6 – There is one administrator: Entire teams may be dedicated to administering networks, these makes it more difficult for network changes to be coordinated with architects to mitigate increased latency.

7 – Transport cost is Zero: Monetary values may be incurred by the infrastructure required for inter-service communication in the form of requiring soft/hard resources, servers, firewalls etc.

8 – The network is homogeneous: Networks are made off devices by various vendors supporting different protocols this makes it impossible to account for all situations and circumstances leaving room for packet loss and other network reliability issues.

Although distributed architectures outperform monolithic architectures in certain traits, they impose a requirement to handle problem scenarios that would not have existed otherwise, this trade-off is often overlooked which leads to undefined behavior when these problems do arise as they were not foreseen, to begin with.