Edge und Compute: Zwei Schichten moderner Anwendungsarchitektur

TL;DR

Eine belastbare Edge-Compute-Architektur trennt den öffentlichen Eingang von der eigentlichen Anwendungsausführung. Die Edge Cloud übernimmt Routing, Schutz, TLS-Terminierung und Lastverteilung. Compute-Plattformen führen Workloads aus. Diese Trennung reduziert Kopplungen, verbessert Failover-Optionen und erlaubt, Anwendungen unabhängig vom zugrunde liegenden Cluster oder Provider zu betreiben.

Einleitung

Viele Plattformarchitekturen behandeln den Loadbalancer vor dem Cluster als Teil der Compute-Infrastruktur. Das wirkt zunächst effizient, erzeugt aber eine enge Kopplung zwischen öffentlicher Erreichbarkeit und Anwendungsausführung. Fällt der Cluster aus, werden dadurch oft auch Routing, Schutzmechanismen und der Zugang zu alternativen Backends mitgerissen. Eine Edge-Compute-Architektur trennt deshalb zwei Verantwortungsbereiche: Die Edge stellt den kontrollierten öffentlichen Eingang für Anwendungen und APIs bereit. Die Compute-Infrastruktur führt die Workloads aus. Diese Unterscheidung ist keine rein organisatorische Frage, sondern beeinflusst Verfügbarkeit, Security, Migrationen und den laufenden Betriebsaufwand.

1. Unterschiedliche Aufgaben erfordern unterschiedliche Schichten

Die Edge verarbeitet eingehenden Traffic, bevor er ein Backend erreicht. Dazu gehören Anycast-basiertes Layer-4- und Layer-7-Loadbalancing, DNS-Auflösung, TLS Termination, Web Application Firewall und DDoS Protection. Backend Health Checks entscheiden, ob ein Ziel erreichbar ist; Failover-Mechanismen können Traffic zu einem anderen verfügbaren Backend lenken. Die Compute-Schicht hat eine andere Aufgabe: Sie stellt Runtime, Netzwerk innerhalb der Plattform, Speicher und Ressourcen für Anwendungen bereit.

Diese Trennung schafft klare Verantwortlichkeiten. Das Edge-Team kontrolliert öffentliche Endpunkte, Routing und Schutz. Das Plattform- oder Anwendungsteam verantwortet Workloads, Deployments und deren interne Abhängigkeiten. Fehler lassen sich dadurch besser eingrenzen. Ein fehlerhaftes Deployment muss nicht automatisch die gesamte öffentliche Zugangsschicht verändern. Umgekehrt kann die Edge weiterarbeiten, auch wenn ein einzelner Cluster gewartet wird oder nicht verfügbar ist.

2. Entkopplung reduziert Abhängigkeiten im Betrieb

Wird der öffentliche Zugang direkt an einen einzelnen Cluster oder Cloud-Provider gebunden, entstehen technische und organisatorische Lock-ins. Ein Wechsel der Compute-Plattform kann dann Änderungen an DNS, IP-Adressen, Zertifikaten, Firewall-Regeln und Traffic-Verteilung auslösen. Zusätzlich müssen Anwendungen während Migrationen häufig parallel erreichbar bleiben. Das erhöht die Komplexität gerade dann, wenn Stabilität besonders wichtig ist.

Eine eigenständige Edge Cloud bildet dagegen eine stabile Eingangsschicht vor unterschiedlichen Backends. Die ayedo Edge Cloud kann mit ayedo Managed Kubernetes , eigenen [Kubernetes]-Clustern oder Clustern bei anderen Providern eingesetzt werden. Backend Cloaking verhindert dabei, dass interne Zielstrukturen zum öffentlichen Bestandteil der Anwendung werden. Bring Your Own IP kann die Trennung zusätzlich unterstützen, wenn bestehende Adressräume als Teil der externen Erreichbarkeit erhalten bleiben sollen. Die Compute-Infrastruktur bleibt austauschbarer, ohne dass der öffentliche Zugang neu entworfen werden muss.

3. Hochverfügbarkeit beginnt vor dem Cluster

Hochverfügbarkeit wird häufig ausschließlich innerhalb der Compute-Plattform betrachtet: mehrere Instanzen, verteilte Nodes und automatisierte Restarts. Diese Maßnahmen lösen jedoch nicht jedes Problem. Wenn DNS, öffentlicher Loadbalancer oder Schutzschicht an derselben Plattform hängen wie die Anwendung, bleibt ein gemeinsamer Ausfallpfad bestehen. Ein redundanter Cluster ist dann nur so erreichbar wie die davorliegende Infrastruktur.

