Albert Greenberg und das Netzwerk als verteilter Computer

Kernaussagen

• Greenbergs Laufbahn verbindet die Messung des Datenverkehrs in Telekommunikationsnetzen, hyperskalige Rechenzentrumsnetze und die Plattformarchitektur von Uber. In jeder Phase wird das Netzwerk als System behandelt, das als zusammenhängende Einheit gemessen und gesteuert werden muss.
• Die 4D-Architektur sowie VL2, DCTCP, Ananta, SWAN und Pingmesh adressierten unterschiedliche Schichten dieses Systems. Sie sind jedoch sämtlich Gemeinschaftsprojekte, deren Wirkung im Produktivbetrieb nicht einer einzelnen Person zugeschrieben werden kann.
• Bei Uber berichtete eine Failover-Studie aus dem Jahr 2026 von höherer Auslastung, nachdem ausgewählte Dienste von einer einheitlichen zweifachen Reserve auf eine differenzierte Planung um etwa das 1,3-Fache umgestellt worden waren; im untersuchten System blieb zugleich eine Verfügbarkeit von 99,97 % erhalten.
• Der langfristig wichtigste Test für Greenbergs Beitrag ist, ob die von ihm mitgeprägten Regelkreise neue Hardware, KI-Lasten, organisatorischen Wandel und Ausfälle überstehen können, ohne ihre Erklärbarkeit oder Rechenschaftsfähigkeit zu verlieren.

Ein Reserveziel von 1,3-facher Kapazität macht die Architektur sichtbar

Der sinnvollste Einstieg in die Laufbahn von Albert Greenberg ist weder eine Amtsbezeichnung noch eine Auszeichnung, sondern eine Kapazitätsentscheidung. Eine Arbeit von Uber auf der NSDI 2026 beschrieb ein System zur Failover-Planung, das ausgewählte Dienste von einem einheitlichen Reservemodell mit dem Faktor 2 auf eine differenzierte Planung um den Faktor 1,3 umstellte. Sie berichtete über eine höhere Auslastung bei zugleich 99,97 % Verfügbarkeit in dem untersuchten System. Das Ergebnis ist einem großen Autorenteam und der Produktivarchitektur von Uber zuzurechnen, nicht einer einzelnen Führungskraft.

Es legt jedoch die Frage offen, die Greenbergs Arbeit seit Jahrzehnten begleitet: Wie viel Reservekapazität, Steuerung und Messung braucht eine Plattform, bevor Zuverlässigkeit zu einer konstruierten Eigenschaft und nicht bloß zu einer Hoffnung wird?

Die Frage ist schwieriger, als die Kennzahl vermuten lässt. Reservekapazität schützt vor Ausfällen, verbraucht aber auch Kapital, Energie und Fläche. Eine Verringerung der Reserve funktioniert nur, wenn Dienste richtig klassifiziert, Abhängigkeiten verstanden, Failover-Pfade tatsächlich unabhängig sind und die Organisation erkennen kann, ob sich der Datenverkehr wie erwartet verlagert hat. Ein Kapazitätsziel ist daher nicht nur finanzielle Optimierung, sondern Ausdruck dessen, wie viel Vertrauen die Plattform in ihre Topologie, Telemetrie, Steuerungssoftware und betriebliche Disziplin setzt.

Greenbergs heutige Rolle bei Uber bringt ihn in die Nähe dieses Problems, doch die öffentliche Dokumentation nennt keinen einzigen unstrittigen Titel. Ein Profil der ARCS Foundation aus dem Jahr 2026 bezeichnet ihn als Senior Vice President and Chief Architect Officer, während eine Veranstaltungsbiografie der University of Minnesota ihn als Vice President of Platform Engineering führt. Beide Quellen sind institutionell belastbar genug, dass der Widerspruch sichtbar bleiben sollte, statt stillschweigend aufgelöst zu werden.

Wichtiger ist, dass beide Greenberg als hochrangigen Plattform- und Architekturverantwortlichen mit Zuständigkeit über die Infrastruktur hinweg beschreiben, nicht als Forscher an einem isolierten Protokoll.

Dieselbe Systemsicht zeigt sich schon viel früher in seiner Laufbahn. Bei AT&T und Bell Labs bestand das Problem darin, Nachfrage und Anomalien in einem Betreibernetz zu messen, dessen wesentlicher Zustand nicht an einem einzigen Zähler ablesbar war. Bei Microsoft lautete die Aufgabe, Rechenzentrums-Fabric, Transportprotokoll, Load Balancer, WAN und Telemetriesystem als Teile einer einzigen Cloud-Plattform zusammenwirken zu lassen. Bei Uber veränderte sich der betriebliche Kontext erneut – hin zu globalen Plattformdiensten, KI-Infrastruktur und differenzierter Resilienzplanung.

Die Technologien wechselten, die wiederkehrende Disziplin jedoch nicht: das Gesamtsystem beobachten, Steuerungsentscheidungen explizit machen, sie sicher einspielen und anschließend messen, ob die Realität dem Modell gefolgt ist.

Telekommunikationsnetze lehrten Greenberg, vor dem Steuern zu messen

Greenberg schloss 1983 seine Promotion in Informatik an der University of Washington ab, nachdem er am Dartmouth College Mathematik studiert hatte. Anschließend verbrachte er einen großen Teil seiner frühen Laufbahn in der Netzwerkforschung bei AT&T und Bell Labs. Entscheidend ist hier weniger die Abfolge der Titel als die Art des Systems, mit dem er konfrontiert war: ein aktives Backbone eines Telekommunikationsbetreibers mit Kunden, Protokollen, Störungen und Verkehrsmustern, das nicht angehalten werden konnte, während Forschende herauszufinden versuchten, was im Netz geschah.

Die Planung eines Backbones stützt sich auf Verkehrsmatrizen, Ausfallbelege und einen Überblick über die Nachfrage über zahlreiche Router hinweg. Link-Zähler zeigen die Last an einem Punkt, Routingtabellen die gewählten Pfade, und Flow-Datensätze liefern eine weitere partielle Sicht. Keines davon erklärt jedoch allein, wie viel Datenverkehr zwischen Eingangs- und Ausgangspunkten fließt oder wie eine Routingänderung diesen Fluss verändert. Teams bei AT&T entwickelten Mess- und Traffic-Engineering-Methoden, durch die sich das Backbone empirischer planen ließ.

Da die öffentliche Dokumentation nicht alle Produktivsysteme oder Datensätze offenlegt, bezieht sich die belastbare Aussage auf die ingenieurwissenschaftliche Methode, nicht auf eine vollständige Liste interner Werkzeuge.

Eine Verkehrsmatrix ist nützlich, weil sie eine große Menge verteilter Belege in ein Modell überführt, mit dem Kapazitätsplaner arbeiten können. Wenn der Datenverkehr zwischen zwei Teilen des Netzes wächst, kann der Betreiber fragen, ob die vorhandenen Pfade ausreichen, ob ein Ausfall einen Engpass erzeugen würde oder ob die Routingregel die Nachfrage auf ungeeignete Verbindungen lenkt. Die Schätzung bleibt unvollständig. Stichproben, Aggregation, Routingänderungen und verschlüsselte Anwendungen können die Interpretation verzerren.

Messungen müssen deshalb mit historischen Daten und betrieblichem Kontext verbunden werden, statt als absolute Wahrheit zu gelten.

Dieser Vorbehalt erklärt, warum Messung in Greenbergs späterer Arbeit mehr als eine Berichtsschicht wurde. Ein Steuerungssystem kann Pfade nicht optimieren, wenn ihm kein hinreichend verlässliches Modell von Topologie und Nachfrage vorliegt. Ein Load Balancer kann Anfragen nicht verteilen, wenn er die funktionierenden Backends und Pfade nicht kennt. Ein Failover-Planer kann die Reservekapazität nicht verringern, wenn Übungen und Telemetrie nicht zeigen, was beim Ausfall eines Standorts, einer Verbindung oder eines Dienstes geschieht.

Der wiederkehrende Regelkreis ist leicht zu beschreiben und schwer zu betreiben: beobachten, entscheiden, einspielen, messen und anschließend überarbeiten.

Die zeitlich dokumentierte Entwicklung stützt dieses Bild, ohne daraus eine Geschichte eines Einzelhelden zu machen. Greenberg promovierte 1983; 2005 erschien Clean Slate 4D Approach to Network Control and Management, 2009 folgte VL2, 2010 Rechenzentrum TCP, 2013 Ananta und SWAN sowie 2015 Pingmesh. Seine Arbeit bei AT&T und Bell Labs erstreckte sich von den 1980er-Jahren bis in die frühen 2000er-Jahre. Microsoft und Azure wurden vom Ende der 2000er-Jahre an zum wichtigsten institutionellen Umfeld, Uber in den 2020er-Jahren zum aktuellen Kontext. Jede Phase brachte neue Mitwirkende und neue Bedingungen des Produktivbetriebs mit sich.

