Unsere Learnings aus dem Azure IoT Workshop mit Microsoft

Im Rahmen des Azure IoT Workshops stellte uns Microsoft mehrere Technologien vor, die sich für IoT Lösungen eignen. Präsentiert wurde der Workshop von:

• Gerhard Ebinger - IoT Solution Architect, Microsoft

• Daniel Schenzer - Global Cloud Solution Architect, Microsoft

• Thomas Schärli - Solution Specialist Data Platform, Microsoft

Warum Azure IoT Edge?

Der Haupttreiber für die Entwicklung von Azure IoT Edge war der Bedarf nach 'AI on the edge'. Oft produzieren Maschinen so viele Rohdaten, dass es sehr teuer wäre, diese Daten direkt in die Cloud zu senden, nur um sie da zu prozessieren. Meistens sind nur die prozessierten Daten relevant für einen Business Use Case in der Cloud. Dank Fortschritten im Hardware-Sektor ist es seit einiger Zeit möglich, Rohdaten in kleinen und kostengünstigen Mikrokontrollern zu prozessieren. Genau hier befindet sich der Use Case von Azure IoT Edge. Azure IoT Edge übernimmt das Bereitstellen und Verwalten dieser Mikrokontroller, in diesem Kontext 'IoT Devices' genannt.

Azure IoT Edge Übersicht

Die wesentlichen Elemente von IoT Edge bestehen aus dem IoT Hub und der IoT Edge Runtime, die Open-Source auf Github verfügbar ist: https://github.com/Azure/iotedge

IoT Hub

Der IoT Hub verbindet die IoT Devices und übernimmt die Aufgabe eines Message Brokers. Er speichert die Messages für 7 Tage, danach werden sie gelöscht. An den IoT Hub können viele Services angefügt werden, die die Daten speichern, prozessieren und visualisieren.

Jegliche Kommunikation zwischen dem IoT Device und IoT Hub ist verschlüsselt und braucht Authentifizierung. Der IoT Hub spricht 3 Protokolle:

• HTTPS: Erlaubt nur unidirektionale Kommunikation vom IoT Device in die Cloud.

• MQTTS: Gut für tiefe Bandbreite.

• AMQPS: Von Microsoft empfohlen, wenn es die Bandbreite zulässt, da es das zuverlässigste Protokoll ist. Diente ursprünglich zum Austausch von Daten an der Börse.

