Der Anfang einer Plattform

Warum jede Architektur irgendwann an den Punkt gelangt, an dem sie das Netzwerk neu denken muss.

Vielleicht besteht die größte Herausforderung moderner Plattformarchitektur nicht darin, Anwendungen zuverlässig zu betreiben. Dafür verfügen wir heute über außerordentlich leistungsfähige Werkzeuge. Kubernetes orchestriert Container mit einer Selbstverständlichkeit, die vor wenigen Jahren noch undenkbar gewesen wäre. Infrastructure as Code macht selbst komplexe Umgebungen reproduzierbar. GitOps reduziert operative Eingriffe auf deklarative Änderungen in einem Repository, während Observability-Plattformen Milliarden von Metriken, Logs und Traces nahezu in Echtzeit auswerten können. Vergleicht man die Möglichkeiten moderner Plattformen mit denen vor zehn oder fünfzehn Jahren, könnte man leicht zu dem Schluss gelangen, dass Infrastruktur heute weitgehend gelöst sei. Vielleicht stimmt das sogar. Zumindest für einen Teil der Plattform.

Während dieser Artikelreihe haben wir versucht, den Blick auf einen Bereich zu richten, der in vielen Architekturdiagrammen erstaunlich wenig Aufmerksamkeit erhält, obwohl er jede einzelne öffentliche Anwendung überhaupt erst erreichbar macht. Wir haben darüber gesprochen, dass moderne Anwendungen längst nicht mehr im Rechenzentrum beginnen. Wir haben den Weg eines Requests verfolgt und festgestellt, dass das Internet weder Anwendungen noch Kubernetes-Cluster kennt, sondern ausschließlich Netzwerke und Erreichbarkeit. Wir haben gesehen, weshalb Anycast keine zusätzliche Funktion darstellt, sondern unmittelbar aus der Architektur von BGP entsteht, warum Hochverfügbarkeit heute weit früher beginnt als bei einem Failover zwischen zwei Rechenzentren und weshalb Compute-Plattformen und Edge-Plattformen zwar eng miteinander zusammenarbeiten, jedoch vollkommen unterschiedliche Verantwortlichkeiten besitzen. Vielleicht lässt sich all das auf eine einzige Beobachtung reduzieren. Die Eintrittsschicht moderner Anwendungen hat sich zu einer eigenständigen Plattform entwickelt. Nicht deshalb, weil dort besonders viele Produkte betrieben werden. Sondern weil dort Entscheidungen getroffen werden, die kein anderes System der Architektur sinnvoll übernehmen kann.

Interessanterweise führt genau diese Erkenntnis häufig zu einer weiteren Frage. Wenn Edge heute eine Plattform ist – wo endet sie eigentlich? Die Antwort darauf fällt überraschend schwer. Sie endet weder an einem Loadbalancer noch an einer Web Application Firewall. Sie endet auch nicht mit der TLS-Terminierung. Denn all diese Komponenten besitzen keine eigenständige Existenzberechtigung. Sie erfüllen lediglich unterschiedliche Aufgaben innerhalb derselben Verarbeitungskette. Vielleicht beschreibt genau dieses Diagramm die Architektur moderner Plattformen deutlich präziser als viele klassische Darstellungen.

                     Internet
                          │
                          ▼
              +-----------------------+
              |     Edge Platform     |
              |-----------------------|
              | DNS                   |
              | Routing               |
              | Anycast               |
              | TLS                   |
              | Layer 4               |
              | Layer 7               |
              | WAF                   |
              | Health Checks         |
              | Traffic Engineering   |
              +-----------┬-----------+
                          │
                          ▼
              +-----------------------+
              |   Compute Platform    |
              |-----------------------|
              | Kubernetes            |
              | Container Runtime     |
              | Services              |
              | Deployments           |
              | Storage               |
              | Business Logic        |
              +-----------------------+

Vielleicht fällt zunächst gar nicht auf, was sich gegenüber klassischen Architekturdiagrammen verändert hat. Es sind nicht die Komponenten. Fast alle existierten bereits zuvor. Verändert hat sich ihre Beziehung zueinander. Die Edge ist nicht länger Infrastruktur vor der Plattform. Sie ist selbst Teil der Plattform.