Die Kontinuität liegt daher im Systemproblem, nicht in der Behauptung, eine einzelne Person habe einen fertigen Bauplan von Unternehmen zu Unternehmen getragen.

Die 4D-Architektur trennte Entscheidungslogik von Weiterleitung

Die 4D-Architektur, die Mitte der 2000er-Jahre mit Mitwirkenden entwickelt und veröffentlicht wurde, stellte einen vertrauten Aspekt routerzentrierter Netzverwaltung infrage: Jedes Gerät vereinte lokale Konfiguration, verteilte Protokolle und Weiterleitungsverhalten, wodurch sich Regeln und Ausfälle auf Ebene des gesamten Netzes nur schwer durchdenken ließen. Der Ansatz teilte die Steuerung in vier Ebenen: Decision, Dissemination, Discovery und Data.

Discovery sammelt Informationen zu Topologie und Zustand, Decision berechnet netzwerkweite Regeln und Steuerungsentscheidungen, Dissemination verteilt den resultierenden Zustand, während die Data Plane die Weiterleitung ausführt.

Der wichtigste Wandel lag in dieser Trennung selbst. Sobald die Regellogik eine eigenständige logische Funktion war, ließ sich über einen Controller mit netzwerkweiter Sicht nachdenken, ohne die Weiterleitung physisch zu zentralisieren. Regeln konnten anhand eines umfassenderen Modells geprüft und der daraus entstehende Zustand anschließend kontrolliert verteilt werden. Die Architektur nahm Ideen vorweg, die später mit Software-defined Networking verbunden wurden. Sie sollte jedoch nicht als alleiniger Ursprung von SDN beschrieben werden.

Das Fachgebiet besitzt mehrere gedankliche Entwicklungslinien; die Belege tragen die Einordnung von 4D als Vorläufer und einflussreichen Beitrag, nicht als Einzelerfindung.

Die Trennung der Steuerung isoliert Risiken und verlagert sie zugleich. Ein Decision-Dienst kann ausfallen oder auf veralteten Discovery-Daten beruhen. Dissemination kann eine Änderung nur teilweise einspielen. Ein logisch zentraler Regelmechanismus kann eine falsche Entscheidung schneller verbreiten als viele schwach koordinierte Router. Während des Übergangs müssen zudem ältere Protokolle und Geräte weiterbestehen. 4D beseitigte die Komplexität daher nicht, sondern machte Teile davon sichtbarer und konzentrierte einen Teil der Verantwortung in Software und Betriebsprozessen.

Dieser Zielkonflikt wurde für spätere Cloud-Systeme zentral. Die Frage war nicht länger, ob sich Netzwerklogik von der Weiterleitung trennen lässt, sondern wie diese Logik hochverfügbar, redundant, beobachtbar und mit verteilten Datenpfaden vereinbar gemacht werden kann. Stufenweise Einführungen, Rollbacks, Zustandsprüfungen und die Fortsetzung lokaler Weiterleitung werden wichtig, weil die umfassendere Sicht des Controllers mit einem größeren Auswirkungsradius einhergeht. Greenbergs spätere Arbeit bei Microsoft behandelte diese Fragen anhand konkreter Systeme statt durch eine einzige globale Steuerungsebene.

VL2 machte die Platzierung von Diensten zu einer Frage des Netzwerkdesigns

Als Greenberg tief in Microsofts Arbeit an Rechenzentrumsnetzen einstieg, veränderten sich Größenordnung und Ausfallmodell. Große Internetdienste wollten Workloads verschieben oder neu verteilen, ohne das Netz um jeden Serverstandort herum neu zu entwerfen. Traditionelle hierarchische Netze konnten zugleich die Bandbreite begrenzen und Adressen eng an physische Standorte binden. VL2, von einem großen Team bei Microsoft entwickelt, kombinierte eine Folded-Clos-Fabric mit Adressindirektion und Valiant Load Balancing, um die Platzierung von Diensten und schwer vorhersehbare Verkehrsmuster zu unterstützen.

Das Ziel auf Dienstebene ist der nützliche Kern der Idee. Workloads sollten stabile Dienstidentitäten behalten können, während die physische Fabric darunter eine skalierbare Layer-3-Struktur nutzt. Verzeichnis- und Steuerungsmechanismen können Dienstadressen Standorten zuordnen, während eine Multipath-Clos-Topologie zahlreiche Pfade durch das Rechenzentrum bereitstellt. Das Netzwerk wird so von einer Menge fester Korridore zu einer Fabric, deren Kapazität bei der Verlagerung von Diensten flexibler genutzt werden kann.

Valiant Load Balancing ergänzt einen zunächst kontraintuitiven Mechanismus. Statt für jede Verkehrsmatrix den besten Ende-zu-Ende-Pfad vorhersagen zu wollen, lässt sich der Datenverkehr über annähernd zufällig ausgewählte Zwischenpunkte verteilen, damit unbekannte Nachfrage nicht dieselbe Gruppe von Verbindungen dominiert. Ein einzelner Datenfluss kann dadurch einen scheinbar längeren Weg nehmen, doch das Verhalten des gesamten Netzes wird unter unterschiedlichen Lasten besser vorhersehbar. Grenzen bestehen weiterhin, darunter zusätzliche Pfadlänge, unausgewogene Hash-Verteilung, sehr große Datenflüsse und Ausfälle.

Die Wirkung von VL2 sollte als Entwicklungslinie des Designs und nicht als unveränderte Blaupause für den Produktivbetrieb beschrieben werden. Azure übernahm die Forschungsarbeit nicht unverändert als endgültige Architektur. Hardwaregenerationen, virtuelle Vernetzung, Hostsoftware, Steuerungssysteme und betriebliche Anforderungen entwickelten sich weiter. Die stärkere Aussage lautet, dass VL2 ein Vokabular festigen half, das für hyperskalige Vernetzung zentral wurde: Clos-Fabrics, die Trennung von Adresse und Standort, Multipath-Nutzung und softwaregestützte Steuerung.

Auch die wirtschaftlichen Folgen entsprechen der Architektur. Einheitliche Fabrics aus handelsüblichen oder modularen Switches können eine schrittweisere Erweiterung ermöglichen als Entwürfe, die von wenigen großen Chassis abhängen. Eine geringere Abhängigkeit von einem einzelnen Gerät beseitigt die Kosten jedoch nicht. Sie verlagert Ausgaben und Fachwissen in Steuerungssoftware, Telemetrie, Automatisierung und Ausfallmanagement. Ein Cloud-Anbieter kann in einer Schicht nur sparen, wenn er das verteilte System, das sie ersetzt, besser betreiben kann.

DCTCP machte Überlastung zum gemeinsamen Problem von Switch und Host

Der Datenverkehr in einem Rechenzentrum mischt kurze, latenzkritische Datenflüsse mit großen Übertragungen. Herkömmliches TCP kann tiefe Warteschlangen aufbauen, bevor es das Sendefenster verkleinert. Dadurch kann die Verbindung stark ausgelastet sein, während kurze Aufgaben hinter angesammelten Paketen warten. DCTCP, ebenfalls eine Gemeinschaftsarbeit, nutzte Explicit Congestion Notification bei geringer Warteschlangentiefe in Switches und passte den Sender anhand des Anteils markierter Pakete an. Ziel war es, die Warteschlangen klein zu halten, ohne den Durchsatz zu opfern.

Das wichtigste Ergebnis ist, dass Überlastungssteuerung zu einem koordinierten Regelkreis zwischen Netzwerkgeräten und Endpunkten wird. Switches benötigen für die jeweilige Einführung passende Markierungsschwellenwerte, Hosts ein kompatibles Verhalten der Überlastungssteuerung. Verkehrsmischung, Topologie und Hardware beeinflussen das Ergebnis. Ein ungeeigneter Schwellenwert oder eine gemischte Einführung kann Fairness und Latenz verändern. DCTCP ist deshalb nicht bloß ein Algorithmus, den ein einzelner Server aktiviert.

Die Arbeit trug dazu bei, Überlastung in Rechenzentren als eigenständiges Betriebsproblem zu etablieren. Das öffentliche Internet besteht aus langen Pfaden, verschiedenen Betreibern und Endpunkten ohne einheitliche Zuständigkeit. Ein Cloud-Anbieter kann Server und Switches dagegen meist gemeinsam kontrollieren. Dieser administrative Zuständigkeitsbereich schafft Raum für Mechanismen, die global nur schwer zu koordinieren wären. Zugleich entstehen Verpflichtungen für die Plattform: Versionen der Endpunkte, Einstellungen der Switches und Telemetrie müssen sich gemeinsam entwickeln, sonst driftet der Regelkreis auseinander.

