Warum wir die ayedo Edge Cloud gebaut haben
Eine Anwendung kann vollständig in Deutschland betrieben werden und trotzdem bei jedem einzelnen Zugriff von US-Infrastruktur abhängig sein.
Denn bevor eine Anfrage den ersten Pod im Kubernetes-Cluster erreicht, ist bereits einiges passiert. DNS hat den Namen aufgelöst. Das Internet hat einen Netzwerkpfad gewählt. Eine öffentliche IP wurde erreicht. TLS wurde terminiert oder weitergeleitet. Traffic wurde geprüft und auf ein Backend verteilt.
Genau diese Schicht ist die Edge.
Und genau hier beginnt für uns die Frage, wer die technische Kontrolle über eine Anwendung tatsächlich hat.
Es beginnt nicht mit dem Server, sondern mit dem Routing
Die technische Basis unserer Edge Cloud ist ein eigenes Autonomous System. Damit betreiben wir die Netzwerkschicht, über die unsere Edge-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.
Das ist ein wichtiger Unterschied zu einer Architektur, bei der ein Dienst fest an einen Standort und dessen IP-Adresse gebunden ist.
Bei Anycast ist dieselbe öffentliche IP gleichzeitig über mehrere Standorte erreichbar. Das Routing entscheidet, über welchen erreichbaren PoP eine neue Verbindung geführt wird. Fällt ein Standort aus, muss nicht erst ein Standby-System aktiviert und anschließend auf die DNS-Propagation gewartet werden. Die verbleibenden PoPs announcen die Route weiterhin.
Verfügbarkeit entsteht damit bereits auf Netzwerkebene.
DNS gehört zur Infrastruktur
Vor fast jeder Verbindung steht eine DNS-Anfrage. Deshalb behandeln wir DNS nicht als externen Zusatzdienst.
DNS-Zonen werden über die Edge-Infrastruktur mit Anycast bereitgestellt. Anfragen können damit einen erreichbaren PoP nutzen. Interne und externe Zonen lassen sich zentral verwalten, externe Zonen mit unterstützten DNS-Providern synchronisieren.
Entscheidend ist aber auch, wie DNS betrieben wird.
Die Konfiguration lässt sich in Automatisierungsprozesse integrieren. DNS wird damit Teil von Infrastructure as Code, CI/CD und GitOps statt einer Konfiguration, die jemand manuell in einem fremden Webinterface pflegt.
Das ist für Entwickler praktisch. Für Unternehmen ist es vor allem nachvollziehbar und reproduzierbar.
Die öffentliche IP muss nicht dem Cloud-Provider gehören
Ein oft unterschätzter Lock-in entsteht bei IP-Adressen.
Wechselt ein Unternehmen den Provider und damit seine öffentlichen IPs, betrifft das schnell mehr als einen DNS-Record. Allowlists bei Partnern, Firewall-Regeln, APIs, Zertifikatsprozesse und andere Systeme können an diesen Adressen hängen.
Deshalb unterstützt die Edge Cloud Bring Your Own IP.
Unternehmen können eigene IP-Präfixe einsetzen. Wir announcen und routen diese über unsere Edge-Infrastruktur.
Damit kann der öffentliche Adressraum vom Compute-Provider getrennt werden. Ein Backend kann wechseln, ohne dass zwangsläufig auch seine öffentliche Identität im Netz wechseln muss.
Das ist ein ziemlich konkreter Unterschied zwischen „wir können theoretisch den Provider wechseln“ und „unsere Architektur ist tatsächlich darauf vorbereitet“.
Edge und Compute sind bewusst getrennt
Die Edge Cloud ist nicht an die ayedo Compute Cloud gebunden.
Die Anwendung kann in unserer Compute Cloud laufen, in einem anderen Kubernetes-Cluster, bei einem anderen Provider oder on-premises. DNS und Traffic können trotzdem über die Edge bereitgestellt werden.
Das verändert die Architektur grundlegend.
Der öffentliche Einstiegspunkt und der Ort, an dem Compute stattfindet, werden zu zwei getrennten Entscheidungen.
Ein Unternehmen kann also seinen Compute-Standort verändern, ohne gleichzeitig die komplette externe Erreichbarkeit neu bauen zu müssen. Umgekehrt kann die Edge-Infrastruktur ausgetauscht oder erweitert werden, ohne die Anwendungsarchitektur grundsätzlich zu verändern.
Genau diese Entkopplung reduziert Abhängigkeiten.
Vom Internet bis zum Pod ist der Pfad klar definiert
Technisch sieht der Weg einer Anfrage bei Kubernetes-Workloads so aus:
Client → ayedo Edge / Loadbalancer → Node → Ingress Controller oder Gateway Proxy → Service → Pod.
Die einzelnen Schichten haben unterschiedliche Aufgaben.
Der Edge-Loadbalancer hält die öffentliche virtuelle IP, führt Health-Checks durch und kann TCP- oder HTTP-Traffic terminieren beziehungsweise weiterleiten. Im Cluster übernimmt anschließend der Ingress Controller oder Gateway Proxy das Routing nach Hostname und Pfad. TLS kann dort terminiert oder per Passthrough weitergereicht werden.
Für bestehende Kubernetes-Workloads unterstützen wir NGINX Ingress mit den etablierten Ingress- und IngressClass-Ressourcen.
Für neue Architekturen steht Envoy Gateway mit der Kubernetes Gateway API zur Verfügung. Routing wird dort über Ressourcen wie Gateway, HTTPRoute und TLSRoute beschrieben.
Das ist bewusst keine proprietäre ayedo-Routing-API, die Anwendungen technisch an unsere Plattform bindet.
Schutz findet statt, bevor der Traffic die Anwendung erreicht
Zur Edge gehören deshalb auch die Sicherheitsfunktionen, die vor dem eigentlichen Workload greifen.
Die ayedo Edge Cloud bündelt DNS, TLS, Layer-4- und Layer-7-Loadbalancing, Web Application Firewall, DDoS-Schutz und Health-Checks.
Die WAF sitzt damit nicht irgendwo innerhalb der Anwendung, sondern kann HTTP(S)-Traffic bereits am Edge prüfen. Erst danach erreicht legitimer Traffic Cluster-Ingress, Services und Pods.
Health-Checks erfüllen eine ebenso wichtige Funktion: Eine Route kann technisch erreichbar sein, obwohl das dahinterliegende Backend nicht mehr funktioniert. Deshalb reicht Netzwerk-Redundanz allein nicht. Die Edge muss auch wissen, welche Ziele tatsächlich verfügbar sind.
Netzwerk, Routing, Anwendungsgesundheit und Schutzmechanismen gehören deshalb zusammen.
Eine europäische Cloud braucht eine europäische Netzwerkschicht
Cloudflare hat gezeigt, wie wertvoll es ist, DNS, Routing, Loadbalancing und Security an einer globalen Edge zusammenzuführen.
Das Problem ist nicht dieses technische Modell. Im Gegenteil: Es ist sehr gut.
Das Problem entsteht, wenn wir in Europa Anwendungen, Datenbanken und Kubernetes-Cluster unter europäischen Bedingungen betreiben, den gesamten öffentlichen Zugang aber dauerhaft über Infrastruktur kontrollieren lassen, die außerhalb Europas betrieben wird.
Deshalb bauen wir diese Schicht selbst.
Mit eigenem Autonomous System. Eigener Edge-Infrastruktur in der EU. Anycast über mehrere aktive PoPs. Eigenem Routing. Anycast DNS. Loadbalancing. WAF und DDoS-Schutz. Offenen Kubernetes-Schnittstellen. Und der Möglichkeit, Compute und sogar den öffentlichen IP-Adressraum unabhängig vom Plattformanbieter zu halten.
Denn die entscheidende Frage ist nicht nur, wo eine Anwendung läuft.
Sondern wer DNS, IP-Adressen, Routing und den Weg bis zu dieser Anwendung kontrolliert.