Das Volumen der am Edge erzeugten Daten wird zu groß sein, als dass ihre Analyse komplett in der Public Cloud erfolgen wird. Ein neuer Ansatz muss her, der aus dem industriellen Internet der Dinge echtes Edge Computing macht – allen Ressourcenbeschränkungen der Geräte zum Trotz.
Selten sind sich Analysten so einig wie beim Thema Edge Computing: Schon in den kommenden Jahren wird die Anzahl an intelligenten Edge-Systemen im zweistelligen Milliardenbereich liegen. Und diese Geräte am Netzwerkrand werden jährlich 100 Zettabytes und mehr an Daten erzeugen, also mehr als hundert Milliarden Gigabytes.
Solche Schätzungen scheinen zu groß, um wahr zu sein. Aber eine einzige Glühbirne allein erzeugt 86.400 Datenpunkte am Tag, wenn sie in einem Szenario zur Überwachung der Gebäudeausstattung einmal in der Sekunde ihren Status meldet. Wenn man bedenkt, dass in einem Bürohaus Tausende von Glühbirnen installiert sind, erscheint die prognostizierte Größenordnung von IoT-Daten plötzlich realistisch. Doch sollte die Glühbirne statt Zehntausenden Daten nicht lieber nur einmal die Information übertragen, dass sie das Ende ihrer Lebensdauer erreicht hat?
Bei solchen Datenmengen ist das Versprechen der Echtzeit-Überwachung und -Analyse nur sehr schwer zu halten – allen beeindruckenden Leistungsdaten von 5G- und 6G-Netzen zum Trotz. Nicht nur Latenzzeiten und Übertragungsunterbrechungen, sondern auch Anwendungsszenarien sprechen dagegen, bei denen eine ununterbrochene Verbindung der Edge-Geräte mit der zentralen IT gar nicht möglich ist. Sie stellen damit die bis vor kurzem vorherrschende Vorstellung infrage, dass das Computing der Edge-Daten ausschließlich in der Public Cloud stattfindet und stattfinden kann. Hinzu kommen Überlegungen wie Datenschutz und -sicherheit, aber auch der Schutz des geistigen Eigentums, die eine andere, verteiltere Architektur nahelegen.
Von Edge Computing zu Embedded Analytics
Zudem hängt der Erfolg des Edge Computing nicht allein von den Möglichkeiten ab, Unmengen von Daten zu sammeln, zu übertragen, zu speichern und gegen Angriffe von außen zu sichern. Vielmehr kommt es auf die Fähigkeit an, diese Daten zu analysieren. Wenn aber nicht sämtliche Daten über das Netz geschickt werden können und dies aus unterschiedlichen Gründen gar nicht sinnvoll ist, dann kann auch die Intelligenz nicht allein in der zentralen IT, ob im eigenen Rechenzentrum oder in der Public Cloud, beheimatet sein. Das bedeutet, dass zumindest ein Teil der Analysefähigkeiten dort vorhanden sein muss, wo die Daten erzeugt und gesammelt werden, nämlich am Netzwerkrand, d. h. in der Produktionshalle, in einer Maschine oder Anlage, an Transportbändern, in Containern etc.
Dieser Befund wirft sofort eine Reihe von Fragen auf: Wie sieht es mit der Ressourcenausstattung der Edge-Geräte aus? Wieviel Rechen- und Speicherkapazitäten stehen darin zur Verfügung? Wie stabil und leistungsfähig ist ihre Netzwerkanbindung? Wie lässt sich Analysesoftware auf den Geräten implementieren und wie lassen sich Software und Firmware aktualisieren? Und schließlich: Wie lässt sich das Funktionieren der Software und des Geräts überwachen?
Darüber hinaus stellt sich noch eine weitere Frage, die vielleicht sogar am wichtigsten ist: Was sind die auf und von den Edge-Geräten zu erledigenden Analysen, die für das jeweilige Anwendungsszenario notwendig sind? Abhängig von der Antwort auf diese Frage kommt zu den Leistungsdaten des Netzes die Ressourcenausstattung der Edge-Geräte als limitierender Faktor beim Edge Computing hinzu. Diese Ausstattung muss ausreichen, damit der Programmcode für die Analysen tatsächlich in der gewünschten Geschwindigkeit und mit der notwendigen Zuverlässigkeit ausgeführt wird. Dabei gilt die Faustregel: Je geringer die Ressourcen und je umfangreicher die Analysen sind oder beides, desto ressourcenschonender muss der Programmcode sein. Dieser sparsame Umgang mit Ressourcen ist die Voraussetzung dafür, dass sich Analysefähigkeiten auf den Edge-Geräten einbetten lassen, die Voraussetzung für Embedded Analytics.
Weniger Schichten, mehr Effizienz
Die Ressourceneffizienz des Programmcodes hängt sowohl von der Programmiersprache als auch vom Entwicklungsframework ab. Unter beiden Aspekten ist Flogo, eine quelloffene Umgebung für Anwendungsentwicklung, ein vielversprechender Ansatz, der sich auch in der Praxis bewährt. Dank Flogo können sich Entwickler ausschließlich auf die Programm-Logik für die Datenanalyse konzentrieren. Gleichzeitig befreit sie die Umgebung von den lästigen Aufgaben der App-Entwicklung für den Produktivbetrieb wie die Anbindung an ereignisgesteuerte Messaging-Plattformen, Datenspeicher oder andere Anwendungen.
Flogo basiert auf der Programmiersprache Go-Lang. Deren besonderes und im Kontext von Edge Computing so wertvolles Kennzeichen ist, dass die ausführbaren Binärdateien, die damit erstellt werden, ausschließlich und genau diejenigen Komponenten enthalten, die zum Ausführen der Programmlogik notwendig sind. Zusätzliche Schichten zwischen der Hardware und dem Betriebssystem einerseits und der Applikation andererseits werden dadurch überflüssig. Gerade diese Zwischenschichten aber sind es, die im Vergleich zu Flogo den Ressourcenverbrauch in die Höhe treiben. Die Tatsache, dass die Flogo-Binärdateien nur die erforderlichen Bibliotheken enthalten, erlaubt, den Arbeitsspeicherverbrauch drastisch zu senken: von Megabytes auf Kilobytes!
Die Anwendungen selbst lassen sich mit dem Flogo-Framework auf zwei Arten entwickeln: Zero-Code und All-Code. Das heißt, auch Nicht-Programmierer können aus vorgefertigten und grafisch dargestellten Programmbausteinen Applikationen zusammenstellen, die dann automatisch in Binärdateien zur Ausführung bereitstehen. Entwickler wiederum können mittels Flogo nicht nur komplette Programme codieren, sondern auch die verschiedenen Programmbausteine für ihre Kollegen, die nicht über Programmierkenntnisse verfügen, bereitstellen.
Weniger Footprint, mehr Geschwindigkeit
Sie sind dabei frei bei der Wahl der Entwicklungsumgebung (IDE) oder arbeiten schlicht mit einem Texteditor. Mittels Flogo erstellte Anwendungen erweisen sich auch gegenüber im IoT-Umfeld beliebten und maschinennahen Programmiersprachen wie zum Beispiel Python als äußerst effizient. Das betrifft sowohl die Ablaufgeschwindigkeit als auch die Belastung des Arbeitsspeichers, die Anzahl der Transaktionen pro Sekunde und die in Millisekunden gemessenen Antwortzeiten. Diese Vorteile gelten auch für kleine Anwendungen in der Größe von 100 und mehr Kilobytes, die für Analysen auf den Edge-Geräten selbst von besonderem Interesse sind.
Mit Flogo lassen sich Anwendungen für alle gängigen Betriebssysteme kompilieren – Windows, MacOS und Linux (inklusive für ARM-Architekturen) – und direkt auf den Edge-Geräten ausführen. Der Vollständigkeit halber sei hier aber erwähnt, dass sich Flogo-Apps darüber hinaus containerisieren und als Docker-Image auf jedem produktiven PaaS-System, ob Kubernetes, Openshift, Swarm, Mesos etc., aber auch als AWS Lambda-Funktion im Rahmen eines Full-Serverless-Ansatzes ausführen lässt. Damit trägt Flogo dem Gedanken einer verteilten Analytics-Landschaft vom Edge-Gerät wie zum Beispiel einer Linux-basierenden Sensoreinheit oder Kamera bis zur zentralen IT im Rechenzentrum oder in der Public Cloud vollumfänglich Rechnung.
Flogo macht es also in der Tat möglich, Analysefunktionalitäten auf beliebig vielen Edge-Geräten zu implementieren und Menge wie Zeitpunkt der Datenübertragung vom Edge in die zentrale IT gezielt und bezogen auf den jeweiligen Anwendungsfall zu bestimmen. So könnten etwa von einem Sensor in einer Produktionsanlage nur dann Daten an die Zentrale weitergeleitet werden, wenn sie einen bestimmten Schwellenwert über- oder unterschreiten.
Die Auswertung dieser Fehlermeldung könnte dann einen Alarm an die Wartungsmannschaft auslösen, um einen Ausfall und längeren Stillstand der Anlage zu verhindern. Weniger kritische Informationen ließen sich auf einer Zwischenebene, einer Art Edge-Computing-Gateway vor Ort in der Produktionshalle analysieren und von dort an die Werker weiterleiten. Darüber hinaus könnte das Gateway als Zwischenspeicher auch für die unkritischen Sensordaten dienen, die dann in bestimmten Intervallen an die Zentrale übermittelt werden, um den gesamten historischen Datenbestand zu untersuchen und daraus neue Erkenntnisse zur Produktionsoptimierung zu gewinnen. Diese Datenübertragung würde idealerweise zu Zeiten niedriger Netzwerkauslastung erfolgen.
Je größer die Anzahl der Edge-Geräte, auf denen Programmlogik implementiert ist, umso besser müssen diese Geräte verwaltet werden. Zu diesem Zweck bietet Flogo eine Reihe von Schnittstellen zu Konfigurationsmanagementsystemen wie Consul, Zookeeper oder Spring Cloud Config sowie zu Prometheus, einem Open-Source-Projekt der Cloud Native Computing Foundation (CNCF). Prometheus lässt sich so konfigurieren, dass damit Kennzahlen zu Flogo-Anwendungen erhoben und gespeichert werden. Zudem lassen sich die Apps damit überwachen und Alarme auslösen. Diese kostenpflichtige Schnittstelle lässt sich darüber hinaus für die Integration mit weiteren Drittlösungen nutzen.
Ulrich Hatzinger ist Senior Solutions Consultant Central Europe bei Tibco Software.