Die Grenzen bleiben wichtig, weil spätere Systeme dasselbe Ziel verfolgen oder erweitern. Neue Verfahren zur Überlastungssteuerung, schnellere Fabrics und andere Pufferarchitekturen ändern nichts an der Grundfrage: Wo entstehen Warteschlangen, wie erfahren Endpunkte davon und welches Team verantwortet die Konfiguration? Greenbergs Beitrag gehört zu einem Forschungs- und Entwicklungsportfolio, das solche schichtübergreifenden Abhängigkeiten wiederholt als das eigentliche Problem behandelte.

Ananta, SWAN und Pingmesh schlossen unterschiedliche Teile des Regelkreises

Topologie und Transport waren nur ein Teil des Problems der Cloud-Vernetzung. Dienste benötigten skalierbaren Ingress, Rechenzentren mussten Weitverkehrskapazität teilen, und Betreiber brauchten genügend Belege, um Netzwerkfehler von Anwendungssymptomen zu unterscheiden. Teams bei Microsoft behandelten diese Fragen mit Systemen wie Ananta, SWAN und Pingmesh. Jedes davon besitzt ein eigenes Autorenteam und eigene Grenzen des Einsatzes.

Ananta adressierte Layer-4-Load-Balancing im Cloud-Maßstab. Statt die Paketverarbeitung in einer einzelnen Appliance zu konzentrieren, verteilte die Architektur Paketverarbeitung, Routenverwaltung und Dienststeuerung auf zahlreiche Maschinen. Der Datenpfad kann dadurch horizontal skalieren, doch es entstehen neue Anforderungen an Zustand, Konsistenz, die Funktionsfähigkeit der Backends und den Umgang mit Ausfällen. Der Load Balancer wird von einem Gerät am Netzrand zu einem Infrastrukturdienst.

SWAN wandte logisch zentrale Optimierung auf das WAN an. Verbindungen zwischen Rechenzentren sind teuer, die Nachfrage verändert sich, und Ausfälle können Kapazität plötzlich entfernen. Ein Controller mit umfassender Sicht kann Pfade anhand von Dienstpriorität und Netzzustand zuweisen, Datenverkehr von Überlastungen weglenken und knappe Fernverbindungen gezielter nutzen. Dieselbe zentrale Sicht erzeugt Risiken, wenn Nachfrageschätzungen falsch, Aktualisierungen unsicher oder Teile des Netzes für den Controller nicht erreichbar sind.

Pingmesh griff ein anderes Problem an: Sichtbarkeit. Das System setzte Agenten ein und sammelte Latenz- und Paketverlustmessungen über eine große Serverflotte hinweg. So entstand ein kontinuierliches Netz synthetischer Belege. Eine Verbindung kann laut Verwaltung aktiv sein, obwohl ein Pfad schlecht funktioniert; ein Dienst kann wegen eines Netzwerksegments ausfallen, das keinem einzelnen Team eindeutig gehört. Messungen über die gesamte Flotte geben Betreibern für solche Störungen eine gemeinsame Ausgangsbasis, auch wenn synthetische Prüfungen nicht jeden Anwendungspfad, jede Warteschlange oder jede Abhängigkeit abbilden.

Die drei Systeme sind besonders aufschlussreich, wenn sie gemeinsam betrachtet werden. Sie zeigen, warum Greenbergs Bilanz nicht auf eine bekannte Topologiearbeit reduziert werden kann. Ananta ordnet Dienstdatenverkehr Ressourcen zu, SWAN weist WAN-Kapazität zu, und Pingmesh misst, ob sich Pfade wie erwartet verhalten. DCTCP steuert die Rückmeldung aus Warteschlangen innerhalb der Fabric, während VL2 ein Modell für die Struktur dieser Fabric liefert. Zuverlässigkeit entsteht aus dem Zusammenspiel dieser Mechanismen. Deshalb muss auch die Zuschreibung auf die Teams ausgerichtet bleiben.

Azure Networking wurde zum Betriebssystem rund um diese Mechanismen

Als Greenberg große Führungsrollen bei Azure Networking innehatte, bestand die zentrale Herausforderung nicht mehr darin, ob eine einzelne Arbeit in einem bestimmten Experiment funktionierte. Azure musste physische Fabrics, virtuelle Netze, Load Balancer, Gateways, WAN, Telemetrie und Bereitstellungssysteme als einen einzigen Cloud-Dienst betreiben. Kunden erwarteten Isolation, Programmierbarkeit und Verfügbarkeit, ohne die darunterliegende Hardware oder die Steuerungsprozesse verstehen zu müssen.

Virtuelle Vernetzung macht diese Abstraktion greifbar. Der Kunde sieht Adressen, Routen, Sicherheitsregeln und Dienstendpunkte, während die Cloud diese Absicht in Hosts, Switches und Gateways übersetzt, die von mehreren Mandanten gemeinsam genutzt werden. Die Steuerungsebene muss schnelle Veränderungen bewältigen, ohne zuzulassen, dass die Konfiguration eines Kunden einen anderen beeinträchtigt. Die Datenebene muss weiter mit hoher Geschwindigkeit weiterleiten.

Gleichzeitig machen APIs, Prüfprotokolle, Rollback-Mechanismen und regionale Konsistenz das Netzwerk ebenso zu einem Problem des Softwarelebenszyklus wie zu einem Problem der Paketweiterleitung.

Dieser Lebenszyklus verändert die Bedeutung von Architektur. Eine Funktionsfreigabe kann das Routing- oder Sicherheitsverhalten für viele Kunden ändern. Ein Ausfall der Steuerungsebene kann neue Konfigurationen verhindern, während bestehende Datenflüsse weiterlaufen. Eine Telemetrielücke kann die Infrastruktur gesund erscheinen lassen, obwohl Nutzer einen Ausfall erleben. Kapazitätsplaner müssen normales Wachstum und regionalen Failover zugleich berücksichtigen. Die Entwicklungsorganisation wird damit Teil des Dienstversprechens, weil Kunden den größten Teil des verborgenen Systems weder sehen noch selbst reparieren können.

Die SIGCOMM-Keynote von 2015 ist in diesem Zusammenhang wichtig, weil sie Cloud-Vernetzung als Portfolio miteinander verbundener Systeme darstellte und nicht als Suche nach einer einzigen endgültigen Fabric. Topologie, Transport, Virtualisierung, Load Balancing, WAN-Traffic-Engineering, Überwachung und Betrieb müssen zusammenpassen, während sich die Plattform unter ihnen verändert. Diese Rahmung ist dauerhafter als ein einzelnes Implementierungsdetail und entspricht Greenbergs Arbeit über mehrere Teams hinweg.

Seine formale Autorität bei Microsoft stützt die Aussage über Führungsverantwortung, belegt aber keinen persönlichen Alleinbesitz der Technologie. Öffentliche Unterlagen bezeichnen ihn als Corporate Vice President und Technical Fellow bei Azure Networking. Historische Materialien von AT&T nennen je nach Zeitraum hochrangige Rollen, darunter executive director und AT&T Fellow. Die mit diesen Institutionen verbundenen Kernsysteme haben lange Listen von Mitautoren und Produktionsingenieuren.

Die belastbarste Zuschreibung erfolgt daher projektweise: die Gemeinschaftsarbeit benennen, den Arbeitgeber als Institution des Produktivbetriebs bestimmen und persönliche Aussagen auf dokumentierte Beiträge und architektonische Führung begrenzen.

Führung wirkt über Teams, nicht über eine einzelne Erfindung

Greenbergs Laufbahn lädt zu einer Verkürzung ein, die Systemgeschichte leicht in die Geschichte eines Einzelhelden verwandelt. Die sicherere Darstellung ist interessanter. VL2, DCTCP, Ananta, SWAN, Pingmesh und die Failover-Arbeit bei Uber wurden von Teams entwickelt. Die 4D-Architektur entstand aus einer Forschungsgemeinschaft mit mehreren Mitwirkenden. Auch Azure Networking entwickelte sich über Jahre durch Produkt- und Betriebsarbeit, die weder eine einzelne Veröffentlichung noch eine Biografie einer Führungskraft zusammenfassen kann.

