Engineering-Philosophie: Werner Vogels

Die wichtigsten Erkenntnisse

• Sein prägendes Prinzip lautet, dass alles ständig ausfällt — also entwirft man auf Ausfall hin und nicht gegen ihn. Als CTO von Amazon seit 2005 hat Werner Vogels eine nüchterne Beobachtung — bei hinreichender Größenordnung ist der Ausfall von Komponenten ein Dauerzustand und statistisch garantiert — in eine Entwurfsdoktrin verwandelt: Gehen Sie davon aus, dass jede Festplatte, jeder Server, jede Netzwerkverbindung und jede Abhängigkeit ausfallen wird, und bauen Sie Systeme, die durch den Ausfall hindurch verfügbar bleiben, statt so zu tun, als ließe er sich verhindern.¹⁶
• Er war Mitautor des Dynamo-Papers, das die Ideen hinter modernem NoSQL begründete. „Dynamo: Amazon’s Highly Available Key-value Store” (SOSP 2007) vereinte Consistent Hashing, Vector Clocks, Sloppy Quorums, gossip-basierte Mitgliedschaft und Eventual Consistency in einem stets schreibbaren Speicher und beeinflusste unmittelbar Cassandra, Riak, Voldemort und Amazons eigenes DynamoDB.²³
• Er ist der führende Verfechter von Eventual Consistency. Sein Essay „Eventually Consistent” legte den Kompromiss zwischen Verfügbarkeit und Konsistenz schonungslos dar: Wenn das Netzwerk partitioniert — und bei dieser Größenordnung wird es das — müssen Sie sich entscheiden, und Dynamo entschied sich dafür, verfügbar zu bleiben und bald zu konvergieren, statt zu blockieren, bis jedes Replikat übereinstimmt.⁴⁷
• Er hat der Engineering-Kultur den Satz „you build it, you run it” geschenkt. In einem Gespräch von 2006 beschrieb er Amazons Modell, in dem Entwickler ihre Dienste in Produktion selbst verantworten — sie zuschneiden, bauen und betreiben — und argumentierte, dass es die Qualität antreibt, wenn man die Erbauer an den Pager und vor den Kunden stellt.⁵

Das Prinzip

„Everything fails, all the time.” — Werner Vogels, CTO von Amazon, über den Entwurf zuverlässiger verteilter Systeme⁶

Die meiste Ingenieursarbeit optimiert für den Fall, dass alles funktioniert. Man baut den Glücksfall, behandelt die wenigen Fehler, die man sich vorstellen kann, und liefert aus. Dieser Instinkt überlebt genau bis zu dem Punkt, an dem man bei großer Größenordnung arbeitet — und dann verrät er einen. Wenn Sie Hunderttausende von Maschinen betreiben, hört „selten” auf, selten zu sein. Ein Festplattenausfall, der pro Laufwerk einmal in drei Jahren auftritt, geschieht irgendwo in Ihrer Flotte alle paar Minuten. Eine Netzwerkverbindung, die ein Paket von einer Million verliert, verliert täglich Millionen von Paketen. Vogels’ berühmtester Satz verdichtet das auf vier Worte: everything fails all the time.⁶ Ausfall ist keine Ausnahme, um die herum man konstruiert; bei großer Größenordnung ist er der Dauerzustand, für den man konstruieren muss.

Das Prinzip, das daraus folgt, ist die Umkehrung des üblichen. Wenn Sie Ausfall nicht verhindern können — und bei dieser Größenordnung können Sie es nachweislich nicht — dann ist seine Verhinderung das falsche Ziel. Das richtige Ziel ist, verfügbar zu bleiben, während Dinge ausfallen. Also nehmen Sie an, dass jede Komponente sterben wird, und entwerfen so, dass jeder einzelne Tod überlebbar ist: Replizieren Sie Daten über Maschinen hinweg, sodass der Verlust einer einzelnen unsichtbar bleibt; entkoppeln Sie Dienste hinter APIs, sodass eine ausfallende Abhängigkeit eine Funktion abschwächt, statt das System zu stürzen; und minimieren Sie den Schadensradius jedes einzelnen Fehlers, damit er nicht das Ganze niederreißen kann. Das System ist nicht darauf gebaut, den Ausfallfall zu vermeiden; es ist so gebaut, dass der Ausfallfall langweilig ist.¹⁶

Es gibt eine zweite Hälfte des Prinzips, und sie ist es, die die erste Hälfte erst real macht: Sie können nicht zugleich perfekte Konsistenz und perfekte Verfügbarkeit haben, sobald das Netzwerk partitionieren kann — also müssen Sie sich entscheiden, und Vogels entschied sich für Verfügbarkeit. Wenn eine Netzwerktrennung Ihre Replikate voneinander abschneidet, kann ein System entweder die Antwort verweigern, bis alle übereinstimmen (konsistent, aber nicht verfügbar), oder weiterhin mit dem antworten, was es hat, und später abgleichen (verfügbar, aber kurzzeitig inkonsistent). Für Amazons Warenkorb war es inakzeptabel, die Antwort zu verweigern — ein Warenkorb, der während einer Partition ein „In den Warenkorb” ablehnt, ist ein Warenkorb, der einen Verkauf verliert.⁴ Also akzeptiert Dynamo den Schreibvorgang immer und lässt die Replikate danach konvergieren. Der Preis ist ein kleines Zeitfenster, in dem verschiedene Replikate unterschiedliche Antworten liefern können; der Gewinn ist ein System, das einem Kunden niemals „nein” sagt. Dieser Kompromiss — verfügbar bleiben und bald konvergieren, statt zu blockieren, bis alle übereinstimmen — ist Eventual Consistency, und Vogels hat eine ganze Karriere damit verbracht, dafür zu argumentieren, dass es bei großer Größenordnung der richtige Kompromiss ist.⁴⁷

Kontext

Werner Vogels wurde am 3. Oktober 1958 in Ermelo, Niederlande, geboren.¹ Sein Weg in die Informatik war nicht die übliche schnurgerade Linie durch eine Spitzenuniversität. Er studierte Informatik an der Haagse Hogeschool, schloss 1989 ab und erwarb erst später einen Doktortitel in Informatik an der Vrije Universiteit Amsterdam — seine Dissertation von 2003, „Scalable Cluster Technologies for Mission Critical Enterprise Computing”, wurde von Henri Bal und Andrew Tanenbaum betreut, letzterer eine der grundlegenden Gestalten des Fachs in verteilten Systemen und Betriebssystemen.¹ Bemerkenswert ist, dass die Promotion jahrelanger echter Systemarbeit folgte, statt ihr vorauszugehen; die Theorie holte die Praxis ein.

Das prägendste Kapitel ereignete sich an der Cornell University, wo er von 1994 bis 2004 als Forschungswissenschaftler an skalierbaren, zuverlässigen Unternehmenssystemen arbeitete.¹ In Cornell gehörte er zur Gruppe für verteilte Systeme von Ken Birman — der Linie hinter Isis und zuverlässiger Gruppenkommunikation, jenem Werk, das fragte, wie eine Menge von Maschinen sich einigen, konsistent bleiben und weiterlaufen kann, während Mitglieder ausfallen und sich erholen. Er war Mitgründer eines Unternehmens, Reliable Network Solutions, zusammen mit Birman und Robbert van Renesse, und diente dort als VP und CTO.¹ Das ist der geistige Boden, in dem Vogels heranwuchs: nicht „wie hindern wir Maschinen am Ausfallen”, sondern „wie bleibt eine Gruppe von Maschinen korrekt und verfügbar, während ihre Mitglieder ausfallen”. Als er später sagte, alles falle ständig aus, improvisierte er nicht — er formulierte die Gründungsprämisse jener Tradition zuverlässiger verteilter Systeme, in der er ein Jahrzehnt verbracht hatte.

Er trat Amazon im September 2004 als Director of Systems Research bei, wurde im Januar 2005 zum CTO ernannt und erhielt im März 2005 zusätzlich den VP-Titel — die Rolle, die er seither innehat und mit der er die Technologieausrichtung über das gesamte Unternehmen hinweg vorantreibt.¹ Sein Eintritt fiel mit den Jahren zusammen, in denen Amazon die moderne Cloud erfand: Das Dynamo-Speichersystem wurde in dieser Zeit gebaut und niedergeschrieben, Amazon Web Services brachte seine grundlegenden Dienste auf den Markt, und Vogels wurde zur öffentlichen Stimme der architektonischen Prinzipien, die all dem zugrunde liegen — auf Ausfall hin entwerfen, über Dienste entkoppeln, Eventual Consistency annehmen und die Menschen, die einen Dienst bauen, auch für dessen Betrieb verantwortlich machen.²⁴⁵

Das Werk

„Everything fails all the time”: auf Ausfall hin entwerfen und Eventual Consistency

