Fallacies of Distributed Computing

Die Fallacies of Distributed Computing (englisch für Irrtümer der verteilten Datenverarbeitung) sind eine Sammlung eigentlich trivialer, aber doch häufiger fehlerhafter Annahmen, die Programmierer voraussetzen, wenn sie insbesondere das erste Mal eine verteilte Anwendung entwickeln. Die (heute) acht Trugschlüsse werden zitiert als:

1. Das Netzwerk ist ausfallsicher.
2. Die Latenzzeit ist gleich null.
3. Der Datendurchsatz ist unbegrenzt.
4. Das Netzwerk ist sicher.
5. Die Netzwerktopologie wird sich nicht ändern.
6. Es gibt immer nur einen Netzwerkadministrator.
7. Die Kosten des Datentransports können mit null angesetzt werden.
8. Das Netzwerk ist homogen.

Inhomogenes, verteiltes, nicht-ausfallsicheres Netzwerk

Alle der obigen Annahmen sind falsch.

Erklärungen

Das Netzwerk ist ausfallsicher

Obwohl die Netzwerkinfrastruktur-Hardware heute sehr zuverlässig ist und Router und Switches nur selten ausfallen, gibt es dennoch keine Garantie dafür. Auch die Stromversorgung kann unerwartet und im dümmsten Moment abbrechen. Netzwerkprotokolle müssen also so gebaut werden, dass sie mit verlorenen oder verzögerten Paketen umgehen können. Nötigenfalls ist Transaktionsmanagement erforderlich, um bei der Unterbrechung einer Kommunikation keine undefinierten Zustände zu hinterlassen.

Die Latenzzeit ist gleich null

Als Latenzzeit bezeichnet man in einem Netzwerk die Zeit, die ein Datenpaket braucht, um von A nach B zu gelangen. Sie ist niemals null, und im Gegensatz zur Bandbreite (siehe nächsten Abschnitt) kann sie auch nicht beliebig verkleinert werden, da sie physisch durch die Lichtgeschwindigkeit begrenzt ist: Die Paketumlaufzeit von Europa nach Amerika wird immer mindestens 30ms betragen. Eine kurze Latenzzeit ist bei Echtzeit-Anwendungen wie Onlinespielen wichtiger als eine große Bandbreite.

Der Datendurchsatz ist unbegrenzt

Obwohl der Datendurchsatz (auch Bandbreite genannt) in den letzten Jahren deutlich zunahm, ist er immer gegen oben begrenzt. Zusammen mit der Zunahme der Bandbreite steigt jedoch auch das Datenaufkommen kontinuierlich. Wird eine Software nur im lokalen Netzwerk getestet, wo die Latenz typischerweise sehr klein und die Bandbreite sehr hoch sind, können später beim Einsatz dieser Software im Internet unerwartete Probleme auftreten. Da die Paketverlustrate bei weiten Verbindungen zunimmt, wird die Bandbreite nach oben begrenzt, da Paketwiederholungen teuer sind. Man kann versuchen, die Paketgröße zu erhöhen, um den Durchsatz weiter zu steigern, aber größere Pakete gehen mit einer höheren Wahrscheinlichkeit verloren.

Das Netzwerk ist sicher

Die Annahme, dass es keine Hacker gibt und sämtliche Rechner und Anwender im Netzwerk vertrauenswürdig sind, wird heute kaum mehr jemand machen. Als diese falsche Annahme 1991 erstmals niedergeschrieben wurde, war das Internet allerdings noch sehr jung und nur in universitären Einrichtungen wirklich verbreitet.

Obwohl heute jeder Informatiker weiß, dass böswillige Personen versuchen, in Netzwerke einzudringen und Daten zu stehlen oder zu manipulieren, werden immer noch viel zu oft viel zu schwerwiegende Sicherheitsmängel in Software entdeckt. Zudem gehen gerade Firmen oft davon aus, dass Angreifer von außen, also über das Internet, kommen müssten, um Schaden zu verursachen. Tatsächlich sind Firewalls heute ziemlich sicher, aber durch Phishing oder „verlorene“ USB-Sticks (siehe Rubber Ducky) können Angriffe auch aus der Firma heraus gestartet werden.

Die Netzwerktopologie wird sich nicht ändern