Die öffentliche Dokumentation belegt dennoch eine ungewöhnliche Kontinuität zwischen diesen Teams. Greenberg ging von der Messung von Betreibernetzen zu einer grundlegend neu gedachten Steuerungsarchitektur über, von hyperskaligen Rechenzentrumsnetzen zur Führung einer Cloud-Plattform und anschließend zur Plattformorganisation von Uber. Seine Wirkung ist deshalb technisch und organisatorisch zugleich: Er erscheint wiederholt in Arbeiten, die fragen, wie netzwerkweiter Zustand gemessen werden sollte, wo Steuerung liegen muss, wie Datenverkehr zugewiesen werden sollte und wie Teams mit Ausfällen umgehen.

Auszeichnungen spiegeln diese Breite wider, sollten aber Projektbelege nicht ersetzen. Greenberg erhielt den ACM SIGCOMM Award und 2015 den IEEE Koji Kobayashi Computers and Communications Award. 2016 wurde er in die US National Academy of Engineering gewählt; außerdem ist er ACM Fellow. Diese Auszeichnungen stützen den Schluss, dass das Fachgebiet seine Arbeit als einflussreich betrachtet. Sie belegen jedoch weder eine alleinige Erfindung noch aktuelle betriebliche Entscheidungsgewalt oder die genaue Produktiventwicklung eines bestimmten Systems.

Der Widerspruch um Greenbergs Titel bei Uber ist eine nützliche Erinnerung an dieselbe Disziplin. Ein Profil der ARCS Foundation aus dem Jahr 2026 bezeichnet ihn als Senior Vice President and Chief Architect Officer. Materialien der University of Minnesota aus dem Zeitraum 2025 bis 2026 führen ihn dagegen als Vice President of Platform Engineering.

Statt eine Variante auszuwählen und die Dokumentation geordneter erscheinen zu lassen, als sie ist, sollten die Quellen datiert und die gemeinsamen Aussagen beschrieben werden: Greenberg hat eine hochrangige Plattform- und Architekturrolle, während seine internen Entscheidungsrechte nicht vollständig öffentlich sind. Die aktuelle Personalbezeichnung bleibt ein Punkt, der überprüft werden muss, und kein Grund, die breiteren Belege zu seinen Zuständigkeiten abzuwerten.

Das ist wichtig, weil Architektur teilweise eine Verteilung von Autorität ist. Ein Chief Architect oder eine Plattformführungskraft kann gemeinsame Grundsätze festlegen, Prüfungen verlangen, gemeinsame Mechanismen genehmigen oder die Kapazitätspolitik beeinflussen. Die Person steuert jedoch nicht jeden Switch persönlich und schreibt nicht jeden Steuerungsdienst. Netzwerkteams, Dienstteams, Sicherheitsingenieure, Kapazitätsplaner, Finanzfunktionen und Führungskräfte behalten getrennte Entscheidungsrechte.

Der Wert architektonischer Führung liegt darin, diese Rechte an einem gemeinsamen Ausfallmodell auszurichten, nicht darin, so zu tun, als würden sie alle in einer Person zusammenlaufen.

Uber wendet dieselbe Disziplin auf ein anderes Nachfragemuster an

Die Infrastruktur von Uber bedient Mobilitäts-, Liefer- und andere Dienste, deren Nutzungsverkehr und Rechenbedarf je nach Region und Tageszeit stark schwanken. Offizielle Biografien verknüpfen Greenbergs Zuständigkeiten mit Rechenzentren, Rechenleistung, Vernetzung, Speicher, Daten, Suche, Überwachung, Entwicklerproduktivität, Unternehmens-IT und Infrastruktur für KI und autonome Fahrzeuge. Diese Breite belegt den Plattformkontext. Sie beweist jedoch nicht, dass er jedes genannte System oder ein darauf aufbauendes Anwendungsmodell persönlich entworfen hat.

Das Betriebsproblem unterscheidet sich von einer öffentlichen Cloud, weil Uber sein eigenes Anwendungsportfolio kontrolliert und zugleich globale Echtzeitdienste sowie große interne Datensysteme betreibt. Entscheidungen zu Netzwerk, Speicher und Rechenleistung wirken mit Dienstzuverlässigkeit, Workloads des maschinellen Lernens und regionalem Betrieb zusammen. Die Plattformarchitektur muss deshalb festlegen, welche Infrastruktur gemeinsam genutzt wird, welche Ausfallbereiche tatsächlich als unabhängig gelten können und wie Anwendungsteams gemeinsame Dienste nutzen, ohne dass jedes Team dieselben Mechanismen neu entwickelt.

Die Failover-Studie von 2026 macht dieses Problem messbar. Die Umstellung ausgewählter Dienste von einheitlicher zweifacher Kapazität auf differenzierte Planung um den Faktor 1,3 kann Infrastruktur nur dann freisetzen, wenn das Modell hinter der Entscheidung richtig ist. Die Verfügbarkeit von 99,97 % gilt für das genannte System und den untersuchten Zeitraum bei Uber. Sie sollte weder auf sämtliche Uber-Dienste noch auf andere Unternehmen verallgemeinert werden.

Der Wert des Ergebnisses liegt darin, den gesteuerten Zielkonflikt sichtbar zu machen: Eine geringere Reservekapazität kann die Auslastung verbessern, verlangt dafür aber eine bessere Klassifizierung, genauere Abhängigkeitskarten, verlässlichere Telemetrie und wiederholte Übungen.

Dies ist ebenso ein wirtschaftlicher wie ein technischer Regelkreis. Reservemaschinen, Netzwerkpfade, Energie und Rechenzentrumskapazität verursachen Opportunitätskosten. Eine Plattform, die Dienste nach ihren Ausfallanforderungen unterscheiden kann, benötigt möglicherweise weniger ungenutzte Reserve als eine Plattform, die jeden Workload gleich behandelt. Die Gewinne sind nicht real, wenn ein Ausfall eine verborgene Kopplung zwischen Zonen oder Diensten offenlegt, die als unabhängig galten. Tests und das Lernen aus Störungen werden deshalb Teil derselben wirtschaftlichen Begründung.

Heutige KI- und autonome Fahrzeug-Workloads verschärfen diese Entscheidungen. Training und Inferenz können große Ost-West-Datenströme erzeugen, die Platzierung von Beschleunigern belasten und die Leistung am langen Ende der Latenzverteilung empfindlicher machen. Fahrzeug- und Mobilitätsdaten bringen zusätzliche Anforderungen an Speicherung, Übertragung und regionale Verarbeitung mit sich. Die verfügbaren Biografien machen diese Bereiche für Greenbergs Plattformrolle relevant. Sie tragen jedoch nicht die Behauptung, er entwerfe KI-Modelle oder Software für autonomes Fahren.

Die engere Aussage ist belastbarer: Die Plattform muss die Daten, von denen diese Anwendungen abhängen, übertragen, schützen und wiederherstellen.

Zuverlässigkeit ist eine Zuteilungsentscheidung, kein Attribut

Cloud- und Plattformorganisationen beschreiben ihre Systeme gewöhnlich als resilient, hochverfügbar oder fehlertolerant. Diese Eigenschaften verbergen jedoch Zuteilungen von Kapazität, geografischer Verteilung, Softwarekomplexität und Arbeitszeit. Eine Netzwerk-Fabric besitzt ein bestimmtes Maß an Pfadvielfalt; ein WAN verfügt über eine bestimmte Reservekapazität; ein Load Balancer hat einen festgelegten Zustand und ein bestimmtes Ausfallmodell; ein Telemetriesystem überwacht einige Pfade und andere nicht. Zuverlässigkeit ist das Ergebnis dieser Entscheidungen und keine Eigenschaft, die eine Formulierung in einem Entwurfsdokument verleiht.

Zentrale oder logisch zentrale Steuerung kann diese Zuteilungen verbessern, weil sie aus einer breiten Perspektive entscheiden kann. SWAN kann WAN-Kapazität gezielter koordinieren als voneinander unabhängige lokale Entscheidungen. Ein Controller für virtuelle Netze kann über zahlreiche Hosts hinweg einheitliche Regeln durchsetzen. Die Kehrseite ist Konzentration. Eine falsche Regel, ein beschädigter Zustand oder eine fehlerhafte Einführung kann schnell einen größeren Teil des Netzes betreffen.

Zentralisierung überzeugt deshalb nur mit Replikation, stufenweiser Bereitstellung, Rollback und der Fähigkeit lokaler Weiterleitung, bestimmte Unterbrechungen der Steuerung zu überstehen.

Dasselbe Prinzip gilt für Kapazität. Eine einheitliche zweifache Reserve lässt sich einfach erklären, kann aber teuer sein. Eine differenzierte Reserve kann die Auslastung verbessern, erhöht jedoch die Abhängigkeit von korrekter Dienstklassifizierung und Ausfallmodellierung. Keiner der Werte ist von sich aus vernünftig. Die Wahl hängt davon ab, was gemeinsam ausfällt, wie schnell Datenverkehr verlagert werden kann, welche Dienste eine Verschlechterung tolerieren und wie viel Unsicherheit die Organisation zu finanzieren bereit ist.

