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.

Ingest-Pipeline

 

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 
  • Kontextualisierung der Daten mit Stammdaten
  • Kalkulationen auf Basis des eingehenden Datenstroms (z.B. Differenzberechnungen)
  • Einfache Korrekturen eingehender fehlerhafter Daten

Storage Layer

Der Data Storage Layer bindet unterschiedliche Datensenken an:
  • Live-Data zur Abbildung des aktuellen Zustands der Devices (Stichwort: Datengetriebener Digitaler Zwilling) 
  • Zeitreihen Storage zum Vorhalten von Zeitverläufen 
  • Object Storage zur Archivierung und Dokumentation der Daten
  • Datalake mit für weiterführende Analysen aufbereitete und kontextualisierte Daten

Query Layer

Zugriff auf die im Storage Layer persistieren Daten für Umsysteme

Visualisation Layer

  • Dashboarding Applikationen
  • Exploratives Datenanalyse
  • Reporting / BI

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
  • Monitoring
  • Tracing
  • Alerting
  • Dashboarding
  • Deployment / IaC 

 

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. 

 

Tags: Cloud Transformation, Internet of Things

Verwandte Artikel

Die Motivation vieler Unternehmen, in die Cloud zu migrieren, ist die Effizienz ihrer IT zu steigern und Kosten zu senken. Doch...

Mehr erfahren

Topics: Cloud Transformation, Internet of Things

Beim Einsatz moderner Cloud-Technologien ist eine maßgeschneiderte Plattformstrategie für die effiziente und einheitliche...

Mehr erfahren

Topics: Cloud Transformation, Internet of Things

Die Cloud verändert, wie Unternehmen ihre IT-Infrastruktur bereitstellen und betreiben. Auf der einen Seite können Unternehmen...

Mehr erfahren

Topics: Cloud Transformation, Internet of Things