Beginnen Sie hier, denn dies ist das Prinzip, zu Engineering geworden. Die Doktrin hat zwei Bewegungen. Die erste ist auf Ausfall hin entwerfen: jede Komponente als etwas behandeln, das ausfallen wird, und das System ihren Verlust überleben lassen. Das bedeutet Redundanz (replizieren, sodass jede einzelne Kopie verschwinden kann), Entkopplung (Dienste sprechen über APIs, sodass eine kranke Abhängigkeit kontrolliert abschwächt, statt zu kaskadieren) und Eindämmung des Schadensradius (das System partitionieren, sodass ein Fehler in einer kleinen Zelle gefangen bleibt, statt sich auszubreiten).¹⁶ Der Prüfstein eines Entwurfs ist nicht „funktioniert es, wenn alles gesund ist”, sondern „was geschieht, wenn dieses Teil im denkbar schlechtesten Moment stirbt” — und die Antwort muss lauten: „Das System bedient weiter.”

Die zweite Bewegung ist diejenige, die hohe Verfügbarkeit bei großer Größenordnung möglich macht: Eventual Consistency. Eric Brewers CAP-Beobachtung besagt, dass ein verteiltes System bei einer Netzwerkpartition nicht zugleich perfekt konsistent und voll verfügbar sein kann — es muss eines aufgeben.⁷ Vogels’ „Eventually Consistent” macht die Wahl explizit und definiert die Alternative präzise: Unter Eventual Consistency „garantiert das Speichersystem, dass, wenn keine neuen Aktualisierungen am Objekt vorgenommen werden, schließlich alle Zugriffe den zuletzt aktualisierten Wert zurückgeben.”⁴ Das Wort schließlich ist der ganze Kompromiss. Ein System, das Verfügbarkeit betont, „akzeptiert den Schreibvorgang möglicherweise immer, aber unter bestimmten Bedingungen wird ein Lesevorgang das Ergebnis eines kürzlich abgeschlossenen Schreibvorgangs nicht widerspiegeln.”⁴ Für ein kurzes, begrenztes Zeitfenster können zwei Replikate uneins sein — doch keines verweigert je die Antwort. Die Konvergenz geschieht im Hintergrund, und der Benutzer wird nie blockiert.

Warum es als Engineering zählt: Das mentale Modell der meisten Entwickler von einer Datenbank ist das der Einzelmaschine, bei der ein Schreibvorgang für jeden nachfolgenden Lesevorgang sofort sichtbar ist, weil es nur eine Kopie gibt. Dieses Modell überlebt die Größenordnung nicht, denn eine Kopie ist ein Single Point of Failure und eine Maschine eine Obergrenze für den Durchsatz. In dem Moment, in dem Sie replizieren — was Sie müssen, um verfügbar zu sein — erben Sie die Frage, was ein Leser sieht, während die Kopien aufholen. Vogels’ Beitrag bestand darin, darauf zu bestehen, dass dies kein zu verbergender Fehler ist, sondern eine bewusst zu wählende Entwurfsdimension, und Ingenieuren das Vokabular zu geben — read-your-writes, monotonic reads, Sitzungskonsistenz —, um genau auszuwählen, wie viel Konsistenz eine gegebene Arbeitslast tatsächlich braucht, statt überall für die stärkste Garantie zu bezahlen.⁴

Das Dynamo-Paper und die NoSQL-Bewegung

Das Prinzip hat ein kanonisches Artefakt: „Dynamo: Amazon’s Highly Available Key-value Store”, das Vogels mitverfasste und das auf der SOSP 2007 veröffentlicht wurde, dem führenden Forum des Fachs für Betriebssysteme.² Dynamo war Amazons Antwort auf eine spezifische, brutale Anforderung — der Warenkorb musste Schreibvorgänge immer akzeptieren, selbst während Rechenzentrumspartitionen und Festplattenausfällen, weil ein nicht verfügbarer Warenkorb unmittelbar Umsatz kostet.²³ Traditionelle relationale Datenbanken, auf starke Konsistenz abgestimmt, konnten das unter Partition nicht versprechen. Also baute Amazon einen Speicher, der Konsistenz gegen Verfügbarkeit eintauschte, und schrieb genau auf, wie.

