Wir haben vor Kurzem die ayedo Edge Cloud vorgestellt. Eine europäische Edge-Infrastruktur für DNS, Anycast, Loadbalancing, Web Application Firewall, DDoS-Schutz und den kontrollierten Zugang zu Anwendungen.
Die Reaktion darauf hat uns gezeigt, dass sich ein genauerer Blick auf die Technik lohnt. Denn eine Edge Cloud ist weit mehr als ein vorgeschalteter Loadbalancer.
Sie kontrolliert einen entscheidenden Teil der Infrastruktur: den Weg aus dem öffentlichen Internet bis zur eigentlichen Anwendung.
Bevor eine Anfrage den ersten Pod im Kubernetes-Cluster erreicht, ist bereits einiges passiert. DNS hat einen Namen aufgelöst. Das Internet hat anhand von BGP-Routen einen Netzwerkpfad gewählt. Eine öffentliche IP wurde erreicht. Eine Verbindung wurde angenommen, Traffic geprüft und anschließend an ein verfügbares Backend weitergeleitet.
Wer diese Komponenten betreibt, kontrolliert einen erheblichen Teil des Zugangs zur Anwendung.
Deshalb haben wir bei unserer Edge Cloud nicht bei einem einzelnen Produktfeature angefangen. Wir haben die darunterliegende Infrastruktur aufgebaut.
Ein eigenes Autonomous System als Grundlage
Die technische Basis unserer Edge Cloud ist unser eigenes Autonomous System.
Ein Autonomous System, kurz AS, ist vereinfacht gesagt ein eigenständig verwalteter Teil des Internets mit einer eigenen Routing-Policy. Über BGP tauschen solche Netze untereinander aus, welche IP-Netze über sie erreichbar sind.
Für unsere Edge bedeutet das: Wir betreiben die Netzwerkschicht, über die unsere Standorte ihre Routen im Internet bekannt geben.
Zum Start arbeiten fünf Points of Presence in Deutschland: Hamburg, Alsbach und drei Standorte in Frankfurt. Alle fünf sind aktiv und announcen dieselben Anycast-Präfixe.
Eine IP-Adresse, mehrere Standorte
Anycast ist ein zentraler Bestandteil dieser Architektur.
Dabei wird dasselbe IP-Präfix gleichzeitig von mehreren Standorten angekündigt. Ein Nutzer verbindet sich also beispielsweise immer mit derselben öffentlichen IP-Adresse – diese IP ist aber nicht an einen einzelnen Server oder einen einzelnen Standort gebunden.
BGP bestimmt anhand der verfügbaren Routen, über welchen PoP die Verbindung die Edge erreicht.
Das hat einen entscheidenden Vorteil: Fällt ein Standort aus und seine Route wird zurückgezogen, bleiben die anderen Standorte erreichbar. Neue Verbindungen können über einen anderen PoP geführt werden. Dafür muss weder eine öffentliche IP geändert noch auf die Aktualisierung eines DNS-Eintrags gewartet werden.
Redundanz beginnt damit nicht erst beim Server, sondern bereits im Routing.
Auch DNS läuft über die Edge
Noch vor der eigentlichen Verbindung steht in den meisten Fällen DNS. Deshalb gehört auch diese Ebene zur Edge Cloud.
DNS-Zonen werden über unsere Edge-Infrastruktur mit Anycast bereitgestellt. Damit ist auch die Namensauflösung nicht an einen einzelnen Standort gebunden.
Gleichzeitig behandeln wir DNS nicht als Konfiguration, die ausschließlich über ein Webinterface verwaltet werden kann. DNS lässt sich automatisieren und in Infrastructure-as-Code-, CI/CD- und GitOps-Prozesse integrieren.
Das ist gerade für Plattformteams wichtig: Infrastruktur bleibt reproduzierbar und kann mit denselben Prozessen verwaltet werden wie der Rest des Stacks.
Die öffentliche IP muss nicht uns gehören
Ein weiterer Bestandteil ist Bring Your Own IP, kurz BYOIP.
Unternehmen können eigene IP-Präfixe mitbringen, die wir über unsere Edge-Infrastruktur announcen und routen.
Das klingt zunächst nach einem Detail für Netzwerkadministratoren. Für die Unabhängigkeit einer Infrastruktur ist es aber relevant.
Öffentliche IP-Adressen landen mit der Zeit in Firewall-Regeln, Allowlists von Geschäftspartnern, APIs und anderen Konfigurationen. Gehören diese Adressen dem Cloud-Anbieter, kann ein Providerwechsel deshalb weit mehr bedeuten als den Umzug einiger Workloads.
Mit BYOIP bleiben die Adressen beim Unternehmen. Der öffentliche Adressraum und die darunterliegende Compute-Infrastruktur werden voneinander getrennt.
Edge und Compute sind zwei unterschiedliche Entscheidungen
Diese Trennung zieht sich durch die gesamte Architektur.
Die Anwendung hinter unserer Edge muss nicht in der ayedo Compute Cloud laufen. Sie kann dort betrieben werden, in einem Kubernetes-Cluster bei einem anderen Provider oder in eigener Infrastruktur.
Die Edge übernimmt den öffentlichen Zugang und leitet Traffic zum definierten Backend.
Damit werden zwei Dinge voneinander entkoppelt, die bei Cloud-Plattformen häufig zusammenfallen: Wo läuft meine Anwendung – und über wessen Infrastruktur ist sie erreichbar?
Das macht hybride und Multi-Provider-Architekturen möglich, ohne für jeden Compute-Standort eine komplett eigene öffentliche Zugriffsschicht aufbauen zu müssen.
Vom Internet bis zum Kubernetes-Pod
Bei Kubernetes lässt sich dieser Weg sehr konkret nachvollziehen:
Client → ayedo Edge / Loadbalancer → Node → Ingress Controller oder Gateway Proxy → Service → Pod
Der Edge-Loadbalancer hält die öffentliche virtuelle IP, prüft die Erreichbarkeit der Backends und leitet TCP- oder HTTP-Traffic weiter beziehungsweise terminiert ihn.
Innerhalb des Clusters übernimmt anschließend ein Ingress Controller oder Gateway Proxy das anwendungsspezifische Routing. Dort wird beispielsweise anhand von Hostname und Pfad entschieden, welcher Service eine HTTP-Anfrage erhält.
Für bestehende Kubernetes-Architekturen unterstützen wir NGINX Ingress mit Ingress und IngressClass.
Für neue Architekturen steht Envoy Gateway mit der Kubernetes Gateway API und Ressourcen wie Gateway, HTTPRoute und TLSRoute zur Verfügung.
Das ist für uns ein wichtiger Architekturgrundsatz: Der Übergang von unserer Infrastruktur zum Kubernetes-Cluster basiert auf etablierten Cloud-Native-Standards und nicht auf einer proprietären ayedo-Routinglogik.
Security gehört vor die Anwendung
Auf derselben Ebene sitzen die Schutzmechanismen.
Zur Edge Cloud gehören deshalb Layer-4- und Layer-7-Loadbalancing, TLS, Web Application Firewall, DDoS-Schutz und Health-Checks.
Die WAF kann HTTP(S)-Traffic prüfen, bevor er die dahinterliegenden Anwendungen erreicht. DDoS-Schutz setzt bereits auf der vorgelagerten Infrastruktur an. Health-Checks stellen sicher, dass Traffic nicht einfach an ein Ziel geschickt wird, nur weil dessen Netzwerkroute noch existiert.
Das ist ein wichtiger Unterschied: Ein erreichbarer Server ist noch lange kein funktionierender Service.
Edge-Infrastruktur muss deshalb Routing, Verfügbarkeit und Security gemeinsam betrachten.
Eine europäische Alternative muss technisch überzeugen
Cloudflare hat diese Infrastrukturschicht sehr erfolgreich zu einem Produkt gemacht. DNS, Anycast, Routing, Loadbalancing und Security aus einer Hand zu bekommen, löst reale technische Probleme.
Eine europäische Alternative kann deshalb nicht darin bestehen, dasselbe Konzept mit einem EU-Label zu versehen.
Sie braucht eigene Infrastruktur.
Ein eigenes Autonomous System. Eigenes Routing. Mehrere aktive PoPs. Anycast. DNS. Loadbalancing. WAF und DDoS-Schutz. Offene Schnittstellen zu Kubernetes. Die Möglichkeit, Compute unabhängig zu wählen. Und mit BYOIP sogar die Möglichkeit, den eigenen öffentlichen Adressraum zu behalten.
Genau diese Infrastruktur bauen wir mit der ayedo Edge Cloud.
Denn europäische Cloud-Infrastruktur ist erst dann eine echte Alternative, wenn sie nicht nur regulatorisch anders aufgestellt ist, sondern technisch die Kontrolle über die entscheidenden Schichten zurückholt.