Die IoT Hub Client SDK, welche auf dem IoT Device läuft, ist erhältlich in unterschiedlichen Sprachen (C/Python/NodeJs/C#/Java, kein C++). Der Kern der SDK ist in C entwickelt, die anderen verfügbaren Sprachen sind Wrappers.

Die Verbindung eines IoT Device zu einem IoT Hub wird durch den Device Provisioning Service geregelt. Das IoT Device meldet sich beim Device Provisioning Service mit seinen Zertifikaten an. Dabei sucht der Device Provisioning Service den zugehörigen IoT Hub und gibt dem IoT Device ein neues Zertifikat zurück, mit welchem sich das IoT Device dann mit dem IoT Hub verbinden kann.

Um alle Geräte verwalten zu können gibt es auf dem IoT Hub den Device Twin. Der Device Twin besteht aus einem JSON Dokument, welches den aktuellen Stand des IoT Device beschreibt. Auf dem Device Twin können mithilfe von Tags Metadaten abgelegt werden, zum Beispiel den Standort des Geräts. Auf dem Device Twin werden auch die Desired und Reported properties abgespeichert, also die erwünschte Device Konfiguration ausgehend vom IoT Hub und die tatsächliche Device Konfiguration auf dem IoT Device. Mit Queries kann man bestimmte IoT Devices suchen, zum Beispiel alle Geräte, die sich in London befinden und eine Firmware haben, welche nicht der Firmware aus den Desired Properties entspricht. Mit Direct Methods kann man auf den IoT Devices bestimmte Funktionen aufrufen. Mit Jobs können mehrere Direct Methods orchestriert aufgerufen werden.

IoT Edge Gateway

Oft kann die IoT Hub Client SDK aufgrund von Hardware-Inkompatibilität nicht direkt auf einer Maschine installiert werden. Damit eine Maschine trotzdem mit dem IoT Hub kommunizieren kann, ist ein sogenannter IoT Edge Gateway, also das IoT Device, nötig. Auf dem Gateway läuft containerisiert die IoT Edge Runtime, welche aus zwei Modulen besteht:

• Der IoT Edge Agent ist dafür zuständig, dass das IoT Device so konfiguriert wird, wie es der Device Twin auf dem IoT Hub vorgibt.

• Der IoT Edge Hub ist für die Kommunikation zum IoT Hub zuständig.

Die IoT Edge Runtime macht die Kommunikation mit dem IoT Hub bequem. Falls die Verbindung unterbrochen ist, cached die Runtime die Messages. Sobald die Verbindung zum IoT Hub wieder besteht, werden die Messages an den Hub geschickt. Bei den Messages muss man aber aufpassen: In grossen Mengen können sie sehr teuer werden. Man sollte nur Messages senden, die für einen Business Unit Case relevant sind. Die restlichen Daten müssen nicht via Messages an den IoT Hub gesendet werden, sondern können zum Beispiel aggregiert und komprimiert direkt in einem Azure Blob Storage abgespeichert werden. Nebenbei ist es auch möglich, anhand von Routen die Messages zu filtern, die an den IoT Hub gesendet werden. So können die Kosten auch verringert werden. 

Auf dem Bild sieht man ein Beispiel: Ein IoT Edge Gateway ist an eine Ölpumpe angeschlossen und kommuniziert mit der Maschine via Modbus. Ein Decoder macht aus den Modbus Messages JSON. Diese wiederum gelangen in ein Machine Learning Model, welches aus den Daten zum Beispiel berechnet, ob die Maschine eine Wartung braucht. So müssen nur die wichtigsten Informationen in die Cloud gesendet werden.

Wie eine Azure IoT Lösung in der Industrie aussehen könnte, zeigt folgende Darstellung. Mehr dazu im Azure IoT Manual.

Folgende Vorteile einer IoT Lösung kristallisieren sich heraus:

• AI gleich auf der Maschine

• Reagieren in Echtzeit möglich

• Lösung ist robust gegenüber Internetverbindung

• Verringern der Kosten, da man anstelle von Rohdaten prozessierte Daten in die Cloud schicken kann

Azure IoT Central

Azure IoT Central ist eine IoT Software as a Service Lösung, welches auch kleineren Unternehmen ohne extensive IoT & Cloud Kenntnisse ermöglichen soll, kostengünstige IoT Lösungen umzusetzen. 

Im Azure IoT Central Tool kann man IoT Lösungen basierend auf Problemstellungen, wie zum Beispiel die Überwachung des Wasserverbrauchs oder die Überwachung von Spitalpatienten, erstellen.

Azure Data Explorer

IoT Lösungen können grosse Datenmengen produzieren. So ist es wichtig, Tools zur Verfügung zu haben, mit denen man diese Daten performant abrufen, analysieren und prozessieren kann. Als Lösung bietet Microsoft den Azure Data Explorer an.

Der Azure Data Explorer ist geeignet für "warme Daten", also Daten, die zwischen Minuten und Monaten alt sind. Erwarten kann man dabei eine Query Performance von Sekunden bis Minuten.

Der Azure Data Explorer wird von Microsoft vollständig verwaltet. Um den Service zu nutzen, braucht man keine eigene Infrastruktur. Die Daten werden dabei gestreamed, man muss die Daten nicht vorher herunterladen. Dadurch ermöglicht der Azure Data Explorer schnelle ad-hoc Queries.

Mit Policies kann man bestimmen, wo und wie lange die Daten abgespeichert werden. So kann man bestimmen, wie lange Daten im In-Memory-Cache, im SSD Speicher oder in einem Azure Storage bleiben, und ab wann sie gelöscht werden. All dies passiert automatisch. Wenn Daten aus einem Azure Storage gebraucht werden, dauert eine Query beim ersten Mal einfach länger. Danach sind die relevanten Daten im In-Memory-Cache oder SSD Speicher und die Query ist beim wiederholten Ausführen um ein Vielfaches schneller.

Der Azure Data Explorer kann von verschiedenen Plattformen Daten lesen, unter anderem vom IoT Hub, Event Hub, Azure Storage, Azure Data Lake. Es können Terrabytes von Daten performant gelesen und analysiert werden.

Die Kosten für eine Azure Data Explorer Lösung können mit dem Cost Estimator Tool berechnet werden. 

Um den Data Explorer zu gebrauchen, gibt es ein Web-GUI und einen Desktop-Client.

In den GUIs kann man

• Daten importieren

• Daten abfragen

• Dashboards erstellen aus Queries

Für die Queries verwendet Azure Data Explorer eine eigene Sprache: die Kusto Query Language (KQL). Ein grosser Vorteil von KQL ist, dass man mit KQL sowohl strukturierte als auch unstrukturierte Daten abrufen kann.

Im Workshop wurde anhand eines Beispiels auf eindrückliche Weise vorgestellt, wie man mit dem Azure Data Explorer GitHub-Daten analysiert kann. Dabei wurden 1.6 Billionen GitHub Events (Commits, Stars, Watches etc.) abgespeichert in 4.6 TB komprimierter Daten analysiert. Innerhalb von Sekunden wurde berechnet, welche Repositories anhand von eigens definierten Metriken als besonders "Populär" gelten oder an welchen Tagen im Jahr deutlich weniger GitHub Events als sonst entstehen (während Weihnachten bis Neujahr :-)). Äussert nützlich ist dabei, dass man sich die Daten gleich im GUI als Plot darstellen kann. Auch sind einige Machine Learning Funktionen wie Anomaly Detection direkt im Azure Data Explorer integriert, so dass man sie gleich in der Query ausführen kann.

