Wir haben eine bewährte Best-Practice-Architektur entwickelt, die sich bei vielen Kunden als effektiv für die Anforderungen moderner IoT-Plattformen erwiesen hat. Denn bei der Entwicklung von IoT-Plattformen treten häufig ähnliche Herausforderungen auf: die effiziente Verarbeitung und Bereitstellung von Daten, die von einem breiten Spektrum an Geräten generiert werden. Die Daten müssen empfangen, aufbereitet und umliegenden Systemen zur Verfügung gestellt werden. Diese Herausforderung adressiert unsere Best-Practice-Architektur. Sie eignet sich für Projekte jeglicher Größenordnung und Komplexität im Hinblick auf Nutzungs- und Device-Zahlen und hat sich in einer Vielzahl von anspruchsvollen Anwendungsfällen bewährt.
Die zugrundeliegende Architektur ist unabhängig von den konkreten Deployment Szenarien und kann sowohl bei den großen Cloud Service Providern (CSP) mit breitflächigen Paletten an Managed Services, als auch bei kleineren CSPs sowie On-Premise angewendet werden. Der Einsatz in der Cloud bietet aber signifikante Vorteile, so vereinfachen Dienste wie Azure EventHub die Installations-, Konfigurations- und Betriebsprozesse erheblich.
Die damit verbundenen höheren Kosten und der Verlust an Flexibilität sind in vielen Fällen gerechtfertigt, insbesondere wenn man die Vorteile von PaaS und SaaS Services in Betracht zieht: vereinfachte Skalierung, schnellere Bereitstellung und leichtere Wartung. Ein möglicher Vendor-Lock-In wird dabei bewusst in Kauf genommen, falls er zur Cloud-Strategie des Kunden passt.
Unsere Best-Practice-Architektur ermöglicht einen schnellen Start, da der langwierige Prozess zum Entwurf einer Systemarchitektur stark verkürzt werden kann, oder gar ganz entfällt. PaaS und SaaS Managed Services entsprechen fertigen Bausteinen der Architektur, können auf einfachem Weg erzeugt werden und beschleunigen so zusätzlich das Vorankommen beim Aufbau einer IoT-Plattform. Der Fokus der Umsetzung kann dadurch wesentlich früher auf die Implementierung der mehrwertstiftenden Anteile gerichtet werden.
Jeder abstrakte Baustein unserer Architektur kann mit unterschiedlichen konkreten Implementierungen belegt sein. Diese können theoretisch beliebig miteinander kombiniert werden, aber gewissen Umsetzungs-Szenarien begegnet man häufiger. Beispiele:
Diese Umsetzung-Szenarien können schnell basierend auf den vorliegenden Anforderungen erkannt und in passende Umsetzungsstrategien umgewandelt werden.
In diesem Artikel haben wir uns auf die Ingest-Pipeline für IoT Metriken und Telemetriedaten konzentriert. Andere Mechanismen (Kommandos / Request - Response, Device Management, On-Boarding, Provisioining usw.) sind in unserer best-Practice Architektur aber ebenso abgedeckt und werden in zukünftigen Beiträgen behandelt.
Unsere Erfahrung zeigt, dass eine durchdachte Architektur nicht nur die Effizienz und Skalierbarkeit von IoT-Lösungen verbessert, sondern auch die Grundlage für innovative Entwicklungen legt.
Bei der Ingest-Pipeline der IoT-Plattform handelt es sich um eine generische IoT-Datenverarbeitungskette, die Daten von einer Vielzahl von Devices entgegennehmen, aufbereiten, anreichern und speichern muss. Je nach umzusetzenden Anwendungsfall hält die Plattform diese Daten in (Zeitreihen-) Datenbanken vor, legt sie in einem Datalake oder einem Archivierungsbereich ab und/oder gibt sie echtzeitnah an umliegende Systeme weiter. Einige der Teilkomponenten der Ingest-Pipeline haben unserer Erfahrung nach anwendungsfallspezifische Logikanteile. Viele Teilkomponenten lassen sich jedoch völlig generisch abbilden. Nachfolgendes Bild zeigt die Best-Practice-Architektur und die darin enthaltenen generischen und anwendungsfallspezifischen Teilkomponenten der Plattform.
Die Ingest-Pipeline erstreckt sich vom Connected Device bis hin zum Storage Layer. Bei ihrer Umsetzung hat sich die Berücksichtigung der folgenden allgemeinen Prinzipien als hilfreich erwiesen:
Nachfolgende Tabelle erläutert die Aufgabe der Standard Bausteine der Plattform:
Collection Layer |
Eingehender Endpunkt zu dem sich die Devices verbinden. Steht meist im öffentlichen Internet und benötigt entsprechend sehr gut abgesicherte Verbindungsmechanismen, sowie Schutzmechanismen gegenüber gängigen Angriffsszenarien |
Transformation Layer |
Nimmt Daten im device-/anwendungsfallspezifischen Format entgegen und transformiert diese in ein einheitliches generisches Format |
Processing Layer |
Hier können ergänzende Verarbeitungsschritte stattfinden, die meist zusätzliche Daten produzieren. Üblicherweise erfolgen hier
|
Storage Layer |
Der Data Storage Layer bindet unterschiedliche Datensenken an:
|
Query Layer |
Zugriff auf die im Storage Layer persistieren Daten für Umsysteme |
Visualisation Layer |
|
Custom Applications / Portal |
Anwendungsfallspezifische Applikationen die IoT-Daten nutzen |
Analytics Layer |
Spezifische Data Analystics Applikationen für weiterführende Analysen der Daten, Aufbau von Modellen oder ähnlichem |
Operations Layer |
Beinhaltet die für den erfolgreichen Betrieb und Weiterentwicklung der IoT Plattform relevanten Komponenten
|
In der Praxis haben wir eine breite Palette verschiedener Umsetzungs-Szenarien gesehen. Bei der Auswahl spielen häufig spezifische Gegebenheiten des Kunden eine wesentliche Rolle, wie z.B. das Vorhandensein oder Fehlen einer Cloud Strategie, bereits verfügbare (on-premise) Lösungen oder auch vorhandenes Know-how zu spezifischen Technologien. Im Wesentlichen kamen wir immer wieder mit folgenden Basis-Umsetzungsstrategien in Berührung:
Neben der Basis-Umsetzungsstrategie spielen die genauen Anforderungen an die IoT-Plattform eine entscheidende Rolle bei der Auswahl geeigneter Bausteine. Anforderungen können z.B. sein
Anhand der Basisstrategie und den spezifischen Anforderungen können schlussendlich passende Bausteine für die Plattform ausgewählt werden.
Nachfolgende Tabelle zeigt einen Ausschnitt an Technologien oder Services kategorisiert nach Art des Bausteins und Managementtyps. Im Prinzip lassen sich diese Bausteine (in bestimmten Grenzen) beliebig kombinieren.
Self-Managed |
CSP Managed |
3rd Party Managed |
|
K8S |
rancher vanilla K8s openshift |
Azure AKS AWS EKS usw. |
- |
Kafka |
Strimzi |
Azure EventHubs AWS MSK |
Confluent Cloud Aiven Kafka |
Kafka Integration |
Kafka Connect |
AWS MSK Connect Azure Data Explorer (ingest) Azure Eventhubs Routing |
Confluent Kafka Connect Aiven Kafka Connect |
Collection Layer |
EMQX HiveMQ |
Azure IoTHub AWS IoT Core |
HiveMQ Cloud |
Transformation Layer Processing Layer |
Spring Cloud Stream Services Microservices in verschiedenen Sprachen (Go, Rust, Java, Python, Typescript) |
Azure Functions Azure App Services AWS Lambdas AWS BeanStalk |
- |
Storage Layer: Cold Path |
Min.io DeltaLake |
Azure Storage Accounts AWS S3 |
- |
Storage Layer: Warm Path |
Influx Timescale |
Amazon Timestream Azure Data Explorer |
Influx Cloud Timescale Cloud |
Storage Layer: Hot Path (Streaming Analytics) |
Apache Spark Apache Flink Kafka Streams |
Azure Databricks AWS EMR AWS Databricks |
Ververica Platform Databricks Platform |
Query Layer |
Eigene API Service |
Azure Data Explorer |
InfluxQL PromQL |
Visualisation Layer |
Grafana Tableau |
Azure Power BI Azure Synapse Azure Managed Grafana AWS Managed Grafana AWS QuickSight |
Grafana Cloud Tableau Cloud |
Custom Applications / Portals |
Eigene Custom Applikationen |
- |
- |
Analytics Layer |
Apache Spark Apache SuperSet Trino PrestoDB Jupyter / Zeppelin |
Azure ML AWS SageMaker |
- |
Operations |
Prometheus Grafana ELK Stack |
Azure Monitor / Application Insights AWS Cloud Watch |
Instana Observability Dynatrace |
Der Aufbau einer IoT Plattform bietet einen sehr heterogenen Lösungsraum. Die vorgestellte Best-Practice-Architektur für die Ingest-Pipeline lässt sich in allen gezeigten Umsetzungsszenarien realisieren. Dabei hat iteratec gute Erfahrung mit den gezeigten Plattform-Bausteinen gemacht und kann diese gemäß der existierenden Anforderungen sehr individuell kombinieren. Die Umsetzung auf einer der großen CSP bietet dabei natürlich große Leistungsvorteile.
Dass mittlerweile immer mehr Unternehmen auch passende Cloud Strategien haben, um leistungsfähige Lösungen in der Cloud anzubieten zeigt z. B. die Azure basierte Umsetzung einer digitalisierten IoT Lösung (siehe SWM Insights auf Linkedin oder IoT-Lösungen | SWM) an deren Umsetzung iteratec Kolleg:innen beteiligt waren.