Best-Practice-Architektur einer Cloud-basierten IoT-Plattform

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.      

1. Der Vorteil der Cloud: Skalierung und Effizienz
2. Schneller zum Ziel mit Managed Services und Best-Practice-Architektur
3. Flexibilität durch modulare Bausteine
4. Fokus auf die Ingest-Pipeline
5. Architektur der Ingest-Pipeline
6. Bausteine der Architektur 
7. Umsetzungs-Szenarien
8. 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: