Verteilung hat nicht nur Vorteile

Das Gottlieb-Duttweiler-Institut hat unter dem Titel «Hype oder Hilfe? Was Blockchain wirklich kann» eine Studie mit den Vorteilen der Blockchain veröffentlicht. Darin wird impliziert, dass mehr Verteilung bei einem IT-System automatisch besser sei. Dem ist nicht immer so.

Meine Analyse zur GDI-„Studie“ ist inzwischen veröffentlicht.

Laut GDI-Report gibt es eine Achse „zentral→verteilt→dezentral“ entlang der alles besser würde (abgesehen davon, dass die Abgrenzung zwischen „verteilt“ und „dezentral“ nicht so klar ist). Leider ist das nicht der Fall. So gibt es etliche Probleme, die zentral einfacher gelöst werden können. Und es macht auch einen Unterschied, ob ich in einem verteilten System Daten lesen oder aber schreiben will:

• Wenn Daten nur gelesen werden sollen, kann es nicht genug Kopien geben, wenn die Verfügbarkeit („Availability“) der Daten wichtig ist.
• Sobald aber auch noch geschrieben werden können soll, wird es schwierig: Da müssen nämlich bei einer Änderung immer restlos alle Kopien aktualisiert werden um die Konsistenz („Consistency“) zu gewährleisten. Und je mehr Kopien vorhanden sind, desto aufwändiger wird das.
• Ganz schwierig wird es, wenn einzelne der Kopien unbekannt sind oder gerade nicht erreichbar, wegen einem Ausfall des Rechners oder der Netzverbindung zwischen dem Schreiber und der Kopie, auch bekannt als Netzwerkpartitionierung („Partitioning“). Ein Knoten, der jenseits dieser Partitionsgrenze liegt wird fröhlich mit den veralteten Daten arbeiten, da für die Änderung ja kein Durchkommen ist.

Dass man in einem vernetzten System nicht gleichzeitig 100%ige Verfügbarkeit und 100%ige Konsistenz garantieren kann, falls das Netzwerk auch einmal ausfallen soll, ist als CAP-Theorem bekannt (Consistency, Availability, Partition tolerance).

Alle drei gleichzeitig zu erreichen ist beweisbar unmöglich, entsprechend kann auch eine Blockchain dies nicht lösen. (Eine Auswirkung des CAP-Theorems erleben wir übrigens, wenn eine Webseite nicht funktioniert und dies durch einen Reload der Seite behoben werden kann.)

Beispiele

Schauen wir uns ein paar Beispiele an:

• Eine zentrale Lösung fällt aus, wenn der zentrale Server weg ist (=keine Availability). Dafür gibt es aber keine Konsistenzprobleme, auch nicht, wenn das Netzwerk Probleme hat.
• Die Blockchain an sich hat eine relativ hohe (Lese-)Verfügbarkeit. Aber bei einer Partitionierung können Inkonsistenzen entstehen, da potenziell beide Seiten unabhängig voneinander weiter arbeiten. (Wenn das Netzwerkproblem behoben ist, gewinnt eine der beiden Seiten und der Zustand der anderen Seite ist verloren.)
• Das globale Emailsystem ist ein föderierter Dienst, eine spezielle Art der Verteilung, an der wir die Flexibilität auch von Nicht-Blockchain-basierten Diensten aufzeigen können. Bei einem föderierten Dienst arbeiten verschiedene unabhängige Provider zusammen, jeder hat seine eigene Verantwortlichkeit.
  • Aus Sicht des Mailprogramms (Clientsicht) verhält sich „sein“ Mailserver wie ein zentraler Dienst (möglicherweise nicht verfügbar, sonst aber OK).
  • Wenn das Mailprogramm via IMAP-Mailprotokoll eine synchronisierte Kopie der Mailboxen hält, sind die Mails auch bei Netzunterbruch oder Mailservercrash weiterhin lesbar. Änderungen an den Mailboxen führen zu Inkonsistenzen (die aber Aufgrund der unterstützen Operationen meist relativ glimpflich ausgehen).
  • Zwischen verschiedenen Mailservern (Systemsicht) gibt es eigentlich keine Konsistenzprobleme, da sie nicht auf denselben Daten arbeiten und jeder in Bezug auf die anderen autonom sind. Aber wenn natürlich die Verbindung zwischen den Servern ausfällt, kommen die Nachrichten natürlich erst nach der Reparatur wieder an.

Schlussfolgerungen

Mehr Kopien bzw. mehr Verteilung hat manchmal Vorteile, manchmal Nachteile. Das hängt immer

• an der Anwendung die darauf aufbaut,
• den Operationen, welche auf den Daten ausgeführt werden sollen,
• den Bedürfnissen der Nutzer der Anwendung und
• welche Fehler welche Auswirkungen haben sollen.

Fehler kommen immer vor, auf verschiedenen Ebenen. Wir brauchen die richtige Fehlerkultur, die auf das Anwendungsproblem passt. Das lässt sich nicht durch eine Technik wegzaubern. Auch nicht durch die Blockchain.