Edge-Computing bringt Rechenleistung und Daten näher an Produktion und Filiale. Doch nicht jeder Workload gehört an den Rand des Netzwerks. Latenz, Datenmenge, Autonomie und Betriebsaufwand entscheiden darüber, was direkt am Edge, im lokalen RZ oder zentral im Core bzw. in der Cloud verarbeitet wird.

Eine Maschine erkennt einen Fehler und muss innerhalb von Millisekunden reagieren. Eine Kamera produziert mehr Daten, als sinnvoll über die WAN-Leitung übertragen werden können. Und die Filiale soll weiterarbeiten, auch wenn die Verbindung zum zentralen Rechenzentrum ausfällt. In solchen Fällen liegt es nahe, Anwendungen und Daten dorthin zu bringen, wo sie entstehen: an den Edge.

Doch damit beginnt für IT-Verantwortliche erst das eigentliche Problem. Denn jede Anwendung, die aus dem Rechenzentrum an einen Produktionsstandort oder in eine Filiale wandert, braucht dort Rechenleistung, Storage, Netzwerk und Management. Aus einer zentral beherrschbaren Infrastruktur werden schnell Dutzende oder Hunderte kleine IT-Standorte.

Die entscheidende Frage lautet deshalb nicht, ob Edge-Computing sinnvoll ist. Sondern: Welche Workloads und Daten gehören tatsächlich an den Rand des Netzwerks und welche bleiben besser im Core oder in der Cloud?

Core bezeichnet die zentralisierte IT-Ebene des Unternehmens, typischerweise das zentrale Rechenzentrum oder eine zentrale Private-Cloud-Umgebung. Dort werden Rechenleistung, Storage, Daten und zentrale Dienste für mehrere Standorte gebündelt. Edge-Systeme sind dagegen näher an Maschinen, Sensoren, Filialen oder anderen Datenquellen angesiedelt. Ein lokales RZ am Produktions- oder Filialstandort kann zwischen beiden Ebenen liegen: Es verarbeitet und speichert Daten standortnah, ohne bereits die zentrale Core-Infrastruktur des Unternehmens zu sein.

Wie viel Echtzeit ist wirklich Echtzeit?

Niedrige Latenz gehört zu den klassischen Argumenten für Edge-Computing. Das ist richtig, reicht als Begründung aber nicht aus. Nicht jede Anwendung wird automatisch besser, nur weil sie näher an Maschine, Kamera oder Filiale ausgeführt wird. Entscheidend ist, wie schnell ein System tatsächlich reagieren muss und was passiert, wenn eine Antwort einige Millisekunden oder Sekunden später eintrifft.

Bei zeitkritischen industriellen Prozessen kann dieser Unterschied entscheidend sein. Erkennt etwa ein Kamerasystem einen Produktionsfehler, muss die Information unter Umständen unmittelbar an die Maschine zurückgegeben werden, damit ein fehlerhaftes Werkstück aussortiert oder der Prozess gestoppt wird. Ähnliches gilt für Robotik, fahrerlose Transportsysteme und andere Anwendungen, bei denen schnelle Reaktionen erforderlich sind.

Lokale Verarbeitung verkürzt hier nicht nur den Weg der Daten. Sie reduziert auch die Abhängigkeit von Netzwerkverbindungen und übergeordneten Systemen. Für zeitkritische Anwendungen zählt deshalb nicht allein die durchschnittliche Antwortzeit, sondern ebenso, wie konstant und vorhersehbar sie bleibt.

Je näher die Verarbeitung an der Datenquelle liegt, desto schneller reagiert sie – und desto weniger Rohdaten müssen weiterreisen. (Grafik: KI-generiert mit DALL-E, speicherguide.de)

Bei vielen anderen Workloads spielen ein paar Sekunden dagegen kaum eine Rolle. Eine Anwendung, die Maschinendaten für Wartungsprognosen sammelt oder regelmäßig Zustandswerte berechnet, muss nicht zwingend direkt an der Produktionslinie laufen. Dasselbe gilt für Warenwirtschaft, langfristige Produktionsanalysen oder Reporting.

Eine einfache Leitfrage hilft bei der Einordnung: Was passiert, wenn die Antwort nicht sofort kommt?

Bleibt eine Produktionsanlage stehen, entsteht ein Sicherheitsrisiko oder kann ein Geschäftsvorgang nicht abgeschlossen werden, spricht viel für lokale Verarbeitung. Geht es um Berichte oder Analysen, deren Ergebnis erst Minuten später benötigt wird, ist ein zentraler Betrieb meist einfacher.

Hinzu kommt die Frage nach der Autonomie des Standorts. Eine Produktionslinie sollte nicht automatisch stillstehen, nur weil die WAN-Verbindung zum Rechenzentrum unterbrochen ist. Auch Kassensysteme und andere kritische Filialprozesse müssen je nach Einsatzfall zeitweise ohne zentrale Verbindung weiterarbeiten können.

Damit ergibt sich eine grobe Abstufung: Echtzeitkritische Verarbeitung gehört möglichst nahe an die Datenquelle. Zeitkritische Workloads können am Standort oder in einer regionalen Edge-Infrastruktur laufen. Nicht zeitkritische Aufgaben bleiben häufig besser im Core oder in der Cloud.