Eine Edge-Schicht mit eigener Netzwerk-Infrastruktur, eigenem Autonomous System, verteilter Multi-PoP-Architektur und Aktiv-Aktiv-Prinzip adressiert diesen Bereich separat. Anycast kann Anfragen an verfügbare Edge-Standorte führen. Health Checks liefern die Grundlage, um nicht erreichbare Backends aus der Verteilung zu nehmen. Dabei ersetzt die Edge keine redundante Anwendungsausführung: Sie kann keinen fehlerhaften Datenbankzustand reparieren und keine fehlenden Workload-Replikate bereitstellen. Sie sorgt jedoch dafür, dass Routing, Schutz und Failover nicht unnötig an einen einzelnen Compute-Ausfall gekoppelt sind.

4. Ein Schichtenmodell verbessert Security und Veränderbarkeit

Security-Funktionen sollten möglichst vor der Anwendung greifen. Die Edge kann TLS-Verbindungen terminieren, HTTP- und HTTPS-Traffic durch eine Web Application Firewall prüfen und DDoS-Angriffe an der Edge abwehren. Durch Backend Cloaking bleiben interne Endpunkte verborgen. Proxy Protocol kann zusätzliche Verbindungsinformationen an Backends weitergeben, wenn Anwendungen oder nachgelagerte Systeme die ursprüngliche Client-Verbindung auswerten müssen.

Für die Compute-Schicht bedeutet das eine klar definierte Eingangsgrenze. Anwendungen müssen nicht selbst jede öffentliche Schutzfunktion implementieren, behalten aber die Verantwortung für Authentisierung, Autorisierung und anwendungsbezogene Validierung. Gleichzeitig lassen sich Routingregeln, Zertifikatswechsel oder Backend-Failover unabhängig von einem Workload-Release betreiben. Das verkürzt nicht automatisch jede Änderung, reduziert aber den Umfang notwendiger Abstimmungen zwischen Netzwerk-, Security- und Anwendungsteams.

Architektur- und Betriebsszenario

Ein Unternehmen betreibt eine API in einem eigenen Kubernetes -Cluster und hält eine zweite Umgebung bei einem anderen Provider für Wartung und Failover vor. Ohne separate Edge-Schicht müssten DNS, externe Adressen und Schutzregeln eng an die jeweiligen Ingress-Komponenten der Cluster gekoppelt werden. Ein Wechsel der aktiven Umgebung wird dadurch zu einer Infrastrukturänderung mit mehreren Fehlerquellen.

Mit einer Edge Cloud bleibt der öffentliche Endpunkt unverändert. Die Edge terminiert TLS, prüft den Traffic, führt Health Checks aus und verteilt Anfragen auf die verfügbaren Backends. Kubernetes bleibt für Deployment und Skalierung der API zuständig. Die Edge muss dabei nicht wissen, wie die Anwendung intern betrieben wird. Genau diese Entkopplung reduziert den Koordinationsaufwand bei Wartung, Migration und Providerwechsel.

FAQ

Ist die Edge Cloud ein Ersatz für Kubernetes?

Nein. Kubernetes führt Workloads aus und verwaltet deren Ressourcen. Die Edge Cloud stellt den öffentlichen Zugang, Schutz, Routing und Lastverteilung vor diesen Workloads bereit.

Muss Compute bei ayedo betrieben werden?

Nein. Die ayedo Edge Cloud kann auch mit eigenen [Kubernetes]-Clustern oder mit Clustern anderer Provider eingesetzt werden.

Verhindert die Trennung jede Auswirkung eines Backend-Ausfalls?

Nein. Die Edge kann Traffic umleiten oder nicht erreichbare Backends aus der Verteilung nehmen. Anwendung, Datenhaltung und fachliche Ausfallsicherheit bleiben Aufgaben der Compute-Architektur.

Fazit

Edge und Compute sollten als eigenständige Schichten geplant werden, weil sie unterschiedliche technische Ziele verfolgen. Die Edge kontrolliert den öffentlichen Eingang und schützt ihn; Compute stellt die Anwendungsausführung bereit. Diese Trennung verbessert die Austauschbarkeit von Clustern und Providern, schafft klarere Betriebsgrenzen und reduziert gemeinsame Ausfallpfade. Die ayedo Edge Cloud ist in diesem Modell keine vorgelagerte Funktion eines bestimmten [Kubernetes]-Angebots, sondern eine eigenständige Plattform für Routing, Schutz und Zugang vor unterschiedlichen Compute-Umgebungen.