Fallacies of Distributed Computing: 5. Topology doesn't change
Tags: distributedcomputing
Published: 2020-05-25 00:00:00

---
title: "Fallacies of Distributed Computing: 5. Topology doesn't change"
date: "2020-05-25T00:00:00.000Z"
tags: ["distributedcomputing"]
---

[The fallacies of distributed computing](https://web.archive.org/web/20171107014323/http://blog.fogcreek.com/eight-fallacies-of-distributed-computing-tech-talk/) are a set of assertions describing false assumptions made about distributed systems. 

[L. Peter Deutsch](https://en.wikipedia.org/wiki/L._Peter_Deutsch) drafted the first 7 fallacies in 1994, with the 8<sup>th</sup> added by [James Gosling](https://en.wikipedia.org/wiki/James_Gosling) in 1997.

The 8 fallacies are:

1. [The network is reliable](https://dereklawless.ie/fallacies-of-distributed-computing-1-the-network-is-reliable)
1. [Latency is zero](https://dereklawless.ie/fallacies-of-distributed-computing-2-latency-is-zero)
1. [Bandwidth is infinite](https://dereklawless.ie/fallacies-of-distributed-computing-3-bandwidth-is-infinite)
1. [The network is secure](https://dereklawless.ie/fallacies-of-distributed-computing-4-the-network-is-secure)
1. [Topology doesn't change](https://dereklawless.ie/fallacies-of-distributed-computing-5-topology-doesnt-change)
1. [There is one administrator](https://dereklawless.ie/fallacies-of-distributed-computing-6-there-is-one-administrator)
1. [Transport cost is zero](https://dereklawless.ie/fallacies-of-distributed-computing-7-transport-cost-is-zero)
1. [The network is homogeneous](https://dereklawless.ie/fallacies-of-distributed-computing-8-the-network-is-homogeneous)

## 5. Topology doesn't change

### The problem

Network topology is volatile:

- Environments may have differing network requirements -- from quickly spun up development environments through to production environments supporting high availability, resiliency, and redundancy
- Firewall rules are likely to change in response to security concerns or application requirements
- Services may be introduced (e.g. federated authentication) or deprecated, changing network topology

The topology of the network is typically outside your control. Servers may be added or retired, network services may be upgraded or deprecated, planned and unplanned outages may occur.

In cloud computing scenarios -- where elasticity is typically a key motivation for adoption -- network topology will mutate in response to load and utilisation.

__Network topology changes constantly.__

### Solutions

Given that network toplogy is indeed volatile, there are two broad approaches that can be taken to buffer against topology changes.

#### Abstract network specifics

- Avoid referencing IP addresses directly, instead using <abbr title="Domain Name System">DNS</abbr> hostnames to reference resources
- Consider using a [service discovery pattern](https://microservices.io/patterns/server-side-discovery.html) for Microservice architectures

#### Design for failure

- Design your architecture to avoid irreplaceability, assume any server may fail
- Introduce [chaos engineering](https://en.wikipedia.org/wiki/Chaos_engineering) and test for system behaviour under infrastructure, network, and application failures