Damit wird eine Architekturprüfung ebenso zu einer Verteilung von Macht wie zu einer technischen Auswahl. Dienstteams beschreiben ihren Latenz- und Verfügbarkeitsbedarf. Netzwerk- und Plattformteams wählen gemeinsame Mechanismen. Kapazitätsplaner und Finanzverantwortliche bestimmen die finanzierte Reserve. Sicherheitsteams legen Isolationsanforderungen fest. Führungskräfte bestimmen die Risikotoleranz. Ein Architekt kann eine gemeinsame Begriffsbasis schaffen und verlangen, dass lokale Entwürfe zu einem kohärenten Modell passen. Er kann jedoch die getrennten Anreize und Verantwortlichkeiten, die das Produktivsystem prägen, nicht beseitigen.

Greenbergs Arbeit liefert einen nützlichen Test für solche Prüfungen: Schließt der Entwurf den Regelkreis zwischen Nachfrage, Entscheidung, Weiterleitung und Belegen? VL2 behandelte Platzierung und Topologie. DCTCP behandelte die Rückmeldung aus Warteschlangen. Ananta und SWAN wiesen Datenverkehr zu. Pingmesh lieferte kontinuierliche Beobachtung. Azure und Uber verwandelten solche Mechanismen in organisatorische Systeme. Das Netzwerk verhält sich nur dann wie ein verteilter Computer, wenn diese Regelkreise während Veränderungen kohärent bleiben.

Das Portfolio ist breiter als die bekannteste Einordnung

Greenberg wird besonders stark mit Rechenzentrumsnetzen verbunden. Die Dokumentation erstreckt sich jedoch über mehrere Arten von Arbeit, die nicht in eine einzige Kategorie gepresst werden sollten. Die Messung des Datenverkehrs in Betreibernetzen machte Nachfrage und Anomalien für Betreiber sichtbar. Die 4D-Architektur trennte Steuerungsfunktionen auf konzeptioneller Ebene. VL2 behandelte Fabric-Topologie und Dienstplatzierung. DCTCP steuerte Warteschlangen durch Rückmeldungen zwischen Endpunkt und Switch.

Ananta adressierte den Eingang von Diensten, SWAN die Weitverkehrszuweisung und Pingmesh die Beobachtbarkeit über eine Serverflotte hinweg. Azure Virtual Networking brachte mehrere dieser Ideen anschließend in eine kundenorientierte Cloud-Plattform ein.

Jede Schicht hat andere Nutzer und andere Belege. Die Messung in Betreibernetzen dient vor allem Betreibern und Planern, während ein großer Teil der Produktivdetails proprietär bleibt. Die 4D-Architektur ist ein Forschungsentwurf, dessen Wirkung stärker konzeptionell ist als ein Beleg für eine einzige weltweite Einführung. Für VL2 und DCTCP gibt es veröffentlichte Mechanismen und öffentliche Auswertungen, doch die nachfolgenden Produktivsysteme entwickelten sich innerhalb von Microsoft weiter. Ananta, SWAN und Pingmesh wiederum beschreiben Plattformdienste mit unterschiedlichen Teams, Abhängigkeiten und Grenzen.

Der gemeinsame Faden ist kein einzelnes Produkt, sondern eine Reihe von Mechanismen, die verschiedene Entscheidungen explizit machen. Datenverkehrsmessung schätzt die Nachfrage. Die Steuerungsarchitektur bestimmt, wo Regellogik liegt. Die Fabric stellt Pfade bereit. Die Überlastungssteuerung regelt, wie Endpunkte sie nutzen. Load Balancing ordnet Dienstdatenverkehr Ressourcen zu. WAN-Engineering weist knappe Kapazität zwischen Standorten zu. Telemetrie zeigt, ob das Ergebnis den Erwartungen entspricht. Eine Führungsrolle in der Architektur koordiniert anschließend die Organisationen, die diese Regelkreise aufrechterhalten.

Diese Unterscheidung ist nützlich, wenn Greenbergs Arbeit mit benachbarten Systemen verglichen wird. VL2 gehört zu einer Entwicklungslinie mit Clos-Fabrics, PortLand, SEATTLE, Google Jupiter und anderen Architekturen für Rechenzentren. DCTCP gehört zur Forschung zur Überlastungssteuerung. SWAN gehört zum Traffic Engineering im Weitverkehr, Pingmesh zur Beobachtbarkeit. Software-defined Networking und OpenFlow bilden eine parallele Entwicklungslinie programmierbarer Steuerung. Kommerzielle Load Balancer und Produkte zur Netzwerkbeobachtung können verwandte Probleme mit anderen Produkt- und Betriebsmodellen lösen.

Der Zweck dieses Vergleichs ist weder eine Rangliste von Personen noch die Erklärung einer Architektur zum Sieger. Google Jupiter und B4, Rechenzentrums-Fabrics von Meta, kommerzielle Clos- und Leaf-Spine-Produkte, SDN-Arbeiten der OpenFlow-Ära, Appliance- oder verwaltete Load Balancer und Anbieter von Netzwerkbeobachtung lösen überlappende Steuerungsprobleme innerhalb unterschiedlicher institutioneller Grenzen. Eine Hersteller-Appliance kann eine Betriebsaufgabe vereinfachen, indem sie Verantwortung in einem Produkt bündelt. Eine Cloud-Plattform kann mehr Schichten integrieren, weil sie Hosts, Switches und Software kontrolliert.

Eine Forschungsarchitektur kann eine nützliche Abstraktion offenlegen, ohne zu belegen, dass die zu ihrem Betrieb notwendige Organisation leicht aufzubauen ist.

Die Systeme verbinden Forschungsgruppen, Anbieter und Betreiber

Greenbergs Arbeit liegt in einem Netz von Institutionen und nicht innerhalb einer einzigen, durchgehend bestehenden Organisation. AT&T Labs stellte das Umfeld der Betreiberforschung bereit, in dem Datenverkehrsmessung und Netzwerkverwaltung zu zentralen Fragen wurden. Microsoft Research und Azure verbanden Forschung an Rechenzentren mit hyperskaligem Produktivbetrieb. Uber liefert den heutigen Plattformkontext. Dartmouth College und University of Washington gehören zu seiner akademischen Ausbildung, während ACM SIGCOMM, IEEE und National Academy of Engineering einen Teil der beruflichen Anerkennung repräsentieren.

Diese Beziehungen bedeuten jedoch nicht dasselbe. Ein Beschäftigungsverhältnis bestimmt den institutionellen Kontext, belegt aber keinen persönlichen Besitz der Architektur. Mitautorenschaft belegt die Beteiligung an einem Forschungsergebnis, gewährt jedoch keine alleinige Kontrolle über die Produktivimplementierung. Eine Auszeichnung belegt Anerkennung durch Fachkollegen, beschreibt aber nicht den aktuellen Zustand eines Systems. Ein Konferenzvortrag kann den Einfluss einer Architekturgemeinschaft und den Austausch von Wissen zeigen, ohne eine kommerzielle Beziehung zu belegen.

Die Unterscheidung ist für hyperskalige Infrastruktur besonders wichtig, weil viele Produktivdetails nicht öffentlich bleiben. Veröffentlichungen legen Mechanismen, Annahmen und ausgewählte Messungen offen. Ein Cloud-Anbieter kann Hardware, Steuerungssoftware und Betriebspraktiken nach der Veröffentlichung jedoch verändern. Eine Arbeit kann deshalb belegen, was ein Team zu einem bestimmten Zeitpunkt entwickelt und ausgewertet hat, ohne eine vollständige Beschreibung des heutigen Netzes von Azure oder Uber zu sein.

Dieselbe Vorsicht gilt für Beschreibungen aktueller Rollen. Ein hochrangiger Titel weist auf formale Autorität hin, doch interne Entscheidungsrechte sind selten öffentlich. Architekturgemeinschaften, Entwurfsprüfungen und Plattformorganisationen können beträchtliche informelle Autorität schaffen, indem sie Schnittstellen, Ausfallmodelle oder Bereitstellungsverfahren festlegen, die zur allgemeinen Praxis werden. Die Belege stützen Greenberg als Führungskraft innerhalb solcher Mechanismen. Sie legen jedoch nicht jedes Vetorecht, jede Berichtslinie oder jede Budgetentscheidung offen, die ihm zur Verfügung steht.