Muss es wirklich der Edge sein?

Edge-Computing bedeutet nicht automatisch, dass jede Verarbeitung direkt neben einer Maschine oder Kamera stattfinden muss. Viele Unternehmen verfügen am Produktionsstandort bereits über einen Serverraum oder ein lokales Rechenzentrum. Damit stellt sich eine naheliegende Frage: Warum die IT noch weiter verteilen, wenn Compute und Storage am selben Standort bereits vorhanden sind?

Die Antwort hängt wiederum vom Workload ab. Reichen die Reaktionszeiten des lokalen Rechenzentrums aus und kann die vorhandene Netzwerkinfrastruktur die anfallenden Daten problemlos transportieren, gibt es wenig Grund, zusätzliche Systeme direkt an der Produktionslinie aufzustellen. Ein lokales RZ bietet meist mehr Rechenleistung und Speicherkapazität und lässt sich einfacher betreiben und absichern.

Edge wird interessant, wenn selbst der Weg ins lokale RZ für den jeweiligen Workload zu lang, zu störanfällig oder zu datenintensiv ist. Das betrifft beispielsweise Kamerasysteme, die kontinuierlich große Bildströme erzeugen. Erfolgt die erste Analyse bereits an der Produktionslinie, müssen nur Ergebnisse, Metadaten oder auffällige Bilder weitergeleitet werden. Das entlastet nicht nur die Verbindung zu zentralen Systemen, sondern bereits das lokale Netzwerk.

Hinzu kommt die Verfügbarkeit. Muss eine Maschine unabhängig von übergeordneten IT-Systemen reagieren können, spricht ebenfalls viel dafür, die dafür notwendige Verarbeitung unmittelbar am Prozess anzusiedeln.

Edge und lokales Rechenzentrum schließen sich dabei nicht aus. Am Unternehmensstandort bilden sie unterschiedliche Stufen einer verteilten On-Premises-Architektur. Je zeitkritischer ein Workload und je größer sein Rohdatenstrom, desto näher sollte seine erste Verarbeitung an der Datenquelle liegen. Reicht dagegen die Infrastruktur des Standort-Rechenzentrums aus, bleibt die zentrale Verarbeitung meist die einfachere Lösung.

Latenz, Datenmenge, Autonomie und lokale Datenhaltung zeigen, ob ein Workload besser am Edge, hybrid oder zentral läuft. (Grafik: KI-generiert mit DALL-E, speicherguide.de)

Müssen wirklich alle Daten übertragen werden?

Neben der Latenz spricht vor allem die Datenmenge für eine Verarbeitung am Edge. Maschinen, Sensoren und vor allem Kameras erzeugen Datenströme, bei denen das Prinzip »alles ins Rechenzentrum schicken« schnell unpraktisch oder teuer wird.

Besonders anschaulich ist die visuelle Qualitätskontrolle. Mehrere hochauflösende Kameras können an einer Produktionslinie kontinuierlich große Mengen Bilddaten erzeugen. Werden sämtliche Aufnahmen über das Netzwerk bis in ein zentrales RZ oder in die Cloud übertragen, steigen Bandbreitenbedarf, zentrale Verarbeitung und Speicherbedarf entsprechend.

Die interessantere Frage lautet deshalb: Welche Daten müssen den Standort überhaupt verlassen?

Ein Edge-System kann die erste Verarbeitungsstufe übernehmen. Es analysiert die Bilder vor Ort und übermittelt beispielsweise nur Prüfergebnisse, Metadaten und Aufnahmen auffälliger Werkstücke. Aus einem kontinuierlichen Strom großer Dateien wird so ein deutlich kleinerer Datenstrom.

Das Grundprinzip lautet: erfassen, lokal analysieren, filtern und nur relevante Daten weiterleiten.

Das bedeutet allerdings nicht, dass möglichst viele Rohdaten grundsätzlich gelöscht werden sollten. Daten, die heute unauffällig erscheinen, können später für Qualitätsanalysen, Fehlerrekonstruktionen oder das Training verbesserter KI-Modelle wertvoll sein.

Welche Regeln gelten für die Edge-Architekturen?

Edge-Architekturen brauchen deshalb Regeln für die Datenhaltung. Flüchtige Rohdaten können nach der Verarbeitung verworfen werden. Ereignis- und Metadaten werden gezielt weitergeleitet. Geschäftskritische Informationen müssen zuverlässig geschützt, repliziert oder gesichert werden. Ausgewählte Rohdaten können für Analysen, KI-Training oder langfristige Aufbewahrung ins Core beziehungsweise in die Cloud wandern.

Damit wird Edge Computing zwangsläufig auch zu einem Storage- und Datenmanagement-Thema. Denn sobald Daten lokal bleiben, stellt sich die nächste Frage: Wie viel Storage benötigt der Standort und wie lange muss er Daten puffern können?