Dynamo ist ein Katalog von Techniken verteilter Systeme, zusammengefügt zu einem einzigen, stets schreibbaren, dezentralen System, und der Einfluss des Papers rührt daher, wie sauber es sie darlegte.²³ Consistent Hashing partitioniert Daten über Knoten hinweg, sodass der Ring wachsen oder schrumpfen kann, ohne alles umzuverteilen — „inkrementelle, möglicherweise lineare Skalierbarkeit.”³ Vector Clocks verfolgen die kausale Geschichte jedes Werts, sodass nebenläufige Schreibvorgänge erkannt statt stillschweigend verloren werden. Sloppy Quorums und hinweisbasierte Übergabe halten das System schreibbar, selbst wenn einige Replikate nicht erreichbar sind, indem sie Schreibvorgänge auf einem vorübergehenden Stellvertreter parken, bis der rechtmäßige Knoten zurückkehrt. Anti-Entropie mit Merkle-Bäumen lässt Replikate ihre Unterschiede effizient finden und reparieren. Gossip-basierte Mitgliedschaft lässt Knoten voneinander erfahren und Ausfälle ohne zentralen Koordinator erkennen — der Entwurf ist bewusst symmetrisch und dezentral, sodass „jeder Knoten in Dynamo dieselben Verantwortlichkeiten haben sollte wie seine Nachbarn”, was bedeutet, dass es keinen besonderen Knoten gibt, dessen Tod katastrophal wäre.³ Jede dieser Entscheidungen dient demselben Herrn: verfügbar bleiben, wenn Dinge ausfallen.

Amazon hat den Code von Dynamo nie veröffentlicht, doch das Paper erledigte die Arbeit — es wurde zu einem der einflussreichsten Systempapers seines Jahrzehnts, dem geistigen Samen der NoSQL-Bewegung.³ Apache Cassandra, Riak und Project Voldemort führen ihre führerlosen, eventually-consistent Entwürfe alle direkt darauf zurück.³ Und der Name lebte kommerziell weiter in Amazon DynamoDB, das auf den Prinzipien von Dynamo aufbaut, auch wenn es unter der Haube andere technische Entscheidungen traf (Replikation mit einem einzelnen Leader statt Dynamos rein führerlosem Modell).³ Die Lehre aus Dynamos Einfluss ist selbst bemerkenswert: Amazons Wettbewerbsgraben war nicht der Code, sondern die Klarheit. Indem sie genau erklärten, welche Garantien sie aufgaben und warum, lehrten sie eine ganze Generation von Ingenieuren, wie man über den Kompromiss nachdenkt.

AWS, Serviceorientierung und „you build it, you run it”

Dynamo ist ein Speichersystem; der tiefere Beitrag von Vogels ist architektonisch und kulturell. Amazons Plattform ist als ein Geflecht unabhängiger Dienste gebaut, die nur über APIs sprechen — keine gemeinsam genutzten Datenbanken, an die hinter dem Vorhang gegriffen wird, keine verborgene Kopplung.⁵ Diese Disziplin ist für den Ausfall entscheidend: Wenn Dienste hinter harten Schnittstellen entkoppelt sind, schwächt ein ausfallender genau die Funktion ab, die er antreibt, statt die Daten zu beschädigen oder die Threads von allem, was ihn berührte, zum Stillstand zu bringen. Serviceorientierung ist Eindämmung des Schadensradius, ausgedrückt als Architektur. Sie ist auch das, was AWS möglich machte — sobald Ihre internen Systeme saubere, über APIs ansprechbare Dienste sind, ist es ein natürlicher nächster Schritt, sie der Außenwelt als Produkte zugänglich zu machen.

Die kulturelle Hälfte ist der Satz, mit dem Vogels ebenso oft zitiert wird wie mit „everything fails all the time”: „you build it, you run it.” In einem Gespräch von 2006 mit Jim Gray beschrieb er Amazons Modell, in dem jeder Dienst von Anfang bis Ende dem Team gehört, das ihn erstellt: „Jeder Dienst hat ein Team, das ihm zugeordnet ist, und dieses Team ist vollständig für den Dienst verantwortlich — vom Abstecken der Funktionalität über das Entwerfen, das Bauen bis zum Betreiben.”⁵ Und die Begründung drehte sich ausdrücklich um Qualität durch Eigenverantwortung: „You build it, you run it. Das bringt Entwickler in Kontakt mit dem täglichen Betrieb ihrer Software. Es bringt sie auch in täglichen Kontakt mit dem Kunden.”⁵ Es gibt keine Mauer, über die man Code wirft; der Ingenieur, der den Dienst geschrieben hat, trägt für ihn den Pager. Die Wirkung ist eine enge Rückkopplungsschleife — die Person, die eine Schwachstelle am besten beheben kann, ist die, die um drei Uhr morgens deren Schmerz spürt, und die Person, die die Funktion entworfen hat, hört die Kundenbeschwerde unmittelbar. Eigenverantwortung ist hier keine HR-Parole; sie ist ein Zuverlässigkeitsmechanismus. Ein Team, das betreibt, was es baut, entwirft auf Ausfall hin, weil der Ausfall es aufweckt.

