Die Wolke wird nicht verschwinden. Doch die Idee, dass alles in einem zentralen Rechenzentrum laufen muss, Hunderte von Kilometern vom Ort der Datengenerierung entfernt, zeigt langsam ihre Risse. Wenn eine Produktionslinie einen Defekt in Echtzeit erkennen muss, wenn ein autonomes Fahrzeug in Millisekunden beschließt, zu bremsen, oder wenn ein Einzelhändler Lagerbestände verarbeiten muss, ohne auf eine stabile Konnektivität angewiesen zu sein, ist die Round-Trip-Latenz zur Cloud kein technisches Detail – es ist ein Geschäftsproblem mit direkten Folgen für den Betrieb.
Warum Zentralisierung ihren Preis hat
Die öffentliche Cloud eignet sich außerordentlich gut für Workloads, die Latenzzeiten von mehreren zehn Millisekunden tolerieren, über Bandbreite für die kontinuierliche Datenübertragung verfügen und keinen strengen Einschränkungen hinsichtlich des Speicherorts der Daten unterliegen. Bei allem, was nicht dieser Beschreibung entspricht, beginnt die Zentralisierung gegen Sie zu wirken.
Ein typischer Industriesensor kann Gigabyte an Daten pro Stunde erzeugen. All dies an die Cloud zu senden, zu verarbeiten und eine Entscheidung zurückzugeben, kostet nicht nur viel Bandbreite, sondern ist auch zu langsam für jeden Prozess, der eine Reaktion in Echtzeit erfordert. Hier ist das zentralisierte Modell nicht nur ineffizient; er ist unrentabel. Die Latenz ist im aktuellen Modell nicht optimierbar, da das Problem physikalischer Natur ist: Für elektromagnetische Signale gilt eine Geschwindigkeitsbegrenzung.
Die Datensouveränität fügt eine weitere Ebene hinzu. Vorschriften wie LGPD, aber auch sektorale Vorschriften im Gesundheitswesen, im Finanzwesen und in kritischen Infrastrukturen schränken oder erschweren die Übermittlung bestimmter Datenkategorien an Server außerhalb des kontrollierten Umkreises. Die Verarbeitung lokal oder am Rande des Netzwerks ist keine architektonische Option mehr und wird zu einer regulatorischen Anforderung.
Was Edge Computing eigentlich ist
Unter Edge Computing versteht man die Verlagerung eines Teils der Rechenkapazität an Punkte, die sich physisch in der Nähe der Datenquelle befinden – die Fabrikhalle, die Antenne eines 5G-Turms, die Verkaufsstelle einer Einzelhandelskette, die in ein Fahrzeug integrierte Hardware. Anstatt dass jedes einzelne Datenelement den ganzen Weg in die zentrale Cloud wandert, findet ein erheblicher Verarbeitungsaufwand statt, bevor die Daten überhaupt die Umgebung verlassen, in der sie generiert wurden.
Dies ersetzt nicht die Cloud. Es ersetzt einen bestimmten Teil dessen, was die Cloud getan hat: den Teil, der eine schnelle Reaktion erfordert, der sensible Daten lokal verarbeitet oder der nicht auf eine ständige Konnektivität angewiesen sein kann. Die zentrale Cloud bleibt der Ort, an dem Sie den Verlauf zusammenfassen, Modelle trainieren und das Gesamtbild orchestrieren. Der Rand ist der Ort, an dem Sie agieren.
Hier erscheint die Unterscheidung zwischen Edge- und Fog-Computing. Fog ist eine mittlere Schicht – Server in einer Umspannstation, in einem regionalen Lager –, die Daten von mehreren Geräten aggregiert, bevor sie an die Cloud gesendet wird. Kante ist der dem Ursprung am nächsten mögliche Knoten. In der Praxis kombinieren viele Architekturen beides.
Wo Edge Computing das Spiel verändert
Die Herstellung ist der klarste Fall. Computer Vision in Echtzeit, Erkennung von Anomalien in der Ausrüstung, Anpassung von Produktionsparametern mithilfe von Sensoren – all dies erfordert eine Reaktion in Millisekunden, die die zentrale Cloud nicht liefern kann. Edge-Prozessoren in der Fabrikhalle lösen das Latenzproblem, ohne die Verbindung zu zentralen Managementsystemen zu beeinträchtigen.
Telekommunikation und 5G sind ein weiterer Vektor. Betreiber bauen Verarbeitungskapazitäten in ihren eigenen Türmen auf, die es ihnen ermöglichen, Anwendungen direkt am Rande des Netzwerks des Betreibers auszuführen. Für Cloud-Gaming, ferngesteuerte Chirurgie, industrielle Augmented Reality – alles, was eine Latenzzeit von weniger als 10 Millisekunden benötigt – ist diese Architektur die einzige, die funktioniert.
Der physische Einzelhandel weist besondere Herausforderungen in Bezug auf Konnektivität und lokale Verarbeitung auf. Autonome Kassensysteme, kamerabasierte Bestandsüberwachung, Echtzeit-Personalisierung im Regal – diese Anwendungen können es kaum erwarten, bei jedem Videobild eine Antwort aus der Cloud zu erhalten. Die Verarbeitung im Geschäft mit regelmäßiger Synchronisierung löst das Problem.
Autonome Fahrzeuge sind vielleicht das dramatischste Beispiel. Das Auto muss in Sekundenbruchteilen Entscheidungen auf der Grundlage von Kameras, Lidar und Radar treffen. Das Warten auf die Cloud ist keine akzeptable technische Einschränkung – es ist ein physisches Sicherheitsproblem. Sämtliche Wahrnehmungs- und Entscheidungsprozesse finden im Fahrzeug statt, ohne Netzwerkabhängigkeit.
So erstellen Sie eine Edge-Architektur, ohne den Betrieb zu fragmentieren
Das größte Risiko am Rande ist nicht technologischer Natur. Es ist betriebsbereit. Die Verteilung der Rechenkapazität auf Dutzende, Hunderte oder Tausende von Knoten führt zu einer Komplexität, die die Vorteile überwiegen kann, wenn die Architektur nicht von Anfang an darauf ausgelegt ist.
Die erste Entscheidung besteht darin, zu definieren, welche Prozesse wo stattfinden. Nicht alles, was auf der Kante laufen kann, sollte auch auf der Kante laufen. Hochfrequenzverarbeitung mit geringer Latenz gehört an den Rand. Historische Aggregation, Modelltraining, globale Korrelationen gehören zur zentralen Cloud. Wenn Sie diese Unterteilung klar halten, vermeiden Sie die Duplizierung der Logik und die Entstehung von Inkonsistenzen zwischen den Umgebungen.
Das zweite Problem ist die Orchestrierung. Die Verwaltung von Softwareaktualisierungen auf verteilten Knoten erfordert eine andere Bereitstellungsstrategie als die in der Cloud verwendete. Lösungen wie Kubernetes in Hybridkonfigurationen oder Plattformen für das Edge-Management wie AWS IoT Greengrass oder Azure IoT Edge bieten zentralisierte Sichtbarkeit, ohne dass an jedem Knoten ein manueller Eingriff erforderlich ist.
Das dritte ist das Datenmodell. Was synchronisiert wird, wann es synchronisiert wird und wie Konflikte gelöst werden, muss vor dem Erstellen entschieden werden. Edge Computing ist keine Erweiterung der Cloud – es ist eine verteilte Architektur mit allem, was dieser Begriff impliziert: Partitionierung, letztendliche Konsistenz, lokale Zustände, die konvergieren müssen.
Auch die Sicherheit in verteilten Umgebungen verändert ihr Profil. Jeder Edge-Knoten ist eine physische Angriffsfläche. Verschlüsselung im Ruhezustand und während der Übertragung, gegenseitige Authentifizierung zwischen Knoten und der Cloud sowie die Möglichkeit, ein gefährdetes Gerät aus der Ferne zu deaktivieren, müssen alle im Architekturplan enthalten sein, bevor es in die Produktion geht.
Lesen Sie auch
- Edge Computing: Warum verteilte Verarbeitung Ihre Architektur neu definieren wird
- Edge Computing-Architektur: Strategien für die verteilte Verarbeitung
- Edge Computing in Fabriken: Wenn lokale Verarbeitung sinnvoller ist
- RISC-V am Edge und IoT: Warum offene Architektur wichtig ist
- Autonomes Rechnen: wenn das System sich selbst korrigiert, bevor Sie den Fehler bemerken
- Energie: Der Engpass, den niemand auf die Computing-Roadmap gesetzt hat