Fallacies of Distributed Computing

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.^[1]

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.

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.^[2]

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,^[1] 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 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.^[1]

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.

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.^[1]

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.^[3]

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.^[1]

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.^[4]

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.^[5][6] 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.

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

1. ↑ ^{a b c d e} Fallacies of Distributed Systems. 4. Juni 2022, abgerufen am 5. Februar 2023 (englisch). 
2. ↑ Arnon Rotem-Gal-Oz: Fallacies of Distributed Computing Explained. Januar 2008, abgerufen am 5. Februar 2023 (englisch). 
3. ↑ Tobias Jonas: ChatGPT: Die Cloud Kosten des berühmtesten AI Sprachmodells. In: innFactory. 10. Januar 2023, abgerufen am 5. Februar 2023 (deutsch). 
4. ↑ Ingrid Van Den Hoogen: Deutsch’s Fallacies, 10 Years After. 8. Januar 2004, archiviert vom Original am 11. August 2007; abgerufen am 2. April 2023 (englisch). 
5. ↑ Tim Visée: Falsehoods programmers believe about time, in a single list. Abgerufen am 5. Februar 2023 (englisch). 
6. ↑ Falsehoods programmers believe about time. Abgerufen am 5. Februar 2023 (amerikanisches Englisch).