Das stärkste Profil ist deshalb eines, das die Mitwirkenden sichtbar hält. Die Mitautoren von VL2, DCTCP, Ananta, SWAN, Pingmesh und der Uber-Failover-Arbeit sollten Teil der technischen Geschichte bleiben, während die Arbeitgeber zur Geschichte des Produktivbetriebs gehören. Greenbergs persönliche Bedeutung ergibt sich aus der Kontinuität der architektonischen Fragen in diesen Kontexten und nicht aus dem Ausblenden der Teams, die sie beantworteten.

Finanzierung und Geografie begrenzen die belastbaren Aussagen

Greenbergs Arbeit wurde weitgehend durch die Forschungs- und Entwicklungsorganisationen der Unternehmen finanziert, bei denen er beschäftigt war. Die verfügbaren Unterlagen belegen weder ein persönliches Erlösmodell noch eine Schätzung seiner Beteiligungen, seines Vermögens oder einen geprüften finanziellen Beitrag auf Produktebene. Hohe Titel und einflussreiche Systeme bieten keine Grundlage, um seine Vergütung zu schätzen oder Umsätze von Azure oder Uber einem einzelnen Architekten zuzurechnen.

Veröffentlichungen zu Produktivsystemen können über Effizienz- oder Verfügbarkeitswerte berichten; die Uber-Failover-Studie ist ein Beispiel. Diese Kennzahlen gehören zum genannten System und Autorenteam und beruhen auf den Annahmen der jeweiligen Architektur und des jeweiligen Zeitraums. Ohne finanzielle Offenlegung sollten daraus weder unternehmensweite Einsparungen noch Aussagen über Greenbergs persönliche Leistung abgeleitet werden. Zitationen und Auszeichnungen messen Anerkennung, nicht Umsatz.

Geografisch liegen Greenbergs Ausbildung und seine wichtigsten Arbeitgeber in den Vereinigten Staaten, während sich die betroffene Infrastruktur weltweit erstreckt. Die Backbone-Forschung von AT&T, Azure-Regionen und das Dienstgebiet von Uber unterliegen unterschiedlichen Kapazitäts-, Regulierungs- und Ausfallbedingungen. Ein Designprinzip, das in mehreren Kontexten funktioniert, bedeutet nicht, dass jede Region identische Hardware, Topologie oder Reserveregeln verwendet.

Diese globale Reichweite gewinnt im heutigen Kontext von KI und Mobilität zusätzlich an Bedeutung. Training, Inferenz, Speicherung und Flottendaten hängen von Rechenzentren, Netzen und Lieferketten ab, die Regionen überschreiten, selbst wenn die architektonische Führung in einem Land sitzt. Die öffentliche Dokumentation legt nicht jede Topologie oder Lieferantenbeziehung offen. Daher sollte die stärkere Aussage gelten: Greenbergs Arbeit betrifft Infrastruktur, deren betriebliche Folgen über die Institutionen hinausreichen, in denen die Forschung zuerst veröffentlicht wurde.

Die Gegenposition: Integrierte Steuerung kann auch Ausfälle koppeln

Das stärkste Argument gegen die Architektur liegt in ihrer eigenen Anziehungskraft. Eine netzwerkweite Sicht kann Regeln, Kapazität und Wiederherstellung besser koordinieren als eine Gruppe isolierter Geräte. Sie kann einem einzigen Softwarefehler jedoch auch einen erheblich größeren Auswirkungsradius geben. 4D machte dies auf konzeptioneller Ebene sichtbar, und spätere Cloud-Systeme mussten sich im Produktivbetrieb damit auseinandersetzen: Wenn Steuerung getrennt und logisch zentralisiert wird, werden der Controller, seine Eingaben und der Einführungsmechanismus zu kritischer Infrastruktur.

Telemetrie beseitigt dieses Problem nicht, weil Beobachtung unvollständig ist. Pingmesh kann eine starke Ausgangsbasis für Latenz und Verlust schaffen, doch synthetische Prüfungen repräsentieren nicht jeden Anwendungspfad oder jede Warteschlange. Verkehrsmatrizen können Nachfrage schätzen, werden aber von Stichproben und Routingänderungen beeinflusst. Die Korrelation von Netzwerk-, Host- und Dienstsignalen kann den Bereich eines Fehlers eingrenzen, ohne dessen Grundursache zu beweisen. Ein System, das seiner Telemetrie zu stark vertraut, kann eine falsche Interpretation schneller automatisieren als ein menschliches Team.

Kapazitätsoptimierung besitzt eine ähnliche Asymmetrie. Bessere Modelle können Verschwendung verringern, wie die Uber-Failover-Arbeit nahelegt. Der Wert einer geringeren Reserve hängt jedoch von Annahmen über Unabhängigkeit und Wiederherstellung ab. Wenn zwei Zonen eine verborgene Abhängigkeit teilen, kann ein Modell, das sie als unabhängig behandelt, die für einen realen Ausfall notwendige Kapazität unterschätzen. Je aggressiver die Plattform ungenutzte Ressourcen optimiert, desto stärker muss sie die Szenarien testen, auf denen die Einsparungen beruhen.

Die Lücke zwischen Forschung und Produktivbetrieb ist eine weitere Fehlerquelle. Eine veröffentlichte Architektur ist eine Momentaufnahme mit bekannter Autorenliste, bekanntem Workload und bekannter Auswertungsmethode. Produktivsysteme vereinen dagegen Hardwareüberarbeitungen, Softwaremigrationen, Kompatibilitätsschichten, Notfallausnahmen und organisatorische Praktiken, die möglicherweise nie veröffentlicht werden. VL2 als heutige Azure-Architektur oder die Uber-Studie von 2026 als dauerhafte Regel für jeden Dienst zu behandeln, würde Belege für ein bestimmtes System in eine Aussage verwandeln, die sie nicht tragen.

Die personenzentrierte Variante desselben Risikos ist Überpersonalisierung. Greenbergs Bilanz ist ungewöhnlich breit, was dazu verleiten kann, ihm die gesamte Entwicklung von softwaredefinierter Steuerung bis zur modernen KI-Infrastruktur zuzuschreiben. Die Belege tragen das nicht. Er verfasste die wichtigsten Systeme nicht allein, besitzt die Infrastruktur von AT&T, Microsoft oder Uber nicht persönlich und kann nicht als Entwickler von Anwendungsmodellen oder Software für autonomes Fahren bezeichnet werden, nur weil Plattformbiografien diese Workloads nennen.

Diese Grenzen mindern den Beitrag nicht, sondern bestimmen ihn genauer. Greenbergs Wirkung liegt darin, Systeme mitgestaltet und geführt zu haben, die Netzwerkverhalten als Zusammenspiel von Topologie, Transport, Steuerung, Messung und organisatorischer Reaktion behandeln. Die Gegenposition lautet, dass jede weitere Integrationsschicht eine zusätzliche Abhängigkeit schafft, die ausfallen, abdriften oder von außen schwer überprüfbar werden kann.

Verkehrsmatrizen machten das Netzwerk planbar

Betreibernetze erzeugen eine enorme Menge betrieblicher Belege, ohne eine einfache Beschreibung der Nachfrage zu liefern. Ein Link-Zähler kann zeigen, dass eine Schnittstelle überlastet ist, erklärt aber nicht, welche Ende-zu-Ende-Nachfrage die Last erzeugt hat oder was beim Ausfall eines anderen Pfades geschehen würde. Flow-Datensätze, Routingtabellen und historische Leistungsdaten bieten jeweils eine Teilansicht. Eine Verkehrsmatrix versucht, diese Perspektiven in einem Modell zu verbinden, das die Nachfrage zwischen Eingangs- und Ausgangspunkten schätzt.

Für Kapazitätsplaner verändert dieses Modell die Fragen, die gestellt werden können. Eine überlastete Verbindung kann ein lokales Problem, das Ergebnis einer Routingregel oder ein Hinweis auf strukturelles Wachstum an anderer Stelle sein. Geplante Wartung kann bei normaler Nachfrage sicher und während einer korrelierten Spitze gefährlich sein. Netzwerkweite Schätzungen erlauben es Ingenieuren, solche Möglichkeiten zu prüfen, bevor sie neue Kapazität oder eine neue Routingregel festlegen.

Die Schätzung bleibt bedingt, weil Netzwerkdaten unvollständig sind. Stichproben können Lastspitzen übersehen, Aggregation kann einzelne Datenflüsse verbergen, und Verschlüsselung begrenzt die Interpretation auf Anwendungsebene. Eine Routingänderung kann Datenverkehr so schnell verlagern, dass die Nachfragematrix von gestern nur ein schwacher Hinweis auf das heutige Risiko ist. Der betriebliche Wert entsteht durch den Vergleich mehrerer unvollkommener Signale im Zeitverlauf, nicht durch das Warten auf ein einziges Messsystem mit endgültiger Antwort.