Das wird spätestens bei einer unterbrochenen WAN-Verbindung relevant. Fallen mehrere Stunden Verbindung aus, dürfen neu erzeugte Produktionsdaten nicht einfach verloren gehen. Ein Edge-System benötigt dann ausreichend lokale Kapazität, Persistenz und einen definierten Mechanismus, um die Daten später mit zentralen Systemen zu synchronisieren.

Edge ersetzt die Core-Ebene also nicht. Die Ebenen teilen sich die Arbeit. Am Edge erfolgen zeitkritische Verarbeitung, Vorfilterung und kurzfristige Speicherung. Core oder Cloud übernehmen typischerweise Konsolidierung, langfristige Speicherung, übergreifende Analysen und rechenintensive Aufgaben wie das Training größerer KI-Modelle.

Nicht alle Daten müssen im lokalen RZ verarbeitet werden. Am Edge lassen sich die Daten analysieren und filtern, bevor sie zielgerichtet weitergeleitet werden. (Grafik: KI-generiert mit DALL-E, speicherguide.de)

Edge oder Core: Der Workload entscheidet

Die technische Möglichkeit, eine Anwendung am Edge zu betreiben, bedeutet noch nicht, dass sie dort sinnvoll aufgehoben ist. Neben Latenz und Datenmenge spielen Autonomie, Verfügbarkeit, lokale Datenhaltung und Betriebsaufwand eine Rolle.

Maschinennahe Auswertungen und andere zeitkritische Prozesse sind klassische Edge-Kandidaten. Bei der automatischen Auswertung von Bildern und Videos (Computer Vision) liegt zumindest die erste Analyse häufig nahe an der Datenquelle, weil sich dadurch große Bildströme reduzieren lassen. Predictive-Maintenance-Anwendungen können dagegen mehrere Ebenen nutzen: Lokale Systeme erfassen und verdichten Sensordaten, während zentrale Plattformen langfristige Muster über viele Maschinen oder Standorte hinweg analysieren.

Ähnlich sieht es in Filialen aus. Ein Kassensystem benötigt unter Umständen lokale Funktionen, damit der Verkauf auch bei einer WAN-Störung weitergehen kann. Zentrale Warenwirtschaft, langfristige Auswertungen oder unternehmensweite Bestandsplanung profitieren dagegen meist stärker von zentral konsolidierten Daten.

Auch KI lässt sich nicht pauschal einer Ebene zuordnen. Inferenz, also die Anwendung eines trainierten Modells auf aktuelle Daten, kann häufig am Edge erfolgen, wenn schnelle lokale Entscheidungen gefragt sind. Das Training großer Modelle benötigt dagegen meist mehr Rechenleistung und aggregierte Daten aus vielen Quellen und passt damit eher ins Core oder in die Cloud.

Für die Architekturentscheidung helfen fünf Fragen:

• Wie schnell muss die Anwendung reagieren?
• Wie viele Daten erzeugt sie?
• Muss sie ohne WAN-Verbindung funktionieren?
• Welche Daten müssen lokal gespeichert werden?
• Wie viel zusätzlichen Betriebsaufwand verursacht ein dezentraler Betrieb?

Je stärker kurze Reaktionszeiten, große lokale Datenmengen oder autonome Abläufe für eine Anwendung sprechen, desto näher sollte die Verarbeitung an die Datenquelle rücken. Fehlen diese Anforderungen, ist die zentrale Infrastruktur meist die einfachere Wahl.

Die Grenzen sind dabei nicht starr. Gerade hybride Architekturen verteilen einzelne Verarbeitungsschritte desselben Workloads auf mehrere Ebenen.

Die Kehrseite: Aus Außenstellen werden kleine Rechenzentren

Mit jedem Workload, der an den Edge wandert, verlagert sich allerdings auch Infrastruktur. Compute und Storage müssen überwacht, aktualisiert und abgesichert werden. Für lokale Daten braucht es Regeln für Replikation, Backup und Recovery. Hardware kann ausfallen, Anwendungen müssen sich wiederherstellen lassen.

Das ist bei einem Standort überschaubar. Bei 50 Fabriken oder mehreren hundert Filialen wird daraus eine Managementaufgabe. Der Edge soll möglichst autonom funktionieren, gleichzeitig aber zentral kontrollierbar und standardisiert bleiben. Hinzu kommt, dass an vielen Standorten kein eigenes IT-Personal zur Verfügung steht.

Deshalb sollte die Entscheidung für Edge nicht mit der Frage beginnen, welche Hardware sich dort aufstellen lässt. Sinnvoller ist es, zuerst den Workload und seine Daten zu betrachten. Nur wenn Latenz, Datenvolumen, Autonomie oder andere Anforderungen eine Verarbeitung nahe an der Datenquelle rechtfertigen, sollte zusätzliche Infrastruktur an den Rand wandern.

Edge und Core sind keine Gegensätze. Entscheidend ist, welcher Teil eines Workloads wo am sinnvollsten läuft – nahe an der Datenquelle oder zentral.

Und je stärker der Edge wächst, desto wichtiger wird anschließend die zweite Frage: Wie lassen sich Dutzende oder Hunderte dieser kleinen Rechenzentren sicher und effizient betreiben?