Hallo zusammen,
heute möchte ich meine Deep Dive Artikelserie, zur Azure IoT Solution Architecture fortsetzen.
In der letzten Folge hatten wir unsere Sicht auf die Architektur etwas erweitert und das Segment Cloud Gateway in die Betrachtungen mit einbezogen. Hier das Gesamtbild noch einmal zur Erinnerung:
Da das Bild sehr komplex ist, hatte ich es für die späteren Betrachtungen noch mehrmals gesplittet. Während ich euch die Erläuterungen für Teilabbildung a + b bereits in der letzten Folge (hier) geliefert hatte, bin ich euch allerdings die Erläuterungen für Teilabbildung c noch schuldig geblieben.
Das werde ich heute sofort nachholen aber vorher gibt es hier, auch Teilabbildung c noch einmal zum anschauen:
Wie ihr sehen könnt, gibt es in Teilabbildung c keine direkte Kommunikation mehr zwischen den Devices im Segment Field und dem Cloud Gateway. Alle Kommunikation erfolgt stattdessen über ein Field Gateway (gegebenenfalls auch in Kombination mit einem Protocol Gateway).
Stellt sich sofort die Frage: Warum diese Umleitung?
Dafür gibt es mehrere Gründe:
- Ein PAN Device ist aufgrund seiner Beschaffenheit (niedriges Ressourcenangebot), in der Regel gar nicht in der Lage selbstständig mit der Cloud zu kommunizieren. Ihr müsst zuerst über Bluetooth eine Verbindung zu einem Gateway herstellen, um anschließend die Daten in die Cloud zu übertragen.
- Legacy Devices benutzen oft komplexe Netzwerk Protokolle (z.B. Modbus). Diese sind für eine direkte Kommunikation auch nicht geeignet.
Neben den Kommunikationsproblemen (davon sind übrigens zirka 85% aller Devices betroffen), kann aber auch die Notwendigkeit oder der Bedarf, den Data Stream einer Vorverarbeitung (Transformation) zu unterziehen, ein Grund für den Einsatz eines Field Gateways sein.
Beispiele für diese Transformationen des Data Streams sind:
- Batching
- Compression
- Message Composition
- Queuing
- Throttling
Kommen wir zum letzten Grund, für den Einsatz eines Field Gateways: die sog. Implementation of Infrastructure Capabilities. Mit dem Field Gateway habt ihr z.B. die Möglichkeit eure Infrastruktur an Sicherheitsbedürfnisse anzupassen oder einen Identity Management Layer (Credential Management Layer) zu realisieren.
Kommen wir nun zur Azure IoT Plattform:
Für die Azure IoT Plattform wurde die Unterstützung für das Field Gateway, bisher als Open Source Projekt „Azure IoT – Gateway SDK“ auf GitHub angeboten.
Ok, ihr habt es gelesen: Bisher
Vor knapp drei Wochen fand in Seattle die Microsoft Build Conference 2017 statt (das ist Microsoft größte Entwicklerkonferenz). In der Keynote der Konferenz wurde eine neue Komponente der Azure IoT Platform vorgestellt:
Azure IoT Edge
Azure IoT Edge ist einerseits der Ersatz für das Azure IoT Gateway SDK, mit einer relativ identischen Funktionalität. Andererseits bekommt ihr aber auch zahlreiche neue Möglichkeiten für die Transformation eures Data Streams geboten (dazu gibt es in einem späteren Artikel mehr).
Betrachten wir nun, das Azure IoT – Gateway SDK (oder auch das Azure IoT Edge) einmal näher:
Wie ihr sehen könnt, besteht der Inhalt eines Field Gateways nur aus zwei unterschiedlichen Elementen, den Modulen und einen Message Broker.
Klären wir nun erstmal die Frage: Was ist ein Gateway Modul?
Ein Gateway Modul empfängt eine Nachricht, führt dann eine Aktion damit aus, transformiert sie optional in eine neue Nachricht und gibt sie dann abschließend zur Verarbeitung an andere Module weiter.
Im Gateway treten Module immer als eine Verkettung von mehreren Modulen auf (auch Data Processing Pipeline genannt). Die Anzahl an unterschiedlichen Modulen hängt von euren individuellen Bedürfnissen ab. Zwei Module findet ihr aber in jeden Szenario:
- Protocol Ingester Modul (als Startpunkt der Pipeline)
- IoT Hub (Send to Cloud) Modul (als Endpunkt der Pipeline)
Zwischen dem Startpunkt und dem Endpunkt der Pipeline, kommen dann weitere vordefinierte Module (zusätzliche Gateway Funktionalitäten) oder benutzerdefiniert Module (eure Business Logic) zum Einsatz (dazu später mehr).
Nächste Frage: Was ist mit dem Message Broker?
Der Message Broker wird von den Modulen dazu verwendet, um miteinander zu kommunizieren. Ihr veröffentlicht eine Nachricht auf dem Broker, die dann schrittweise an alle angebundenen Module weitergegeben werden.
Ein Message Broker basiert je nach eurem Bedarf, auf einer Busarchitektur, dem Pub / Sub Pattern oder jeden anderen Messaging Pattern.
Ok, genug für heute. Sehr viel mehr zum Thema, gibt es in der nächsten Folge.
Schöne Grüße
Oliver