Dieser empirische Ansatz liegt auch der späteren Cloud-Arbeit zugrunde. VL2 benötigt eine Sicht auf die Nachfrage, wenn Datenflüsse über die Fabric verteilt werden sollen. SWAN benötigt Prognosen und den aktuellen Zustand, wenn WAN-Kapazität zugewiesen werden soll. Eine differenzierte Failover-Planung braucht Belege zu Dienstabhängigkeiten und Wiederherstellungsverhalten. Die Mechanismen unterscheiden sich, doch jeder von ihnen überführt Beobachtungen in ein Modell, das überarbeitet werden kann, wenn es nicht zur Realität passt.

Eine Fabric ist nur nützlich, wenn ihre Steuerung sicher verändert werden kann

Folded-Clos-Topologien wurden für hyperskalige Rechenzentren attraktiv, weil sie mehrere Pfade von Servern in die übrige Fabric bieten und Erweiterungen modularer machen. VL2 verband diese physische Struktur mit Adressindirektion und Verteilung des Datenverkehrs, damit Dienste verschoben werden konnten, ohne an eine starre Standortshierarchie gebunden zu sein. Ziel der Architektur war, Anwendungen eine weitreichende und einheitliche Konnektivität zu geben, obwohl das darunterliegende Netzwerk eine verteilte Menge von Switches und Verbindungen blieb.

Diese Abstraktion verlagert Verantwortung in die Steuerungssoftware. Das System muss Dienstidentitäten Standorten zuordnen, Datenverkehr auf Pfade verteilen und auf den Ausfall von Verbindungen oder Switches reagieren. Sind diese Mechanismen veraltet oder inkonsistent, kann die Fabric über viel Rohbandbreite verfügen und dennoch einen schlechten Dienst liefern. Topologie ist deshalb eine Kapazitätsressource, keine Garantie für Zuverlässigkeit.

Dasselbe gilt für virtuelle Vernetzung. Kunden sehen ein programmierbares Netzwerk, während der Anbieter ihre Absicht in Hostregeln, Routen, Tunnel, Gateways und gemeinsam genutzte physische Kapazität übersetzt. Änderungen müssen versioniert und sicher eingeführt werden, weil der Kunde den verborgenen Zustand nicht sieht. Ein Fehler der Steuerungsebene kann neue Konfigurationen beeinträchtigen, während bestehende Datenflüsse der Datenebene weiterlaufen. Eine Störung zeigt dann je nach Zeitpunkt der Erstellung oder Verlagerung eines Workloads unterschiedliche Symptome.

Hier wird Architektur zu einem Betriebsvertrag. Das Plattformteam nimmt den Anwendungsteams Komplexität ab und übernimmt dafür Verantwortung für Kompatibilität, Beobachtbarkeit und Wiederherstellung. Gemeinsame Abstraktionen können eine Organisation schneller machen, aber nur, wenn die betreibenden Teams ihre Grenzen erklären und einen Ausweg bereitstellen können, falls die Abstraktion versagt.

Überlastungssteuerung zeigt, warum Teamgrenzen Teil des Designs sind

DCTCP ist ein nützliches Beispiel, weil der Mechanismus eine Grenze überschreitet, die Organisationen häufig als klare Trennlinie behandeln. Switches markieren Pakete, wenn Warteschlangen einen Schwellenwert überschreiten, während Endpunkte ihr Sendeverhalten anhand des Anteils der Markierungen anpassen. Keine Seite kann allein das beabsichtigte Ergebnis liefern. Netzwerkteam und Host- beziehungsweise Betriebssystemteam müssen sich über Verhalten, Schwellenwerte, Einführung und Messung verständigen.

Im Maßstab eines Rechenzentrums sind solche Vereinbarungen keine einmaligen Konfigurationsentscheidungen. Neue Hardwaregenerationen können das Pufferverhalten verändern. Host-Abbilder können unterschiedlichen Transportcode einführen. Workloads können sich von kurzen Anfrage-Antwort-Mustern zu großen Speicherübertragungen oder KI-Kommunikationsmustern verlagern. Eine Einstellung, die unter einer bestimmten Mischung funktionierte, kann unter einer anderen Unfairness oder Latenz erzeugen. Der Regelkreis muss deshalb überwacht werden, während sich das umgebende System verändert.

Das erklärt auch die Bedeutung der Unterscheidung zwischen Forschung und Produktivbetrieb. Eine Veröffentlichung kann einen Mechanismus isolieren und unter kontrollierten Annahmen ein Ergebnis zeigen. Produktteams müssen diese Annahmen dagegen bewahren oder erkennen, wann sie nicht mehr gelten. Gute Architektur macht Abhängigkeiten so sichtbar, dass eine Aktualisierung getestet werden kann, bevor sie die gesamte Flotte erreicht.

Greenberg kehrt wiederholt zu diesem Problem zurück. Ananta verteilt eine Funktion, die Appliances konzentriert hatten. SWAN zentralisiert die Logik rund um das WAN, während die Weiterleitung verteilt bleibt. Pingmesh schafft gemeinsame Belege für Teams, die möglicherweise unterschiedlicher Ansicht darüber sind, ob ein Fehler im Netzwerk oder in der Anwendung liegt. Jedes System verändert eine technische Grenze und damit zugleich die organisatorische Grenze zwischen den Teams, die zusammenarbeiten müssen.

Beobachtbarkeit ist nur wertvoll, wenn sie eine Entscheidung verändert

Eine große Plattform kann mehr Telemetrie sammeln, als ein Mensch direkt prüfen kann. Die Herausforderung besteht nicht bloß darin, mehr zu messen, sondern Messungen mit Handlungen zu verbinden. Pingmesh machte Latenz und Verlust über viele Paare von Endpunkten hinweg kontinuierlich beobachtbar und lieferte eine Ausgangsbasis, die Betreiber während Störungen zum Vergleich heranziehen konnten. Das ist nützlich, wenn Geräte laut Zustandsanzeige gesund sind, Nutzer jedoch ein Problem auf Pfadebene erleben.

Synthetische Messungen besitzen einen wichtigen Vorteil: Sie können auch dann kontinuierlich laufen, wenn eine Anwendung ruhig ist. Sie haben ebenso eine wichtige Grenze: Sie sind nicht die Anwendung. Eine Prüfung kann einen anderen Pfad nehmen, eine bestimmte Warteschlangenlage übersehen oder die Anwendungsabhängigkeit umgehen, die das Symptom verursacht. Betriebliche Beurteilung entsteht deshalb aus der Verbindung synthetischer Netzwerkbelege mit Diensttelemetrie, Topologiezustand und Bereitstellungshistorie.

Dasselbe gilt für Verkehrsmatrizen und Ausfalltests. Messung wird zu Infrastruktur, sobald sie Teil eines wiederholbaren Entscheidungsregelkreises ist. Ein Kapazitätsplaner ändert den Erweiterungsplan, weil Nachfragedaten einen Engpass zeigen. Ein Controller verlagert Datenverkehr, weil der aktuelle Zustand einen Ausfall erkennen lässt. Ein Störungsteam setzt eine Bereitstellung zurück, weil Telemetrie eine Änderung mit einem Verlustmuster verbindet. Kennzahlen, die keine Entscheidung verändern können, sind Berichte; können sie eine Entscheidung verändern, werden sie Teil der Steuerung.

Diese Unterscheidung erklärt, warum Greenbergs Arbeit mit der Ausbreitung von Software-defined Networking relevant bleibt. Mehr Programmierbarkeit bedeutet, dass Entscheidungen schneller getroffen werden können. Dadurch steigt der Wert von Belegen darüber, ob diese Entscheidungen erfolgreich waren. Automatisierung ohne Messung ist blind. Messung ohne einen Weg zur Veränderung bleibt passiv. Architektur wird nützlich, wenn beide Seiten verbunden sind, ohne dass der Regelkreis so aggressiv wird, dass ein einziges fehlerhaftes Signal das System destabilisiert.

KI-Infrastruktur erhöht die Kosten von Fehlern in Regelkreisen

Heutige KI-Infrastruktur beseitigt die älteren Lehren nicht, sondern erhöht ihren Einsatz. Trainingssysteme können anhaltenden Ost-West-Datenverkehr zwischen Beschleunigern, Speicher und Rechenknoten erzeugen. Inferenz kann latenzkritische Dienstpfade ergänzen. Die Platzierung von Beschleunigern, Datenbewegung und Wiederherstellung nach Ausfällen machen das Netzwerk zu einem Teil der Workload-Planung und nicht zu einem Hilfsmittel im Hintergrund. Eine Steuerungsentscheidung, die Kapazität bindet oder Überlastung erzeugt, kann neben Netzwerkbandbreite auch teure Rechenleistung verschwenden.