Die Annahme, dass sich Server oder Clients in einem verteilten System nicht ändern werden, ist unrealistisch. Wenn beispielsweise eine Applikation viel Zuspruch erfährt, wird sie möglicherweise bald skalieren müssen und es werden Server hinzugefügt, ersetzt oder geografisch verschoben. Dasselbe gilt in einem noch viel höheren Maße für die Clients, denn die Benutzer werden ständig neue und andere Rechner einsetzen. Eine Applikation sollte daher nicht von einer statischen Netzwerktopologie ausgehen, und beispielsweise Rechneradressen via DNS auflösen anstatt feste IP-Adressen zu verwenden.

Es gibt immer nur einen Netzwerkadministrator

Das mag für kleine Teams gelten, ist aber in großen Firmen oder bei firmenübergreifenden Projekten sicher nicht zutreffend. Die Annahme, dass ein Administrator (oder ein Team von Administratoren) auf alle involvierten Systeme uneingeschränkten Zugriff hat, ist dann nicht mehr realistisch und auch aus Sicherheitsgründen nicht wünschenswert. Jede Firma möchte aus nachvollziehbaren Gründen anderen nur so viele Rechte einräumen, wie diese unbedingt benötigen. Selbst innerhalb einer größeren Firma darf kein einzelner Benutzer auf alle Ressourcen zugreifen.

Die Administratoren, die das produktive System am Laufen halten sollten, sind auch nicht unbedingt die Entwickler des Systems, so dass sie zwar Zugriff auf Diagnosedaten haben, aber diese erst mit dem (internen oder externen) Entwicklungsteam diskutieren müssen, falls unerwartete Effekte auftreten.

Die Kosten des Datenaustauschs können mit Null angesetzt werden

Eine Weise, diese Behauptung zu lesen, ist der Versuch, eine auf einen Server zugeschnittene Anwendung in ein verteiltes System umzuwandeln. Wegen Punkt 2 wissen wir aber, dass dadurch ein System sicher nicht schneller wird und neue Probleme auftauchen können.

Die zweite Weise ist offensichtlicher: Obwohl Breitband-Internetanschlüsse heute erschwinglich sind, sind ihre Kosten nicht null, insbesondere wenn man auch die Netzwerkadministration und die nötige Sicherheitsinfrastruktur (Firewalls, Router) mitrechnet. Die Betriebskosten des Chatbots ChatGPT wurden Anfang 2023 mit zwischen 100.000 und 1.500.000 € pro Tag angegeben.

Das Netzwerk ist homogen

Diese Annahme wurde erst 1997 von James Gosling der Liste hinzugefügt. Die Annahme, dass alle Server und alle Clients unter der Kontrolle der Entwickler stehen, war zuvor durchaus realistisch gewesen. Eine Firma hatte es im Griff, nur eine Art von Geräten oder Betriebssystemen zu unterstützen. Heute finden sich schon in kleinen Netzwerken Rechner mit verschiedenen Betriebssystemen, dazu Smartphones und smarte Geräte, die alle miteinander kommunizieren wollen. Durch Standardisierung sind mittlerweile Webbrowser weitgehend kompatibel zueinander, aber das war nicht immer so.

Es ist einfacher, bereits bei der Planung von Software vorzusehen, sie auf verschiedene Plattformen zu portieren, statt das nachträglich durchführen zu müssen.

Entwicklung

Die Liste der Fallacies of Distributed Computing kommt ursprünglich von Sun Microsystems und wurde dort von Bill Joy und Tom Lyon mit vier Trugschlüssen eröffnet. Weite Bekanntheit erlangten sie 1994 durch L Peter Deutsch, der sie erweitert auf sieben Trugschlüsse als „The Seven Fallacies of Distributed Computing“ veröffentlichte. James Gosling, ebenfalls von Sun, setzte ungefähr 1997 noch den achten Punkt dazu.

Vergleichbare Listen

Es gibt weitere Bereiche, in denen auch erfahrene Programmierer immer wieder dieselben Fehler gemacht haben. Ein berühmtes Beispiel sind falsche Annahmen über die Zeit, beziehungsweise über deren absolute Gültigkeit und Eindeutigkeit. Alle der dort angegebenen Annahmen – die jeder intuitiv als logisch erachten würde – sind unter gewissen Bedingungen falsch und können daher zu undefiniertem Verhalten von Software führen.

Quellen

• Arnon Rotem-Gal-Oz: Fallacies of Distributed Computing Explained (PDF; 254 kB)
• Moderne Erklärung der Irrtümer, Juni 2022, (englisch)