Cosmos DB

Cosmos DB ist ein von Microsoft vollständig verwalteter globaler NoSQL Datenbank-Service, welcher niedrige Latenzen und massive Skalierung garantiert. Dabei können die Daten auf die ganze Welt verteilt und repliziert werden. Der Service skaliert je nach Belastung.

Mit dem Cosmos DB Service garantiert Microsoft:

• Low latency of Read/Write request (< 10ms)

• High availability (99.999%)

• Garantierter Throughput

• Garantierte Consistency

Wenn man diese Garantien nicht braucht, ist eine Cosmos DB möglichweise nicht die richtige Wahl, da eine Cosmos-DB je nach Belastung eher teuer werden kann. So muss man sich im vorneherein über die Belastung im Klaren sein. Bei einer normalen SQL-Datenbank ist es oft einfacher, die Kosten vorherzusehen und unter Kontrolle zu haben.

Unterstützt werden neben dem native Core (SQL) API auch APIs für MongoDB, Cassandra, Gremlin, etc. Somit können bestehenden Applikationen auf eine Cosmos DB Lösung wechseln, ohne dass das ganze Data Access Layer neu geschrieben werden muss.

Wie die Daten auf verschiedene Teile der Welt distribuiert und repliziert werden, bestimmt das auswählbare Consistency Level. Die Consistency Levels gehen von 'Strong' bis zu 'Eventual', wobei mit 'Strong' immer sichergestellt wird, dass die Nachrichten gleichzeitig und in gleicher Reihenfolge auf alle Regionen verteilt wird. Bei 'Eventual' hingegen können die Nachrichten verspätet und in unterschiedlicher Reihenfolge auf alle Regionen verteilt werden. Das Consistency Level kann man auch pro Request setzen. So kann es sein, dass 'Eventual' in der Regel gut genug ist und nur einzelne Requests einen Consistency Level von 'Strong' benötigen.

Zur Berechnung der Kosten verwendet der Cosmos DB Service sogenannte 'Request Units' (RU). Eine RU ist eine normalisierte Einheit und ist definiert durch 1 Read Operation von einem 1KB Dokument. Es gibt folgende Bezahlmodelle für diese Cosmos DB:

• Provisioned Throughput: Man reserviert sich die Rate der RU, also RU pro Sekunde. Zum Beispiel reserviert man sich 500 RU/s. Wenn man nur 200 RU/s verwendet, zahlt man trotzdem auch für die restlichen 300 RU/s. Deshalb sollte man sich gut überlegen, wie viel RU/s man erwartet. Wenn mehr als 500 RU/s verwendet werden, dann werden die überschüssigen Requests auf die nächste Zeiteinheit verschoben.