Die Cloud propagieren: Schadensradius, Zellen und well-architected Systeme

Vogels’ viertes Werk ist weniger ein einzelnes Artefakt als eine anhaltende Rolle: Seit zwei Jahrzehnten ist er der Architekt-Evangelist, der kodifiziert hat, wie man auf der Cloud baut, nicht nur, wie man die Cloud baut.¹⁶ Die wiederkehrenden Themen sind das Prinzip, auf immer größeren Maßstab angewandt. Den Schadensradius minimieren: Systeme in unabhängige Zellen partitionieren, sodass ein Fehler, ein schlechtes Deployment oder eine giftige Anfrage auf einen Ausschnitt der Kunden eingedämmt bleibt statt auf alle. Aggressiv entkoppeln: asynchrone, lose gekoppelte Dienste mit expliziten Verträgen vorziehen gegenüber engen synchronen Ketten, in denen eine langsame Abhängigkeit den gesamten Aufrufpfad zum Stillstand bringt. Die Wiederherstellung automatisieren, nicht dokumentieren: Ein Runbook, das einen Menschen braucht, läuft nicht ab, wenn der Mensch schläft. Ausfall als Testeingabe annehmen, bewusst Fehler injizieren, um zu beweisen, dass das System sie überlebt, statt zu hoffen, dass es das tut. Jedes davon ist „everything fails all the time”, in eine Betriebspraxis verwandelt — die konsistente Botschaft, über Vorträge und Schriften und ein zweites ACM-Gespräch Jahre später hinweg wiederholt, dass Resilienz eine Eigenschaft ist, die man von der ersten Zeile an einbaut, und keine Schicht, die man hinzufügt, nachdem die Demo funktioniert.⁶

Die Methode

Lesen Sie quer durch Dynamo, Eventual Consistency, Serviceorientierung und „you build it, you run it”, und dieselben Verpflichtungen kehren wieder. Vogels’ Methode ist weniger ein Slogan als ein Satz stehender Gewohnheiten.

Zuerst für den Ausfallfall entwerfen. Bei großer Größenordnung ist Ausfall der Dauerzustand, nicht die Ausnahme, also lautet die Frage nie „funktioniert das”, sondern „was geschieht, wenn jedes Teil davon stirbt.”⁶ Die Lehre überträgt sich weit über Amazons Größenordnung hinaus: Schreiben Sie nicht den Glücksfall und flicken die Fehlerbehandlung hinein — zählen Sie zuerst die Ausfallmodi auf und lassen Sie den funktionierenden Pfad aus einem System hervorgehen, das sie bereits überlebt. Es ist die Beweisschwelle, angewandt auf Zuverlässigkeit — „es funktioniert in der Demo” ist kein Beweis; „es bleibt verfügbar, wenn ich mitten in einer Anfrage einen Knoten töte” ist derselbe Maßstab für Selbstheilung, den Radia Perlman in Netzwerke einbaute, die ohne menschlichen Eingriff neu konvergieren.

Wählen Sie Ihre Konsistenz, erben Sie sie nicht. Die tiefste Bewegung in Dynamo ist die Weigerung, den Standard zu akzeptieren, dass jeder Lesevorgang jeden vorherigen Schreibvorgang sehen muss. Vogels macht Konsistenz zu einem Regler, den Sie pro Arbeitslast einstellen — stark, wo Korrektheit es verlangt, eventual, wo Verfügbarkeit wichtiger ist — und ist präzise darin, welche Garantie ein System tatsächlich bietet.⁴⁷ Die Disziplin besteht darin, genau zu wissen, worauf Ihr Konsistenzanspruch beruht, und nie für eine Garantie zu bezahlen, die eine Arbeitslast nicht braucht. Das ist dieselbe Präzision in Bezug auf Korrektheit, die Leslie Lamport in die verteilte Zeit brachte: Setzen Sie die Eigenschaft nicht voraus, definieren Sie sie exakt und wissen Sie, wann sie gilt.