Die verfügbaren Belege verbinden Greenbergs heutigen Plattformzuständigkeitsbereich bei Uber mit Infrastruktur für KI und autonome Fahrzeuge, gehen jedoch nicht so weit, jedes System zu benennen oder ihm persönliche Entwurfsverantwortung zuzuschreiben. Diese Lücke muss sichtbar bleiben. Der angemessene Schluss lautet, dass dieselben Disziplinen – Topologie, Kapazität, Load Balancing, Telemetrie und Ausfallbereiche – für diese Workloads wichtig sind, nicht dass eine einzelne Führungskraft für die darauf aufbauenden Algorithmen verantwortlich ist.

Spezialisierte KI-Fabrics können sich zudem von allgemeinen Cloud-Netzen unterscheiden. Trainingscluster können eng kontrollierte Verbindungen und andere Planungsannahmen verwenden als Ethernet/IP-Dienstnetze für gewöhnliche Anwendungen. Auch wenn sich die Technologien aufteilen, bleiben die Steuerungsfragen vertraut: Wie groß ist die Nachfrage, wo liegt die Regellogik, wie wird Zustand eingespielt, welche Ausfälle sind unabhängig und welche Belege zeigen, dass das beabsichtigte Verhalten tatsächlich eingetreten ist?

Hier bleibt Greenbergs integrierte Sicht nützlicher als eine einzelne Produktbezeichnung. Die Geschichte legt nahe, dass sich Infrastruktur verbessert, wenn Entwickler Topologie, Transport, Load Balancing, WAN-Kapazität und Telemetrie nicht länger als getrennte Fachgebiete behandeln. KI macht die Kosten der Fragmentierung sichtbarer, weil ungenutzte Beschleuniger, gescheiterte Aufgaben und verzögerte Datenbewegung einen Fehler der Netzwerksteuerung in große Verluste an Rechenleistung und Kapital verwandeln können.

Architektur besteht nur, wenn Organisationen sie betreiben können

Technische Veröffentlichungen enden häufig dort, wo die Arbeit des Produktivbetriebs beginnt. Eine Topologie wird beschrieben, ein Algorithmus ausgewertet, und Messungen zeigen, dass ein Mechanismus funktionieren kann. Der jahrelange Betrieb benötigt jedoch andere Strukturen: klare Zuständigkeit, Freigabeprozesse, Bereitschaftssysteme, Kapazitätspläne, Hardwareerneuerung, Sicherheitsprüfungen, Kompatibilitätsregeln und eine Methode, den Entwurf zu ändern, ohne den Dienst anzuhalten.

Greenbergs Laufbahn überschritt diese Grenze wiederholt. Die Arbeit bei AT&T fand in einem aktiven Betreibernetz statt, dessen Datenverkehr nicht für Forschungszwecke angehalten werden konnte. Ideen aus der Microsoft-Forschung gelangten in eine Azure-Organisation, die Kunden über Hardwaregenerationen und Regionen hinweg unterstützen musste. Plattformteams bei Uber müssen Anwendungsgruppen mit unterschiedlichen Zuverlässigkeits- und Leistungsanforderungen bedienen.

Die Mechanismen verändern sich, doch der organisatorische Test bleibt ähnlich: Lässt sich eine netzwerkweite Idee in wiederholbare Entscheidungen überführen, die viele Teams treffen können?

Gemeinsame Abstraktionen sind nützlich, weil sie spezialisierte Arbeit bündeln. Eine einheitliche Fabric gibt Erweiterungen eine vertraute Form. Virtuelle Vernetzung bietet Kunden eine stabile Steuerungsoberfläche, während der Anbieter das physische Netz verändert. Ein gemeinsamer Load-Balancing-Dienst verhindert, dass jedes Anwendungsteam eine eigene Eingangsarchitektur entwickelt. Gemeinsame Telemetrie ermöglicht Störungsverantwortlichen die Arbeit mit derselben Sicht. Standardisierte Failover-Klassen erlauben Kapazitätsplanern, Workloads zu unterscheiden, ohne jeden Dienst von Grund auf neu auszuhandeln.

Diese Konzentration schafft jedoch Gegenpflichten. Das Plattformteam muss Grenzen veröffentlichen, Kompatibilität schützen und Belege liefern, wenn die Abstraktion undicht wird. Ein Kunde kann eine verborgene Fabric oder Steuerungsebene nicht selbst reparieren. Zentrale Entscheidungslogik ist nur dann gerechtfertigt, wenn das zentrale Team den größeren Auswirkungsradius durch Replikation, stufenweise Änderungen, Rollback und klare Verantwortung für Störungen beherrschen kann.

Die Wirtschaftlichkeit des Hyperscale-Betriebs verstärkt diesen Gedanken. Eine kleine prozentuale Verbesserung bei Auslastung, Warteschlangen, Lastverteilung oder Reservekapazität kann sich auf eine riesige Flotte auswirken. Dieselbe Größenordnung vervielfacht Fehler. Ein ungeeigneter Schwellenwert für Überlastung, ein Fehler bei der Routenverteilung oder eine blinde Stelle in der Telemetrie kann viele Dienste gleichzeitig betreffen. Ein technischer Parameter wird dadurch zu einer Geschäftsentscheidung: Er verändert, wie viel Infrastruktur das Unternehmen finanzieren muss und wie viel Betriebsrisiko es übernimmt.

Der Regelkreis muss seine Gestalter überdauern

Große Netzsysteme werden nicht einmal eingeführt und bleiben anschließend unverändert. Hardwaregenerationen wechseln, Workloads verändern sich, Produkte erhalten neue Anforderungen, und Organisationen verteilen Verantwortung neu. Eine Architektur, die nur funktioniert, solange ihre ursprünglichen Entwickler anwesend sind, ist keine dauerhafte Infrastruktur. Der schwierigere Test lautet, ob neue Teams das System verändern können und dabei eine verständliche Erklärung von Nachfrage, Entscheidung, Weiterleitung und Ausfall bewahren.

Die großen mit Greenberg verbundenen Projekte machen unterschiedliche Teile dieser Kontinuität explizit. Verkehrsmatrizen machen Nachfrage für die Planung sichtbar. Die 4D-Architektur trennt Steuerungsrollen, damit Regellogik unabhängig von der Weiterleitung geprüft werden kann. VL2 trennt Dienstplatzierung vom physischen Standort. DCTCP macht Überlastung zu einer gemeinsamen Rückmeldung zwischen Switches und Endpunkten. Ananta und SWAN weisen Datenverkehr auf Dienst- und WAN-Ebene zu, während Pingmesh kontinuierliche Belege zu Verzögerung und Verlust erzeugt.

Im Produktivbetrieb werden diese Mechanismen zu institutionellem Gedächtnis. Schnittstellen benötigen Versionen, Telemetrie muss über Aktualisierungen hinweg vergleichbar bleiben, und Kapazitätsmodelle müssen neu kalibriert werden, wenn sich Workloads verändern. Ausfallübungen müssen Annahmen über Unabhängigkeit und Reserve infrage stellen. Störungsanalysen müssen Architektur ebenso wie Code verändern, wenn sich herausstellt, dass vermeintlich unabhängige Pfade eine Abhängigkeit teilen oder eine Einführung eine Schwäche der Steuerungsebene offenlegt.

Hier liegt auch die klarste Grenze von Greenbergs persönlicher Rolle. Er hat weder Software-defined Networking noch Cloud-Vernetzung oder jedes mit AT&T, Microsoft und Uber verbundene System allein erfunden. Die Belege tragen die Aussage eines langjährigen Beitrags dazu, das Netzwerk als integrierten verteilten Computer zu behandeln, in dem Topologie, Transport, Steuerung, Telemetrie und Betriebsorganisation gemeinsam konstruiert werden müssen. Diese Wirkung ist stärker, wenn die Disziplin die Person überdauert, die sie mitgeprägt hat.

Der entscheidende überprüfbare Test ist deshalb weder eine weitere Auszeichnung noch ein weiterer öffentlicher Titel. Die Frage lautet, ob die von diesem Ansatz geprägten Plattformen sich weiter verändern können, ohne die Verbindung zwischen dem Beabsichtigten, dem Eingespielten und dem von den Nutzern tatsächlich Erlebten zu verlieren. Neue KI-Workloads, Hardware und Ausfallmodelle werden das Ziel weiter verschieben. Eine robuste Architektur macht solche Veränderungen verständlich genug für Tests, umkehrbar genug für den Betrieb und explizit genug, damit Verantwortung nicht im System verschwindet.