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.
- Der Vorteil der Cloud: Skalierung und Effizienz
- Schneller zum Ziel mit Managed Services und Best-Practice-Architektur
- Flexibilität durch modulare Bausteine
- Fokus auf die Ingest-Pipeline
- Architektur der Ingest-Pipeline
- Bausteine der Architektur
- Umsetzungs-Szenarien
- Fazit
Der Vorteil der Cloud: Skalierung und Effizienz
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.
Schneller zum Ziel mit Managed Services und Best-Practice-Architektur
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.
Flexibilität durch modulare Bausteine
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:
- Hyperscaler mit 100% Fokus auf CSP SaaS
- Mittelgroßes CSP mit managed K8S und Open-Source Bausteine
- On-Premise mit 100% Open Source
Diese Umsetzung-Szenarien können schnell basierend auf den vorliegenden Anforderungen erkannt und in passende Umsetzungsstrategien umgewandelt werden.
Fokus auf die Ingest-Pipeline
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.
Architektur der Ingest-Pipeline
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:
- Event Streaming: von Devices eintreffende Nachrichten werden als ein Stream von Events behandelt. Dabei spielen die folgenden drei Kernelemente eine maßgebliche Rolle
-
- Kafka: Kafka bildet das Zentrum der Architektur und die Daten- / Eventdrehscheibe.
- Stream Processing: ermöglicht den Einsatz von Stream Processing / Streaming Analytics Frameworks zur Umsetzung weiterführender Berechnungen.
- spezifische funktionale Bausteine: Event-orientierte Funktionen oder Services (meist stateless), die Daten von einem Kafka Topic lesen, verarbeiten und auf ein weiteres Kafka Topic schreiben.
- Generische Daten: Die Daten innerhalb der Ingest-Pipeline sind weitestgehend generisch und können so anwendungsfallagnostisch weiterverarbeitet werden.
- Data Sinks: Generische Komponenten, die Daten im generischen Format in konkreten Datensenken speichern.
- Hot, Cold, Warm Paths: Die Verarbeitungskette unterscheidet im wesentlichen drei Verarbeitungswege, die vor allem Einfluss auf die Verarbeitungslatenz haben:
- Hot Path: Hot Daten werden in nahezu Echtzeit verarbeitet und mit sehr geringen Latenzen zur Verfügung gestellt.
- Warm Path: Warm Daten werden schnell verarbeitet und mit relativ geringen Latenzen zur Verfügung gestellt.
- Cold Path: Cold Daten werden verzögert oder gebatched verarbeitet und meist in relativ langsamen Storage persistiert. Insbesondere Lese-Latenzen können hier hoch sein.
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
|
Umsetzungs-Szenarien
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:
- Hyperscaler CSP (Azure, AWS, Google Cloud Platform) unter starken Einsatz von CSP spezifischen Services (PaaS, SaaS):
Diese Strategie wird häufig dann gewählt, wenn die Cloud Strategie die Nutzung zulässt und Management sowie Operation-Kosten minimiert werden sollen. - Hyperscaler CSP (Azure, AWS, Google Cloud Platform) generisch mit K8S:
Diese Strategie wird eingesetzt, wenn die Cloud Strategie das zulässt und mehr Flexibilität bei der Auswahl der einzelnen Bausteine der Plattform gefordert ist, da sehr spezifische Anforderungen an diese existieren. - Mittelgroße CSP: StackIt, Ionos, OVHCloud:
Diese Strategie wird häufig eingesetzt, wenn die Cloud Strategie aus Gründen der Datensouveränität es erforderlich macht auf deutsche Anbieter zu gehen. - Hybride Lösung: CSP mit 3rd Party Managed Services (Influx Cloud, TimeScale Cloud, Confluent Cloud)
Diese Strategie bietet größere Flexibilität bei der Auswahl an Bausteinen, wenn spezifische Anforderungen nur durch 3rd Party Managed Service erfüllbar sind (z.B. MQTT Broker mit voller Unterstützung von Protokoll Version 5), und z.B. die Management- und Operationskosten minimiert werden sollen. - On-Premise & Fully Self Managed (generisch mit K8S)
Diese Strategie wird häufig dann angewendet, wenn keine Cloud Strategie vorhanden oder die Nutzung der Cloud nicht möglich ist.
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
- Leichte Instanziierbarkeit
- Strikt je Anwendungsfall zu trennende, sensible (Device-) Daten
- Notwendigkeit, schnell und häufig neue Anwendungsfälle auf / abzubauen (Fail-Fast Ansatz)
- Sehr hohe Nutzungslast (Datenvolumen) und Device-Zahlen
- Einfache und schnelle Skalierbarkeit z.B. nach Tageszeit aufgrund sehr variabler Lastzeiten / Stoßzeiten oder wegen einem erwartbaren hohen Wachstum.
- Integration vieler diverser Devices, Device-Arten oder unterschiedlicher Hersteller. Die Iot-Plattform fungiert als zentrale, homogenisierende Plattform.
- Gewünschter Ort der Datenhaltung / Speicherung (Europa / Amerika / China)
- u.v.a.
Anhand der Basisstrategie und den spezifischen Anforderungen können schlussendlich passende Bausteine für die Plattform ausgewählt werden.
Bausteine der Architektur
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 |
Fazit
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.