Genau diese Beobachtung war letztlich auch der Ausgangspunkt für alles, was wir in den vergangenen Jahren aufgebaut haben. Nicht, weil wir einen weiteren Loadbalancer entwickeln wollten. Nicht, weil wir glaubten, DNS neu erfinden zu müssen. Und auch nicht, weil bestehende Werkzeuge ihre Aufgabe schlecht erfüllen würden. Ganz im Gegenteil. Nahezu alle Technologien, über die wir in dieser Serie gesprochen haben, gehören seit Jahrzehnten zu den stabilsten und zuverlässigsten Bausteinen des Internets. Die eigentliche Frage lautete vielmehr, weshalb sie in modernen Plattformen häufig noch immer wie voneinander unabhängige Produkte betrieben werden, obwohl sie aus Sicht eines Requests längst eine gemeinsame Verarbeitungsschicht bilden. Aus dieser Fragestellung entstand schließlich unsere eigene Edge-Plattform. Nicht als Sammlung einzelner Netzwerkdienste. Sondern als Architekturebene zwischen dem öffentlichen Internet und unserer Compute Cloud. Eine Ebene, die Routing, Anycast, TLS, Layer-4- und Layer-7-Loadbalancing, Health Checks, DNS sowie Sicherheitsmechanismen nicht als lose Kette spezialisierter Komponenten versteht, sondern als unterschiedliche Verantwortlichkeiten innerhalb derselben Plattform.

Mit diesem Artikel endet diese Reihe allerdings nicht. Eigentlich beginnt sie hier erst. Jedes Thema, das wir in den vergangenen Wochen behandelt haben, verdient eine deutlich tiefere Betrachtung. Warum konvergiert BGP in manchen Situationen innerhalb weniger Sekunden, während andere Änderungen deutlich länger benötigen? Welche Auswirkungen besitzen unterschiedliche Peering-Strategien tatsächlich auf die Latenz einer Plattform? Weshalb unterscheiden sich Layer-4- und Layer-7-Loadbalancing architektonisch deutlich stärker, als ihre Bezeichnungen vermuten lassen? Wie bewertet eine Edge-Plattform den Gesundheitszustand eines Backends, wenn sich verteilte Systeme grundsätzlich niemals in einem vollständig konsistenten Zustand befinden? Und welche Rolle spielen Kubernetes-Komponenten wie Cloud Controller Manager, ExternalDNS oder cert-manager, wenn die Edge selbst Teil der Plattform wird? Genau diesen Fragen möchten wir uns in den kommenden Artikeln widmen. Nicht aus Sicht eines Produkts. Sondern aus Sicht der Architektur. Nicht mit Marketingbegriffen. Sondern mit Routingtabellen, Paketmitschnitten, Sequenzdiagrammen, RFCs, Konfigurationsbeispielen und den Entscheidungen, die hinter einer modernen Plattform tatsächlich stehen.

Vielleicht besteht die wichtigste Erkenntnis dieser gesamten Reihe deshalb auch nicht darin, dass Edge-Plattformen immer wichtiger werden. Sondern darin, dass wir beginnen sollten, unsere Architekturdiagramme an einem anderen Punkt zu zeichnen. Nicht dort, wo Anwendungen ausgeführt werden. Sondern dort, wo sie für einen Benutzer zum ersten Mal existieren. In dem Moment, in dem eine Domain aufgelöst wird. In dem Moment, in dem das Internet einen Pfad auswählt. In dem Moment, in dem eine Plattform entscheidet, ob eine Verbindung angenommen, geschützt und bis zur eigentlichen Anwendung begleitet wird. Vielleicht beginnt moderne Infrastruktur genau dort. Und vielleicht beginnt dort auch die nächste Generation moderner Cloud-Plattformen. Für uns war genau das der Ausgangspunkt. Die ayedo Edge Cloud ist deshalb nicht das Ende einer Entwicklung. Sie ist der Anfang einer Plattform.