Entkoppeln, um den Schadensradius einzudämmen. Unabhängige Dienste hinter harten APIs bedeuten, dass ein Ausfall dort gefangen bleibt, wo er geschieht, statt zu kaskadieren.⁵ Die stehende Gewohnheit ist, die Grenzen so zu ziehen, dass der schlimmste Fall eine abgeschwächte Funktion ist, nie ein ausgefallenes System — bei jeder Abhängigkeit zu fragen: „Wenn diese ausfällt, wie groß ist das Loch?” und das Loch klein zu machen. Es ist die architektonische Form des minimal würdigen Produkts: Die sauberste Grenze ist die, die genau ihre Aufgabe erfüllt und allein ausfällt.

Lassen Sie die Erbauer den Betrieb verantworten. „You build it, you run it” stellt die Menschen, die einen Dienst entwerfen, für ihn an den Pager und schließt die Schleife zwischen einer Schwachstelle und der Person, die sie beheben kann.⁵ Die Lehre ist, dass operativer Schmerz das ehrlichste Qualitätssignal überhaupt ist — ein Team, das von der Produktion abgeschirmt ist, wird zu wenig in Resilienz investieren, weil die Kosten der Fragilität bei jemand anderem landen. Eigenverantwortung ist ein Zuverlässigkeitsmechanismus, also Qualität ist die einzige Variable, in ein Organigramm verwandelt: Der einzige Weg, Qualität zu garantieren, ist, den Erbauer die Folge ihres Fehlens spüren zu lassen.

Erklären Sie den Kompromiss offen. Dynamos Einfluss rührte nicht von seinem Code — der nie veröffentlicht wurde —, sondern von einem Paper, das schlicht darlegte, welche Garantien aufgegeben wurden und warum.²³ Die Gewohnheit ist, die Argumentation lesbar zu machen: den Kompromiss benennen, die gewählte Seite begründen und den nächsten Ingenieur lehren, darüber nachzudenken, statt das Ergebnis im Cargo-Kult nachzuahmen. Klarheit über das Warum ist es, was einen Entwurf seinen Autor überleben lässt — dieselbe erklärende Disziplin, die Perlmans und Lamports Paper noch Jahrzehnte später lehrbar machte.

Einflusskette

Wer ihn geprägt hat

Ken Birman und die Cornell-Tradition zuverlässiger verteilter Systeme. Vogels’ Jahrzehnt in Cornell, innerhalb von Birmans Gruppe und der Isis-/zuverlässige-Gruppenkommunikation-Linie, ist die Quelle seiner Gründungsprämisse.¹ Die zentrale Frage jener Tradition — wie bleibt eine Gruppe von Maschinen korrekt und verfügbar, während ihre Mitglieder ausfallen und sich erholen — ist genau die Frage, die „everything fails all the time” beantwortet. Er prägte keinen Slogan; er formulierte das erste Prinzip seines Fachs für ein weltweites Publikum neu. (Prägender Einfluss)

Andrew Tanenbaum und die Akademie der verteilten Systeme. Seine Promotion an der Vrije Universiteit wurde zum Teil von Tanenbaum betreut, einem der grundlegenden Lehrer des Fachs für Betriebssysteme und verteilte Systeme.¹ Die Fundierung zeigt sich: Dynamo liest sich wie eine funktionierende Synthese des Kanons der verteilten Systeme — Consistent Hashing, Vector Clocks, Quorums, Gossip —, zusammengefügt von jemandem, der die Literatur in- und auswendig kannte. (Prägender Einfluss)

Eric Brewer und der CAP-Kompromiss. Vogels’ Plädoyer für Eventual Consistency beruht ausdrücklich auf der CAP-Beobachtung, dass ein partitionstolerantes System Konsistenz gegen Verfügbarkeit eintauschen muss.⁴⁷ Brewer formulierte die Unmöglichkeit; Vogels operationalisierte die Wahl in Amazons Größenordnung und machte „Verfügbarkeit wählen und konvergieren” zu einem respektablen Standard. (Direkter Einfluss)

Wen er geprägt hat

Die gesamte NoSQL-Bewegung. Das Dynamo-Paper ist der direkte Vorfahr von Cassandra, Riak und Voldemort und der Namensgeber von DynamoDB — das führerlose, eventually-consistent Entwurfsmuster verbreitete sich von einem einzigen Paper von 2007 in die Datenschicht einer ganzen Generation von Systemen.³