• Autoscale Throughput: Hier wird die reservierte RU/s je nach Belastung angepasst.

• Serverless: Hier wird keine bestimmte RU/s reserviert, die Kosten berechnen sich aus den effektiv gebrauchten RUs.

Um die garantierte Cosmos DB Performance zu gewährleisten, werden die Daten auf verschiedene Partitionen verteilt. In welcher Partition ein Dokument abgelegt wird, entscheidet der wählbare Partition Key. Sinn macht es, diesen Partition Key so zu wählen, dass Requests jeweils nur Daten von einer Partition brauchen. Zum Beispiel macht es bei einer IoT Lösung welche Skigebiete überwacht Sinn, dass der Partition Key der Name der einzelnen Skigebiete ist. So können performant alle Daten aus einem Bestimmten Skigebiet geladen werden. Durch geschickte Wahl des Partition Keys können so massiv RUs gespart werden.

Azure DevOps

Verglichen zu Unternehmen ohne DevOps Lösungen können Unternehmen mit DevOps Lösungen folgendes Erreichen:

• 46x höhere Deployment Frequency

• 2555x schnellere Lead Time For Changes

• 7x tiefere Change Failure Rate

• 2604x schnellere Mean Time To Recover

Source: Accelerate: State of DevOps 2018: Strategies for a New Economy.

All dies führt zu einem höheren Umsatz und einem schnelleren Time To Market.

Durch eine geschickte DevOps Lösung können viele Aufgaben automatisiert werden. Bei einem traditionellen Ansatz gibt es zum Überprüfen eines Releases einen 'Cloud Custodian'. Der Cloud Custodian schaut sich alle Changes an, klickt irgendwann auf Release und muss entscheiden, ob und wie ein Rollback umzusetzen ist.

In einem moderneren Ansatz gibt es die 'Cloud-Native Governance'. Automatisierte Mechanismen prüfen den Release anhand von Policies. Zum Beispiel kann bestimmt werden, dass ein Update nicht plötzlich Ressourcen in Asien erstellt. So muss nicht eine Person die Änderungen durchforsten, sondern es können durchdachte Policies erstellt werden die vieles automatisieren.

Auch gibt es die Möglichkeit, einen neuen Release nur im kleinen Rahmen zu verteilen. Der Release wird untersucht und je nach Resultat wird der Release breiter verteilt oder gestoppt.

DevOps besteht aus folgenden teilen:

• Continuous Integration (CI): Nach Commits wird der Code automatisch kompiliert und getestet.

• Continuous Deployment (CD): Nach Commits wird automatisch der aktuelle Production Release ersetzt werden mit der neuen Version.

• Continuous Learning & Monitoring: Nach Deployments wird geprüft, ob die Metriken sich wie erwartet verhalten. Im Notfall, zum Beispiel wenn es viele Error Reports gibt, könnte automatisch ein Rollback zu einer früheren Version ausgeführt werden.

Azure DevOps bietet folgende Services an:

• Azure Boards: Tools fürs Planen, Tracken, und Diskutieren der Arbeit.

• Azure Pipelines: Tools für CI/CD.

• Azure Repos: Cloud-hosted Git Repositories.

• Azure Test Plans: Tools für das Verwalten von manuellen und automatischen Tests

• Azure Artifacts: Speicherplatz für Packages, die im Projekt gebraucht werden aber auch Artefakte der CI/CD Pipeline.

Einzelne dieser Services können ein- und ausgeschaltet und mit anderen Technologien umgesetzt werden.

Unter folgendem Link erfährt ihr, wie Microsoft DevOps umsetzt: devblogs.microsoft.com/devops/how-does-microsoft-do-devops/

Mit dem Azure DevOps Demo Generator kann man schnell ein Azure DevOps Projekt erstellen und sich mit der Azure DevOps Umgebung vertraut machen. Als Starthilfe gibt es zusätzlich im Azure Portal einen 'DevOps Starter', welches ein Azure DevOps Projekt erstellt und mit Azure kommuniziert. Viel Vergnügen!

 Weitere Informationen zu unserem Cloud und IoT Angebot finden Sie unter: www.m-f.ch/cloud-iot