Eigene Logik auf der Edge
Die Entwicklung eigener Module mit Azure IoT Edge bringt in der Praxis häufig Herausforderungen mit sich, etwa begrenzte Skalierbarkeit, fehlendes zentrales State Management und aufwendige Update-Prozesse. Mit Azure IoT Operations entsteht eine neue Grundlage für den Betrieb moderner IoT-Anwendungen. Durch den Einsatz offener Standards und einer Kubernetes-basierten Infrastruktur lassen sich verteilte Systeme robuster und effizienter umsetzen. Das erleichtert nicht nur den Roll-out neuer Funktionen, sondern ermöglicht auch ein konsistentes Betriebsmodell über verschiedene Standorte und Umgebungen hinweg. Besonders in Szenarien mit vielen Edge-Geräten und komplexen Datenflüssen sorgt dieser Ansatz für mehr Kontrolle, Stabilität und Erweiterbarkeit.
Dieser Beitrag schließt inhaltlich an die Informationen aus dem Artikel „IoT neu eingebunden“ an.
Modulentwicklung im Wandel: Was Azure IoT Operations besser macht
Eigene Module ermöglichen es, individuelle Logik direkt auf der Edge auszuführen. Sie kommen überall dort zum Einsatz, wo zum Beispiel Telemetrie verarbeitet, Daten aggregiert oder externe Systeme angebunden werden sollen. Unter Azure IoT Edge war dies grundsätzlich möglich, jedoch mit einigen Einschränkungen verbunden. Besonders in größeren oder dynamischen Umgebungen zeigten sich schnell Grenzen in Bezug auf Skalierbarkeit, Zustandsverwaltung und die Flexibilität von Deployments. Diese Aspekte erschwerten nicht nur den stabilen Betrieb an sich, sondern auch die Weiterentwicklung und Wartung der Lösung im laufenden Betrieb.
Azure IoT Operations verfolgt hier einen anderen, deutlich moderneren Ansatz. Auch in diesem Modell werden Module weiterhin als Container ausgeführt, profitieren nun aber von den Vorteilen einer Kubernetes-basierten Infrastruktur. Das bedeutet, dass Deployments deutlich flexibler gestaltet werden können, sich horizontal skalieren lassen und durch den Einsatz von GitOps deklarativ verwaltet werden können. Änderungen an der Umgebung oder der Modulkonfiguration lassen sich damit versioniert und reproduzierbar umsetzen, was besonders in komplexen Edge-Topologien von Vorteil ist.
Ergänzend dazu stellt das IoT Operations SDK eine Sammlung von Funktionen bereit, die speziell auf die Anforderungen verteilter Edge-Szenarien zugeschnitten sind. Dazu gehören unter anderem eine MQTT-basierte Kommunikation für eine effiziente und zuverlässige Datenübertragung, integriertes State Management für den konsistenten Umgang mit Zuständen über mehrere Instanzen hinweg sowie die Möglichkeit, eigene Discovery Handler für Akri zu implementieren. Letzteres erlaubt es, spezifische Geräte oder Dienste automatisch zu erkennen und dynamisch in das System einzubinden.
Im weiteren Verlauf wird gezeigt, wie sich eigene Module mit Azure IoT Operations praktisch umsetzen lassen. Es wird erläutert, welche Werkzeuge und Konzepte zur Verfügung stehen, auf welche Weise typische Herausforderungen wie Zustandsverwaltung, Telemetrieverarbeitung und Deployment gelöst werden können und worauf bei der Umsetzung in produktiven Szenarien besonders zu achten ist.
Grenzen eigener Module unter IoT Edge
Azure IoT Edge bietet die Möglichkeit, eigene Module zu entwickeln und Logik direkt auf der Edge auszuführen. In der praktischen Umsetzung zeigen sich dabei jedoch weiterhin strukturelle Einschränkungen, insbesondere wenn es um Skalierbarkeit, Ausfallsicherheit und Wartbarkeit geht.
Ein wesentliches Problem ist die fehlende Unterstützung für horizontale Skalierung. Jedes Modul wird exakt einmal pro Gerät ausgeführt, unabhängig von der verfügbaren Rechenleistung oder dem zu verarbeitenden Datenvolumen. Eine Lastverteilung über mehrere Instanzen hinweg ist nicht vorgesehen. Das macht es schwierig, Module für größere Datenmengen oder mit Anforderungen an Redundanz und Hochverfügbarkeit auszulegen.
Auch bei der Aktualisierung von Modulen stößt man schnell an Grenzen. Neue Versionen werden über IoT Hub Deployments ausgerollt. Dabei wird das laufende Modul gestoppt und durch die neue Version ersetzt. Ein unterbrechungsfreier Übergang oder ein kontrollierter Roll-out mit mehreren Versionen parallel, wie zum Beispiel in Form von Canary Releases oder Blue-Green Deployments, ist auf diesem Weg nicht realisierbar.
Ein weiterer zentraler Punkt ist das fehlende integrierte State Management. Für die Speicherung von Zuständen oder Zwischenergebnissen müssen eigene Lösungen entwickelt werden, meist auf Basis lokaler Datenbanken, Caches oder externer Speicher. Diese Ansätze führen zu hohem Wartungsaufwand, fehlender Standardisierung und eingeschränkter Wiederverwendbarkeit von Modulen. Häufig entstehen dabei isolierte Speicherlösungen pro Modul, was zusätzlich zu einer fragmentierten Architektur führt.
Auch das Secret Management ist nur eingeschränkt möglich. Zugangsdaten, Zertifikate oder Konfigurationen müssen entweder als Umgebungsvariablen übergeben oder über individuelle Mechanismen aus einem Azure Key Vault geladen werden. Eine zentrale, integrierte Verwaltung für Secrets existiert nicht, was die Sicherheit und den operativen Aufwand negativ beeinflusst.
Diese Einschränkungen machen es nach wie vor schwierig, eigene Module in größeren, dynamisch wachsenden IoT-Umgebungen effizient, skalierbar und wartbar zu betreiben. Azure IoT Operations adressiert genau diese Schwachstellen und bietet moderne Ansätze für den Aufbau robuster und erweiterbarer IoT-Anwendungen.
Eigene Module unter IoT Operations
Eigene Module in Azure IoT Operations sind einfache Docker-Container, die im Kubernetes-Cluster ausgeführt werden. Im Vergleich zu IoT Edge ist der Einstieg sogar einfacher, da keine spezielle SDK-Integration erforderlich ist. Die Kommunikation mit dem MQTT Broker funktioniert mit jedem beliebigen MQTT-Client. Was es hier zu beachten gibt, kann in der offiziellen Doku nachgelesen werden. Wer jedoch zusätzliche Funktionen wie State Management oder Leader Election nutzen möchte, kann auf das IoT Operations SDK zurückgreifen, das in .NET, Go und Rust verfügbar ist.
Durch die Kubernetes-Orchestrierung ergeben sich neue Möglichkeiten, etwa die Replikation eines Moduls über mehrere Instanzen hinweg. Damit lassen sich sowohl horizontale Skalierung als auch Ausfallsicherheit realisieren. Gleichzeitig entstehen neue Herausforderungen, etwa bei der Koordination von gemeinsam genutztem Zustand oder beim Zugriff auf geteilte Ressourcen. Das SDK stellt dafür fertige Komponenten bereit, darunter einen State Store, der über MQTT Version 5 arbeitet. Zustände können als Key-Value-Paare gespeichert und zwischen Instanzen geteilt werden.
In Szenarien mit mehreren Instanzen eines Moduls muss eine Instanz die Koordination übernehmen. Diese Rolle übernimmt der sogenannte Leader. Auch gemeinsame Sperren, sogenannte Locks, lassen sich über das SDK verwalten, um den Zugriff auf geteilte Ressourcen zu steuern. Wer zwischen Modulen Methoden aufrufen möchte, wie es unter IoT Edge über Direct Method Calls möglich war, kann dies über Remote Procedure Calls auf Basis von MQTT Request Response Pattern umsetzen.
Das Abbilden eines Device Twin ist aktuell nicht nativ integriert, kann aber über retained MQTT-Nachrichten realisiert werden. Dabei handelt es sich um Nachrichten, die vom Broker gespeichert und an neue Abonnenten sofort ausgeliefert werden. So lässt sich ein aktueller Zustand auch nach einem Verbindungsabbruch wiederherstellen. Derzeit werden Quality of Service Level 0 und 1 unterstützt. Bei QoS 1 muss sich die Anwendung selbst um die Erkennung und Vermeidung von Duplikaten kümmern, da Nachrichten erneut gesendet werden können, wenn keine Bestätigung erfolgt. Dies ist mit integriertem State Management aber deutlich einfacher als davor.
Ein einfaches Beispiel zeigt, wie ein Modul über den Telemetry Client des SDK Nachrichten von einem MQTT-Topic konsumiert, verarbeitet, im State Store speichert und in regelmäßigen Intervallen aggregiert wieder veröffentlicht. So bleibt der aggregierte Zustand auch dann erhalten, wenn eine Instanz ausfällt (siehe Listing 1). Das Beispiel stammt aus dem IoT Operations SDK GitHub Repo und kann dort in vollem Detail nachgeschlagen werden.
Listing 1: Telemetry Aggregation mit State Management (Quelle: Microsoft, https://github.com/Azure/iot-operations-sdks/)
// output MQTT topic
[TelemetryTopic("sensor/window_data")]
public class WindowTelemetrySender : TelemetrySender
{
internal WindowTelemetrySender(ApplicationContext applicationContext, IMqttPubSubClient mqttClient)
: base(applicationContext, mqttClient, new Utf8JsonSerializer())
{
}
}
var sessionClient = await clientFactory.GetSessionClient("output");
var sender = new WindowTelemetrySender(applicationContext, sessionClient);
await using var stateStoreClient = new StateStoreClient(applicationContext, sessionClient);
{
// Fetch the past sensor data from the state store
StateStoreGetResponse response = await stateStoreClient.GetAsync("aggregator_sensorData");
if (response.Value == null)
{
return;
}
// Deserialize the sensor data
inputData = JsonSerializer.Deserialize>(response.Value.GetString()) ?? [];
}
// Remove older data
inputData.RemoveAll(d => timeNow - d.Timestamp > TimeSpan.FromSeconds(30));
// Calculate window aggregation
var outputData = new WindowData()
{
Timestamp = timeNow,
WindowSize = Constants.WindowSize,
Temperature = AggregateSensor(inputData, s => s.Temperature),
};
await sender.SendTelemetryAsync(outputData, null, MqttQualityOfServiceLevel.AtMostOnce, cancellationToken: cancellationToken);
Das Deployment eines Moduls erfolgt über eine Kubernetes-Ressourcendefinition, die manuell oder automatisiert aus einer Pipeline heraus angewendet werden kann (siehe Bild 1).
In Kubernetes-Umgebungen ist GitOps ein verbreiteter Ansatz. Dabei wird der gewünschte Zustand der Umgebung in einem Git-Repository versioniert und automatisch auf das Cluster angewendet. Im Gegensatz zu klassischen CI/CD-Pipelines liegt die Steuerung nicht in der Pipeline selbst, sondern im Cluster, das regelmäßig den Repository-Zustand überprüft und Änderungen selbstständig übernimmt.
GitOps kann auch in Azure Arc-fähigen Kubernetes-Clustern eingesetzt werden, um standardisierte Deployments über mehrere Umgebungen hinweg zu ermöglichen. In der Deployment-Definition lässt sich auch die Anzahl der Replikate festlegen, über die ein Modul skaliert werden soll (siehe Bild 1).
Die größte Herausforderung bei der horizontalen Skalierung liegt nicht im Deployment, sondern in der Architektur der Anwendung selbst. Nur wenn ein Modul so aufgebaut ist, dass es mit mehreren Instanzen korrekt funktioniert, lassen sich die Vorteile von Skalierung und Ausfallsicherheit auch tatsächlich nutzen.
Akri, DAPR und Schema Registry: Erweiterungen für Custom Modules
Neben den grundlegenden Funktionen wie Telemetrieverarbeitung, MQTT-Kommunikation und State Management bietet das IoT Operations SDK weitere Komponenten, die sich für komplexere Anwendungsfälle nutzen lassen. Dazu gehören unter anderem eigene Discovery Handler für Akri und ein Schema Registry Client. Neben dem SDK gibt es aber auch eine weitere Abstraktion mit DAPR.
Mit einem eigenen Akri Discovery Handler lassen sich zusätzliche Gerätetypen oder Protokolle in die automatische Geräteerkennung einbinden. So können beispielsweise benutzerdefinierte Netzwerkgeräte, etwa industrielle Sensoren mit proprietären Schnittstellen oder spezielle Kameras, erkannt und automatisch als Assets in Azure IoT Operations registriert werden. Die Handler werden als eigenständige Container entwickelt und in das Akri Framework integriert, das in Kubernetes läuft. Dadurch lassen sich auch Geräte einbinden, die nicht dem OPC UA Standard folgen oder keine klassische Netzwerkadresse besitzen.
Der Schema Registry Client kann auf die Schema Registry zugreifen, welche es ermöglicht, strukturierte Datenformate wie JSON zu verwalten und zu validieren. Das ist besonders hilfreich, wenn mehrere Module mit gemeinsamen Datenstrukturen arbeiten oder wenn Daten an nachgelagerte Systeme wie Data Lakes, Event Hubs oder externe APIs übergeben werden, die ein festes Schema erwarten. Ein Beispiel wäre die Validierung von Sensordaten gegen ein vordefiniertes JSON Schema, um sicherzustellen, dass alle erforderlichen Felder vorhanden und korrekt typisiert sind, bevor die Daten weiterverarbeitet oder exportiert werden.
DAPR, die Distributed Application Runtime, kann ebenfalls in eigene Module integriert werden. Es stellt Funktionen wie Pub/Sub, State Management, Secrets und Service Invocation bereit, die über einheitliche APIs angesprochen werden können. Dabei stellt DAPR eine Abstraktionsschicht bereit, bei der die eigenen Anwendung nichts davon wissen muss, dass hinter einem simplen Pub/Sub oder State Management ein MQTT Broker steckt. Die Implementierung kann dann bequem konfiguriert und bei Bedarf ausgetauscht werden.
Diese Komponenten sind hilfreich, wenn die Anforderungen über einfache Telemetrieverarbeitung hinausgehen. Sie ermöglichen es, eigene Module gezielt an komplexe Umgebungen anzupassen, ohne grundlegende Funktionen selbst implementieren zu müssen.
Fazit
Eigene Module lassen sich mit Azure IoT Operations deutlich flexibler und robuster betreiben als unter IoT Edge. Die Ausführung als Container im Kubernetes-Cluster, die Integration mit dem MQTT Broker und die Möglichkeit zur horizontalen Skalierung eröffnen neue Spielräume für modulare Architekturen auf der Edge. Gleichzeitig bringt dieser Ansatz neue Anforderungen mit sich, etwa bei der Koordination von Zuständen oder dem Umgang mit mehreren Instanzen.
Das IoT Operations SDK bietet hierfür eine praxisnahe Grundlage. Funktionen wie State Management, Leader Election oder State Management über MQTT sind direkt nutzbar und reduzieren den Entwicklungsaufwand erheblich. Wer darüber hinaus komplexere Anforderungen hat, kann auf zusätzliche Komponenten wie Akri Discovery Handler, DAPR oder die Schema Registry zurückgreifen.
Im Vergleich zu IoT Edge ist der Einstieg in Azure IoT Operations nicht zwingend komplizierter, aber konzeptionell anders. Wer die Möglichkeiten gezielt nutzt und seine Module entsprechend aufbaut, kann damit eine skalierbare und wartbare Grundlage für eigene IoT-Anwendungen schaffen.