Cloud-native Architektur und DevOps-Kultur. „You build it, you run it” wurde zu einer der Gründungsideen des modernen DevOps — vollständige Diensteigenverantwortung, On-Call-Entwickler und die Auflösung der Dev/Ops-Mauer führen direkt auf das Modell zurück, das Vogels 2006 beschrieb.⁵

Eine ganze Generation von Cloud-Architekten. Durch die Entwurfsprinzipien von AWS und sein anhaltendes Evangelisieren wurden „auf Ausfall hin entwerfen”, „den Schadensradius minimieren” und „über Dienste entkoppeln” zum Standardvokabular, mit dem Ingenieure über das Bauen zuverlässiger Systeme auf der Cloud nachdenken.⁶

Der rote Faden

Vogels ist der Schlussstein der operativen Größenordnung in dieser Reihe — die Gestalt, die die Theorie der verteilten Systeme nahm und sie auf einem Planeten voller Maschinen laufen ließ. Leslie Lamport gab den verteilten Systemen ihre Grundlagen: wie man Zeit, Ordnung und Konsens präzise definiert und wie man ein System korrekt hält, wenn Teilnehmer ausfallen oder sich willkürlich verhalten. Vogels ist, wie diese Grundlagen aussehen, wenn sie einen Black-Friday-Warenkorb bedienen müssen — dieselben Fragen von Konsistenz und Ausfall, beantwortet nicht an einem Whiteboard, sondern unter echter Last, mit echtem Umsatz, der davon abhängt, verfügbar zu bleiben.⁴ Und Radia Perlman baute Netzwerke, die den Ausfallfall zum Entwurfszentrum machen und sich ohne menschlichen Eingriff selbst heilen; Vogels baute Dienste auf genau diesem Instinkt, eine Ebene höher im Stack — replizieren, entkoppeln, den Schadensradius eindämmen und das System von selbst konvergieren lassen. Wo Lamport sagt definiere Korrektheit und beweise, dass sie den Ausfall überlebt und Perlman sagt baue es so, dass es sich selbst heilt, sagt Vogels: Alles fällt ständig aus, also hör auf, es verhindern zu wollen — entwirf so, dass das System geradewegs durch den Ausfall hindurch verfügbar bleibt, und lass die Erbauer, die es betreiben, jeden Riss spüren. (Reihenbrücke)

Was ich daraus mitnehme

Die Lehre, die ich von Vogels behalte, ist, Ausfall als den Normalfall zu behandeln, nicht als die Ausnahme. Mein Instinkt ist, wie der der meisten Erbauer, den Pfad zu schreiben, in dem der Aufruf gelingt, die Abhängigkeit antwortet, die Festplatte da ist — und dann ein try/catch dranzuschrauben, sobald es funktioniert. „Everything fails all the time” ist die Zurechtweisung: Bei jeder echten Größenordnung ist der Ausfall kein seltenes Ereignis, das meinem System widerfährt, sondern ein Dauerzustand, in dem mein System lebt. Wenn ich also jetzt etwas baue — einen Sync-Job, einen API-Client, einen Queue-Consumer — versuche ich, von „was stirbt, und bedient der Rest weiter, wenn es das tut?” auszugehen, statt zuletzt dorthin zu gelangen. Die ehrliche Version von „es funktioniert” ist nicht die grüne Demo; sie besteht darin, eine Abhängigkeit mitten in einer Anfrage zu töten und zuzusehen, wie das System kontrolliert abschwächt, statt umzukippen. Ein System, das nur den Glücksfall überlebt, ist ein System, mit dessen Entwurf ich nicht fertig bin.

Die zweite Lehre ist, dass Verfügbarkeit und Konsistenz ein Kompromiss sind, den ich bewusst eingehen muss. Es ist verlockend, beides zu wollen — jeder Lesevorgang sieht jeden Schreibvorgang, und das System sagt nie nein — und für eine Einzelmaschine können Sie es haben. In dem Moment, in dem ich irgendetwas repliziere, ist dieser Komfort dahin, und Vogels’ Disziplin besteht darin, die Seite für jede Arbeitslast bewusst zu wählen, statt aus Gewohnheit überall auf die stärkste Garantie zurückzufallen. Das meiste, was ich baue, braucht nicht, dass ein Lesevorgang sofort den jüngsten Schreibvorgang widerspiegelt; es braucht, den Kunden nie abzuweisen. Eventual Consistency hat das für mich umgedeutet, von einem beängstigenden Kompromiss zu einem präzisen Werkzeug: genau benennen, wie veraltet ein Leser sein darf, mit dem Spielraum Verfügbarkeit erkaufen und aufhören, für eine Garantie zu bezahlen, die die Funktion nie brauchte. Die Fertigkeit besteht nicht darin, immer nach dem stärksten Versprechen zu greifen — sie besteht darin, zu wissen, welches Versprechen die Arbeit tatsächlich erfordert.

FAQ

Was bedeutet „everything fails all the time”?

Es ist Werner Vogels’ Verdichtung einer hart erkämpften Lehre über Größenordnung: Wenn Sie genügend Maschinen betreiben, hört der Ausfall von Komponenten auf, eine seltene Ausnahme zu sein, und wird zu einem dauerhaften, statistisch garantierten Zustand.⁶ Ein Ausfallmodus, der auf einem einzelnen Server selten genug ist, um ihn zu ignorieren, geschieht irgendwo in einer großen Flotte ständig. Die praktische Konsequenz ist die Umkehrung des normalen Engineerings: Statt zu versuchen, Ausfall zu verhindern, nehmen Sie an, dass jede Festplatte, jeder Server, jede Verbindung und jede Abhängigkeit ausfallen wird, und entwerfen Systeme, die durch den Ausfall hindurch verfügbar bleiben — durch Redundanz, Entkopplung und eingedämmten Schadensradius —, sodass jeder einzelne Fehler überlebbar und idealerweise unsichtbar ist.¹⁶

Was ist das Dynamo-Paper?

„Dynamo: Amazon’s Highly Available Key-value Store” ist ein SOSP-Paper von 2007, mitverfasst von Vogels, das das Speichersystem beschreibt, das Amazon baute, um Dienste wie den Warenkorb selbst während Ausfällen und Netzwerkpartitionen schreibbar zu halten.²³ Es kombinierte Consistent Hashing für die Partitionierung, Vector Clocks zum Verfolgen nebenläufiger Schreibvorgänge, Sloppy Quorums und hinweisbasierte Übergabe, um unter Ausfall verfügbar zu bleiben, Anti-Entropie mit Merkle-Bäumen zur Reparatur und Gossip für dezentrale Mitgliedschaft — alles im Dienst dessen, einen Schreibvorgang immer zu akzeptieren und später abzugleichen. Amazon hat den Code nie veröffentlicht, doch das Paper wurde grundlegend für die NoSQL-Bewegung und beeinflusste direkt Cassandra, Riak, Voldemort und Amazon DynamoDB.³

Was ist Eventual Consistency?

Eventual Consistency ist ein gelockertes Konsistenzmodell, das Vogels propagierte und in seinem Essay „Eventually Consistent” definierte: „Wenn keine neuen Aktualisierungen am Objekt vorgenommen werden, geben schließlich alle Zugriffe den zuletzt aktualisierten Wert zurück.”⁴ In einem replizierten System erreicht ein Schreibvorgang manche Replikate vor anderen, sodass für ein kurzes Zeitfenster verschiedene Replikate unterschiedliche Antworten liefern können — doch keines verweigert je eine Anfrage. Das System bleibt verfügbar und konvergiert im Hintergrund, statt zu blockieren, bis jedes Replikat übereinstimmt. Es ist die Verfügbarkeitsseite des CAP-Kompromisses: Wenn das Netzwerk partitioniert, kann ein System konsistent sein (die Antwort verweigern, bis alle übereinstimmen) oder verfügbar (mit dem antworten, was es hat, und später abgleichen), und Eventual Consistency wählt verfügbar.⁴⁷

Was bedeutet „you build it, you run it”?

„You build it, you run it” ist Vogels’ Beschreibung — aus einem Gespräch in der ACM Queue von 2006 — von Amazons Modell vollständiger Diensteigenverantwortung: Das Team, das einen Dienst baut, ist „vollständig für den Dienst verantwortlich — vom Abstecken der Funktionalität über das Entwerfen, das Bauen bis zum Betreiben.”⁵ Es gibt keine Mauer zwischen Entwicklung und Betrieb — die Ingenieure, die den Code schrieben, tragen für ihn den Pager. Vogels argumentierte, dies „bringt Entwickler in Kontakt mit dem täglichen Betrieb ihrer Software” und „in täglichen Kontakt mit dem Kunden”, und dass die daraus entstehende Rückkopplungsschleife die Qualität antreibt.⁵ Die Idee wurde zu einem der Gründungsprinzipien der modernen DevOps-Kultur.

Quellen