On-Demand Webinar: MQTT 5 in Azure mit HiveMQ Enterprise MQTT Broker

Angela Meyer: Ein herzliches Willkommen zu unserem diva-e Webinar mit unserem Partner HiveMQ. Heute erfahrt ihr von unseren Experten Dominik Obermaier und Sven Kobow wie der HiveMQ Enterprise MQTT Broker in eine Azure basierte Unternehmensplattform integriert werden kann. Mein Name ist Angela Meyer, und ich bin im diva-e Marketing Team dabei, und betreue unter anderem unsere Events und Webinare und bin heute eure Moderatorin. Und an dieser Stelle übergebe ich jetzt das Wort an Dominik und an Sven. Und wünsche den Teilnehmern sehr viel Spaß beim Zuhören. Sven, ich übergebe dir jetzt die Übertragungsrechte.

Sven Kobow: Vielen Dank Angela für die Einleitung. Und von meiner Seite aus natürlich auch ein herzliches Willkommen. Ich freue mich sehr darauf jetzt die nächste ungefähr Stunde mit euch verbringen zu können. Um euch, wie Angela schon angekündigt hat, einiges dazu zu erzählen, wie man mit dem HiveMQ Enterprise MQTT Broker auch auf einer Azure basierten Unternehmensplattform in den Genuss von MQTT 5 und all seinen Features kommen kann. Zunächst einmal kurz zu uns, zu diva-e, wer sind wir? Wir sind Deutschlands führender Transactional Experience Partner, wir sind Nummer eins E-Commerce Partner in Deutschland, wir sind der Partner der Wahl für viele B2B-Kunden. Wir verfügen über Tools und Technologien für sichere Projekte. Mittlerweile sind wir fast 800 Mitarbeiter an acht Standorten über ganz Deutschland verteilt. Seit 2018 verfügen wir über eine eigenes diva-e IoT Lab, in dem wir alle unsere Aktivitäten rund um das Thema IoT und industrial IoT bündeln und unseren Kunden entsprechend so die Expertise in diesem Bereich zur Verfügung stellen können.

Und wir bieten in unserem Leistungsportfolio natürlich auch Leistungen rund um den HiveMQ Broker oder HiveMQ Produkte an, zum Beispiel Operations oder auch das Entwickeln von Extensions. Hier ein kurzer Überblick über unsere Kunden. Wie man sieht ist da einiges mit Rang und Namen dabei. Wir sind in unterschiedlichsten Branchen tätig für unsere Kunden, und die Anzahl der IT relevanten Projekte nimmt in den letzten Jahren auf jeden Fall rasant zu. Das heißt, wir können auch eine gute Nachfrage in diesem Bereich verzeichnen. Wer bin ich? Mein Name ist Sven Kobow, ich bin bei diva-e als Expert Plattform Architect tätig. Ich habe 2018 das diva-e IoT Lab gegründet, bin Spezialist für IoT und Datenplattformen. Langjährige Erfahrung habe ich in agiler Softwareentwicklung, und ich bin aktiv engagiert bei der Mitarbeit im Rahmen der Open Industry 4.0 Alliance. Wer mir auf LinkedIn oder auf GitHub folgen möchte, kann das gerne tun, Kontaktdaten sind hier eingeblendet. Genau. An der Stelle würde ich zu Dominik übergeben.

Dominik Obermaier: Auch ein herzliches Willkommen von mir. Mein Name ist Dominik Obermaier, ich bin technischer Geschäftsführer und Gründer von HiveMQ. Ich selbst komme aus dem Bereich Distributed Systems, und habe da eben sehr viel die letzten Jahre auch gemacht, auch entwickelt. Und bin als einer der wenigen Deutschen auch Mitglied des sogenannten OASIS MQTT Committee. Das bedeutet, wir spezifizieren den MQTT Standard mit, das, vielleicht einige wissen, ein ISO Standard ist. Und mittlerweile auch in der Industrie das Hauptprotokoll ist, um eben Geräte ins Internet zu bringen. Und ich war eben aktiv daran beteiligt, den aktuellen ISO Standard, aber auch MQTT 5, also die neue Generation, mit zu spezifizieren. Und momentan bin ich eben auch mit dabei MQTT SM für Sensor Netzwerke eben auch sage ich mal MQTT fit zu machen um auch in wirklich kleinste Umgebungen deployed werden zu können. Ich bin Buchautor, Conference Speaker, und beschäftige mich auch mit so Themen wie, bin an der Universität eben tätig und organisiere Konferenzen mit. Man kann mir folgen auf Twitter auch und auf LinkedIn. (8 Sek.)

Zu HiveMQ. HiveMQ ist eine Firma, die es seit acht Jahren gibt, wir sind in der Nähe von München angesiedelt. Zum aktuellen Zeitpunkt betreuen wir mit unserem Kernprodukt HiveMQ 130 Kunden, davon viele Handelsunternehmen, darunter alle deutschen Automobilhersteller und auch international ein großer Automobilhersteller, oder einige große Automobilhersteller. Und bis nächstes Jahr, bis in den nächsten zwei Jahren, werden wir-, circa 50 Prozent aller Connected Cars werden auf HiveMQ laufen. Wir selbst sind spezialisiert auf IoT und MQTT Software, darunter eben unser Kernprodukt HiveMQ. Aber auch Ökosystem-Tools wie etwa Bibliotheken, die wir Open Source zur Verfügung stellen, die eben eingesetzt werden in industriellen Umgebungen, aber eben auch für Use Cases wie Connected Car.

Während wir hier sprechen tut sich einiges im sogenannten Internet der Dinge. Und was wir hier sehen ist die Anzahl der Menschen, die mit dem Internet verbunden sind. Das heißt, wenn man jetzt in das Jahr 2018 zurückgeht, bedeutet das, dass im Jahr 2018 circa vier Milliarden Menschen Zugang zum Internet hatten. Das ist ein bisschen mehr als die Hälfte. Und auch im Jahr 2020 hat sich das natürlich weiterentwickelt, und in den nächsten Jahren wird einfach ein Großteil der Menschen Zugang zum Internet haben.

Was jetzt aber spannend ist-, und dieser Chart, den wir hier sehen, der zeigt die Geräte, die mit dem Internet verbunden sind. Und den Chart, den wir vorher gerade gesehen haben, der eben diese vier Milliarden Menschen und wachsend, dass ja auch schon eine sehr steil wachsende Kurve war. Siehst man hier, das ist diese grau eingezeichnete Linie hier unten. Während wir zum aktuellen Zeitpunkt deutlich über 30 Milliarden Geräte bereits im Internet haben. Was ist ein Gerät? Das kann von der Waschmaschine über ein Auto bis zu sage ich mal industriellen Fertigungsstraßen können das wirklich Geräte sein. Das heißt, das Internet der Dinge ist definitiv exponentiell wachsend, und es ist eine der größten Veränderungen die es wahrscheinlich seit der Dampfmaschine gegeben hat. Das heißt, das Internet der Dinge benötigt auch komplett andere Technologien wie das Internet der Menschen. Weil einfach die Skalierungen, die wir hier sehen, komplett andere sind. Und eine der Schlüssel Technologien ist eben das ganze Thema Cloud Computing.

Und es gibt ja hier die großen Hyperscaler, die Cloud Provider. Und Amazon ist ja einer der meist verwendetsten, AWS ist einer der meist verwendetsten Cloud Plattformen die einen sehr großen Plattformmarkt ausmachen. Und mittlerweile ist es so dass eben Microsoft Azure sehr stark wachsend ist. Und wie wir später auch gleich sehen werden wahrscheinlich für größere Kunden, ambitioniertere Kunden, sogar die bessere Wahl ist, um eben Cloud Computing auch zu machen. Und wir werden es auch in diesem Webinar im Detail beleuchten, wie man auch technisch es schafft seine Use Cases abzubilden, um eben IoT mit Azure zu machen. Wie gesagt, es gibt normalerweise, wenn man von Cloud Computing spricht, wenn man nicht eben in die private Cloud gehen möchte, stellt sich eigentlich die Frage gehe ich in Richtung Microsoft Azure, gehe ich in die Richtung AWS, oder gehe ich in die Richtung Google Cloud.

Und es ist ja nun so, dass zum aktuellen Zeitpunkt sieht man eben an der Verteilung auch der Kunden, AWS hat Stand heute die meisten Kunden. Wobei Microsoft Azure speziell in Richtung Industrie, speziell in Richtung große Unternehmen mit mehr als 1000 Mitarbeitern, deutlich besser aufgestellt ist. Und auch wenn man sich den Umsatz ansieht, und aber auch die Anzahl der Kunden sieht man, dass zwar Azure im Vergleich an absoluten Kunden zum aktuellen Zeitpunkt etwas weniger hat als zum Beispiel Google oder auch Amazon, aber, dass einfach der Usage, die Consumption, deutlich höher liegt. Was alle großen Cloud Provider auch gemeinsam haben ist, dass sie diese sogenannte Internet of Things Plattform mitbringen. Und diese haben viele, viele Funktionalitäten, da wollen wir jetzt gar nicht so im Detail eingehen. Da wird dann der Sven im Detail noch die genauen Komponenten auch darstellen, wofür diese auch technisch notwendig sind. Und wie man eben eine saubere Architektur auch umsetzt. Aber grundsätzlich reden wir sehr häufig davon, dass man Analytics benötigt. Das heißt Auswertungen. Machine Learning ist es mittlerweile sehr häufig. Und ein wichtiger Aspekt, speziell wenn ich in die Richtung Predictive Maintenance gehe ist es eben sehr wichtig. Device Management, darunter auch das Professionieren von Geräten, ist ein Kernthema.

Aber auch so Sachen wie Digital Twin, also die virtuelle Repräsentation eines physischen Devices, mit der ich interagieren kann. Und natürlich auch Sachen wie Security sind wichtig. Und was auch alle Cloud Provider gemeinsam haben, sei es AWS mit ihrem IoT Angebot, oder auch Azure mit IoT Hub, ist das Thema Connectivity. Und davon sprechen wir die direkte Verbindung vom Gerät, also das kann von einem Auto sein, kann von einer Maschine sein, zu der Cloud. Und das ist auch ein Teil der normalerweise auch Out-of-the-Box mitkommt. Der aber mit sehr großen Nachteilen daherkommt, wenn man hier eben diese Standard-Funktionalitäten mitbenutzt. Und das wollen wir uns jetzt noch im Detail angucken.

Erstmal ist die Frage, warum sollte man sich überhaupt beschäftigen mit dem Thema Device to Cloud und Cloud to Device? Weil man-, das Verbinden ist so normalerweise der Teil, mit dem man sich nicht beschäftigen möchte. Man möchte ja IoT in der Cloud machen, um zum Beispiel Predictive Maintenance Use Cases abzubilden, oder andere Use Cases. Sehr häufig möchte man sich einfach gar nicht beschäftigen mit wie verbinden sich die Geräte zur Cloud? Weil, es wird schon passen. Die Wahrheit ist aber, dass die Geräte, die man eben selbst produziert, wenn ich jetzt Maschinenbauer bin, aber auch wenn ich ein Autohersteller bin, dann sind diese Geräte sehr häufig, oder sollten in den meisten Fällen in meiner Wertschöpfungskette sein. Und einer der Themen, die im Internet bisher immer sehr, sehr wichtig waren, war das Thema offene Standards. Es ist insofern wichtig, um Vendor Lock-in zu vermeiden. Und es hat sich http im Web für Menschen als das Standard-Protokoll herauskristallisiert. Es hat den Vorteil, man muss sich nicht darum kümmern, ob jetzt der Wikipedia-Server, den ich jetzt ansurfen möchte, ob dieser jetzt einen Apache Webserver hat, einen Enginex Webserver, oder ob der vielleicht sogar was Eigenes hat.

Weil, am Ende mein Browser spricht http und man bekommt eben eine Antwort. Und es steht mir auch frei, Chrome oder Firefox zu benutzen, oder auch Microsoft Edge. Wenn ich jetzt in das Internet der Dinge schaue, gibt es das Standard Protokoll schlechthin, und das ist MQTT. Und wie schon gesagt, das ist ein Industriestandard, das ist ein ISO Standard. Und die Garantie ist, wenn ich MQTT verbindend benutze, um eben meine Geräte mit der Cloud zu verbinden, ist, dass ich jederzeit auch unter Umständen meinen Cloud Provider wieder wechseln könnte. Weil, wenn ich jetzt aus irgendwelchen Gründen neben Microsoft auch noch auf AWS eine Infrastruktur aufbauen möchte, kann ich durch, dass das mein Gerät MQTT spricht, diesen Standard, kann ich jederzeit meinen Endpunkt wechseln. Ich habe nicht diese enge Koppelung. Leider ist es aber so, dass diese enge Koppelung etwas ist das die Cloud Provider sehr häufig vorgeben.

Und vielleicht nochmal kurz zum Thema MQTT im Detail. MQTT wird normalerweise eingesetzt, wenn ich, ich sage mal, unreliable Networks habe. Das heißt, Netzwerke, die nicht stabil sind. Im Normalfall reden wir hier von mobilen Netzwerken, das heißt irgendeine Verbindung über 2G, 3G, 4G, oder jetzt auch in Zukunft 5G. Und MQTT wird hauptsächlich immer dann eingesetzt, wenn ich keine Verbindung habe, die immer garantiert online ist. Als Beispiel, wenn ich jetzt ein Fahrzeug habe, dann kann es sehr gut sein, dass ich in einen Tunnel reinfahre und so meine Connectivity verliere. Und auch hier speziell in Deutschland, jeder der schon mal mit der Deutschen Bahn gefahren ist und versucht hat, mit seinem Mobiltelefon im Internet zu browsen, wird auch feststellen na ja, so 100 prozentig gutes Netzwerk ist es tatsächlich meistens nicht. Und dafür wurde MQTT genau entwickelt.

Aber auch einen Industriestandard zu schaffen, der es eben erlaubt, keinen Vendor Lock-in zu haben. MQTT 5 ist der neueste Standard, der 2018 veröffentlicht wurde. Und es ist wirklich so, ich sage mal, der Gold-Standard für neue Internet of Things Projekte. Und es ist der Nachfolger von MQTT 3.1.1. Und wer sich jetzt fragt hm, ich weiß gar nicht welche Version ich verwende? Die Chancen sind sehr gut dass eben MQTT 3.1.1, das ist der ISO Standard, verwendet wurde oder wird. MQTT 5 wurde ganz konkret entwickelt, um diese Cloud Connectivity besser zu machen und aber auch flexibel zu gestalten. Mit MQTT 5 ging es eben darum, und es war uns wichtig, im Technical Committee auch wirklich zu schauen, dass wir auf der einen Seite das Feedback einsammeln von den Nutzern, die über die Jahre hinweg in Produktion waren mit MQTT, um es zu verbessern das Protokoll. Aber auch, um die Performance zu erhöhen. Und da sind eben auch solche Dinge mitgekommen wie verbessertes Error Reporting und aber auch größere Skalierungen.

Als Beispiel, mit HiveMQ haben wir Kunden die eben zum aktuellen Zeitpunkt mehr als zehn Millionen Geräte miteinander über einen einzigen MQTT Broker eben verbinden. So, das Problem, das sich jetzt aber stellt, dass wenn ich jetzt Azure benutze, und das ist zum aktuellen Zeitpunkt so, obwohl Microsoft mittlerweile auch im MQTT Technic Committee mit drinsitzt, ist es so, es gibt auf der einen Seite keinen Support für MQTT 5. Und das ist sehr schade, weil, eben seit 2018 ist es der neue Standard, der auch in neuen Projekten verwendet wird. Aber auch, und das ist wirklich was, was schade ist, mit eben Azure IoT Hub ist es eben nicht möglich, industriekonformes MQTT 5 zu sprechen. Es gibt technische Limitierungen, und es ist eben sage ich mal, es ist kein MQTT im eigentlichen Sinne. Es basiert auf MQTT, ist aber eine proprietäre Version, die sich eben anlehnt. Und das Problem dabei ist, wenn ich heute mit IoT Hub eben arbeite, dann führt das zu einem Vendor Lock-in und ich kann nicht meine Lösung später portieren auf eben eine andere Cloud. Aber es fällt mir eben auch schwer, diese Connectivity eben auf standardkonformes MQTT 5 zu haben.

Das heißt, ich bin auch dazu verdammt in Anführungszeichen, dass ich eben auch die erste Case benutze, um eben ordentlich zu arbeiten. Weil es eben sehr, sehr schwierig ist mit Open Source Standard konform MQTT Bibliotheken mit IoT Hub zu interagieren. Und wir haben hier auch einen Vergleich der populären IoT-Cloud-Plattformen. Der ist unter diesem Link zu finden. Und da ist eben auch, sind die Limitationen genauer aufgelistet, um welche Limitationen es sich genau handelt. So, um was es hier aber auch in dem Webinar geht, was ist die Alternative?

Und eine der Alternativen, viele unserer Kunden machen genau das. Also allen unserer Kunden ist es wichtig Standard konformes MQTT zu sprechen, um eben genau nicht in die Wertschöpfungskette der eigenen Company einen Vendor Lock-in zu bekommen. Um eben hier auch flexibel zu sein für die Zukunft. Und dementsprechend - HiveMQ implementiert alle MQTT Standards zu 100 Prozent. Und das Thema, mit dem wir hauptsächlich arbeiten, ist eben Reliability und Scalability. Das heißt, wir haben Kunden, die mehr als zehn Millionen Geräte im Einsatz haben. Das sind zum Beispiel auch viele Automobilhersteller, also sehr viele Automotive Clouds laufen eben tatsächlich auf HiveMQ. Und HiveMQ ist eben der MQTT Broker, der eben diese Daten zu eben Datalakes, zu Machine Learning, Applications und so weiter weiterbringt. Das heißt, das ist dieser Connectivity-Endpunkt, mit dem sich eben die Geräte verbinden, um standardkonform eben auf der Geräteseite zu bleiben. Und HiveMQ ist eben dafür designed, standardkonform zu sein, und kann auf allen gängigen Cloud Plattformen betrieben werden, unter anderem auch Azure, was wir uns heute im Detail angucken werden.

Aber natürlich auch so Sachen wie Kubernetes sind sehr, sehr leicht machbar. Und wie gesagt, dazu werden wir jetzt gleich mehr sehen. Also HiveMQ ist wie gesagt dafür gebaut, auf diesen Plattformen betrieben zu werden. Und integriert sich neben dem, dass diese Device Connectivity über Standard MQTT passiert, integriert sich HiveMQ mit allen gängigen Enterprise Systemen. Und es geht los mit Apache Kafka, aber auch, was wir heute sehen werden, mit eben Cloud-Diensten, wie zum Beispiel Event Hubs, oder auch ServiceBuzz. Auch, wenn ich jetzt im Amazon Ökosystem wäre, eben auch mit all diesen Komponenten, ist es eben möglich. Und ich kann eben, ich habe die Freiheit, das zu betreiben in der Cloud, im Private Cloud, Public Cloud und so weiter. Genau, wir haben eben wie gesagt einige Kunden die das tun.

Wir haben 130 Kunden weltweit die das einsetzen, darunter alle deutschen Automobilhersteller in Produktion, aber auch Firmen wie Siemens oder die Telekom setzt eben hier darauf. Aber auch der größte Kabelbetreiber der Welt, Liberty Global. Aber auch Firmen wie zum Beispiel der Flughafen München, der eben diese Flughafen Use Cases eben über HiveMQ abbildet, um standardkonform zu bleiben und für die Zukunft gut aufgestellt zu sein. Genau. Und ich freue mich jetzt, dass wir eben das euch vorstellen können gemeinsam mit unserem Partner diva-e, die eben HiveMQ Partner sind. Und seh,r sehr tief diese Integration genau wie Microsoft Azure, aber auch HiveMQ schon häufig gemacht haben und da auch wirklich Experten sind. Wie bringe ich diese Komponenten zusammen, um Use Case abzubilden, der wirklich auch funktioniert, vom Proof of Concept bis zur Produktion. Und dann würde ich gerne an Sven übergeben.

Sven Kobow: Genau, danke schön. Richtig. Also in den folgenden Slides geht es auf jeden Fall darum eben zu zeigen, wie man HiveMQ in seine Azure-Landschaft integrieren kann. Wir gehen dabei davon aus, dass sich ein Unternehmen aus guten Gründen zum Beispiel für Azure entschieden hat, um seine Unternehmensinfrastruktur darauf aufzubauen. Und das ist auch völlig in Ordnung so. Das wollen wir gar nicht in Frage stellen. Es gibt durchaus gute Gründe, sich zum Beispiel für Azure oder für irgendeinen anderen Cloud Service Provider zu entscheiden, um dort letztendlich seine Workload hinzushiften. Genau. Bevor wir ins Detail gehen, wollen wir einfach nochmal ganz kurz betrachten, wie grundsätzlich die Architektur von einer IoT-Plattform aussehen könnte. Ich sagte gerade bewusst könnte, weil es mit Sicherheit sehr viel unterschiedliche Ansätze gibt, die dann im Einzelnen natürlich auch immer noch sehr stark vom konkreten Use Case abhängen.

Aber alles in allem kann man eigentlich sagen, dass viele Architekturen eben einem solchen Standard, wie er hier dargestellt ist, folgen. Letztendlich ist es so, dass die Daten von den IoT-Devices meistens über MQTT Broker oder vergleichbare Technologien eben in die Plattform reinkommen. Und dann dort oftmals splittet sich dieser Datenstream auf. Man kann sagen, es gibt so etwas wie einen Hot Path, wo es in erster Linie darum geht, Dinge wie Stream Processing zu machen und Daten vorzuhalten, um sie auch möglichst schnell wieder zu verwerten oder darzustellen. Dazu werden die Daten oftmals in Timeseries-Datenbanken gespeichert, die hoch performant sind. Dafür speichert man allerdings immer nur eine begrenzte Menge an Daten, üblicherweise sind das so die letzten 90 Tage. Das hat den großen Vorteil, dass man eben zum Beispiel in bestimmten Anwendungen am Ende sehr schnell auf diese Timeseries-Daten zugreifen kann.

Dann gibt es oftmals noch den Cold Path, in dem es dann letztendlich darum geht, die Daten dauerhaft zu persistieren. Um dann eben auch Dinge wie Analytics, Reporting oder auch Machine Learning auf den Daten ausführen zu können. Oftmals ist das Speichern deutlich langsamer, dafür aber auch deutlich kosteneffizienter. Also entsprechende Komponenten sind da oftmals deutlich günstiger in Bezug auf die Menge an Daten. Grundsätzlich kann man sagen, dass so eine Architektur eben diesem Muster folgt, dass man aus Daten Insights generiert, und aus diesen Insights letztlich Aktionen ableitet. Wenn sich ein Unternehmen jetzt für Azure entschieden hat, dann könnte man natürlich auch mit den Azure eigenen Bordmitteln eine entsprechende IoT-Plattform aufbauen. Der IoT Hub von Azure wäre da die entsprechende Komponente der Wahl, die eben alles mitbringt, was man dazu benötigt, um eine IoT-Plattform aufzubauen. Das bedeutet, dass letztlich der IoT Hub auch dieses Konzept des digitalen Zwillings beinhaltet, dass ich die Möglichkeit habe, über den IoT Hub meine Devices, meine Things zu verwalten.

Ich kann Konnektivität über unterschiedliche Protokolle wie MQTT und AMQP bereitstellen, und es gibt sehr viele SDKs für viele unterschiedliche Plattformen, um letztendlich die Software auf den Devices zu entwickeln und sie an den IoT Hub anzubinden. Ein weiterer großer Vorteil ist natürlich auch, dass der IoT Hub als interne Komponente hervorragend mit den weiteren Komponenten von Azure integriert ist. Und, dass man dann am Ende natürlich die Daten über diesen Weg wunderbar in seine Unternehmensinfrastruktur kommt und in seine weiteren Business Applikationen. Aber, wie wir schon gehört haben, im vorangegangenen Vortrag von Dominik, gibt es da an der Stelle einige Nachteile zu beachten. Vor allem eben, dass MQTT nicht vollständig unterstützt wird. Wenn ich MQTT implementiere und dafür nicht das vorgegebene Azure SDK verwende, dann muss ich mich an vorgegebene Kommunikationsschemata halten, und bin da auch in der Verwendung von bestimmten Konzepten oder Topics stark limitiert. Und natürlich bringt auch IoT Hub als Komponente von Azure entsprechende Limitierungen in Bezug auf die SKU Größe nennt sich das in Azure immer, also die Größe des IoT Hubs, die man bestellt hat. Wer da genauere Infos braucht, der kann gerne unter dem Link sich mal informieren über Quotas und Drosselung in Bezug auf den IoT Hub. Das bezieht sich eben meistens natürlich auf die Anzahl der Devices, also der gleichzeitigen Verbindungen die man aufbauen kann, nach ihrer echten Größe et cetera. Um jetzt genau diese Limitierungen aufzuheben und vollständig wie Dominik das auch schon sehr schön beschrieben hat, eben auch die Konnektivität im Sinne seiner Wertschöpfungskette abzubilden und auch da an der Stelle die volle Kontrolle behalten möchte, der kann natürlich wunderbar auf HiveMQ als Message Broker setzen, und den auch in Azure betreiben. Wie eine solche Architektur dann aussehen könnte das habe ich hier mal dargestellt.

Die Kernkomponente ist an der Stelle natürlich HiveMQ, den man in einem Kubernetes Cluster, also im Azure Kubernetes Service, betreiben kann. Um damit letztendlich auch die Integration in die Azure Plattform zu gewährleisten. An der Stelle muss natürlich auch dazu gesagt werden, HiveMQ ist ein reiner MQTT Broker, und im Gegensatz zum IoT Hub ist es natürlich so, dass man hier an der Stelle einiges an Funktionalität erst mal auf den ersten Blick einbüßt, was der IoT Hub mitbringt. Und das ist vor allem das Konzept des digitalen Zwillings. Das ist natürlich insofern wichtig, als dass ich in meiner Cloud Lösung immer auch Informationen über den Zustand und über die Konfigurationen von meinen Devices haben möchte, und das wird üblicherweise mit diesem digitalen Zwillings-Konzept abgebildet. Entsprechend haben wir uns Gedanken gemacht, welche Komponenten man noch benötigt, um entsprechend diese Funktionalität nachzubilden, um dann im Endeffekt quasi eine äquivalente Funktionalität bereitzustellen. Das umfasst natürlich auch den Aspekt des Monitorings, denn wer sich für Managed Services auf einem Hyperscale entscheidet, der tut das natürlich vornehmlich aus dem Grund, dass der Betrieb deutlich einfacher sein soll. Dass man in den Genuss von Hochverfügbarkeit kommt, et cetera.

Und da ist entsprechendes Monitoring auch immer eine ganz wichtige Komponente. Wie man jetzt hier an dieser Architektur-Skizze sieht, haben wir zum einen Ditto als Thing Twin Komponente implementiert, und zum anderen haben wir über die Verwendung von der Prometheus Extension HiveMQ eine Anbindung an das Azure Monitoring geschaffen, die dann am Ende natürlich wieder das Monitoring über Azure native Tools ermöglicht. Die Komponenten, die jetzt hier so gestrichelt dargestellt sind, das sind alles Komponenten, die man grundsätzlich weiter anbinden könnte. Also man ist auf gar keinen Fall darauf initiiert, die Daten jetzt, wie in unserem Fall die Demo gleich zeigt, an den Event Hub weiterzuleiten, sondern man könnte natürlich auch jede andere Azure Komponente an der Stelle verwenden, wie zum Beispiel Event Grid, den Service Bus, und auch für die Persistenz könnte man weitere Services natürlich benutzen.

Man kann über den Event Hub dann auch Azure Functions anbinden, die Daten in einen Azure Datalakes persistieren oder Azure Blog Storage, oder auch in eine Azure Time Series Insight Instanz einbinden. Um da entsprechend diese Services dann für seine Business Applikationen zu nutzen. Diese Architektur, die könnte man natürlich beliebig weiter ausbauen. Und man kann-, am Ende noch könnte man das Azure API Management einsetzen, um das Ganze dann mit einem Azure Active Directory für die Authentifikation oder Autorisierung zu integrieren. Oder man könnte natürlich auch, wenn man nicht den Event Hub benutzen möchte, sondern eh schon auf Kafka zum Beispiel setzt, könnte man an der Stelle natürlich auch Kafka oder andere Message Broker verwenden. Gehen wir nochmal auf das Konzept des digitalen Zwillings ein.

Letztlich beinhaltet der digitale Zwilling immer eine digitale Kopie eines real existierenden Assets. Es gibt da an der Stelle unterschiedlichste Definitionen. Ich möchte da gar nicht so in die Tiefe gehen. Letztendlich ist es so, ich möchte immer auch, sage ich mal, permanent über Schnittstellen verfügen, in denen ich Eigenschaften von meinen Geräten auslesen kann. Unabhängig davon, ob sie zum aktuellen Zeitpunkt zum Beispiel tatsächlich verbunden sind oder nicht. Ich möchte meine Dinge natürlich auch verwalten können. Und all das sind Funktionalitäten, die zum Beispiel die Komponente Eclipse Ditto zur Verfügung stellen soll. Eclipse Ditto hat den großen Vorteil, dass sie zum einen Open Source ist, zum anderen über umfangreiche APIs für das Datenmanagement verfügt, für das Live Streaming von den Daten, hat über die Connectivity API vielfältige Möglichkeiten für die Integration, zum Beispiel über MQTT, AMQP oder Kafka. Und Ditto bietet die Möglichkeit, das Payload-Format zu transformieren. Was einem natürlich die Möglichkeit gibt, oder die Flexibilität an der Stelle, seine Payload am Ende vollkommen flexibel nach den eigenen Wünschen zu gestalten. Und ist an der Stelle dann auch nicht auf irgendein Nachrichtenformat festgelegt. Das bietet einem natürlich auch wunderbar die Möglichkeit auf andere Standards zu setzen. Deswegen sind auf der rechten Seite hier diese beiden anderen Icons oder Logos zu sehen.

Das sind Institutionen, die sich aktuell sehr stark mit diesem Thema Nachrichtenformate und auch Standards, Standardisierung von Nachrichtenformaten auseinandersetzen. Zum einen die Open Industry 4.0 Alliance, bei der wir unter anderem auch Mitglied sind. Und natürlich auch die Plattform-Industrie 4.0, die mit der Verwaltungsschale auch an Standards arbeitet, um, sage ich mal, Future Assets dann in einem Modell, oder unterschiedlichen Modellen abzubilden. All das kann man letztendlich mit Ditto dann auch realisieren. Kommen wir zum Monitoring.

Ich hatte ja gesagt, dass wir mit Hilfe von der Prometheus Extension das HiveMQ Monitoring, oder die HiveMQ Metriken auch an das Azure Monitoring angebunden haben. Und so erhalte ich auch an der Stelle die Möglichkeit, natürlich meine HiveMQ Instanz zu monitoren, denn das ist auf jeden Fall ein ganz wichtiger Aspekt. Denn ich möchte natürlich zu jedem Zeitpunkt Informationen darüber bekommen, wie viele Devices sind verbunden, wie viele Nachrichten werden gesendet, gibt es irgendwelche Fehler, die auflaufen et cetera pp. An der Stelle können wir natürlich auf diesem Weg vollständige Transparenz dann schaffen.

Okay. Kommen wir mal zur praktischen Umsetzung von unserem Demo Case. Wie haben wir das gemacht? Also, letztendlich kommen wir jetzt tatsächlich zur eigentlichen Umsetzung, also, wie könnte das aussehen, wenn man für sein Projekt, für seine IoT Plattform sich dazu entscheidet HiveMQ auf Azure zu verwenden? Letztendlich ist es ja so, dass viele Leute sich für Azure oder für Cloud Plattformen entscheiden, wie ich schon gesagt hatte, um in den Genuss von Managed Services zu kommen. Also, sie wollen möglichst den Aufwand für Operations niedrig halten und diese Aufwände dann in Richtung Cloud Provider shiften. Und wie man letztendlich einen ähnlichen Effekt, oder in den Genuss der gleichen Vorteile kommen kann, das werde ich jetzt im Folgenden darstellen.

Wir haben uns entschieden, einem DevOps Ansatz zu folgen, so dass wir zum Beispiel die gesamte Infrastruktur als Code darstellen. Also die gesamte Infrastruktur, die wir in Azure provisionieren, die ist geskriptet. Uns ist da an der Stelle immer wichtig, dass wir diese Infrastrukturen provisionieren können ohne manuelle Einsätze. Weil, letztendlich man dadurch eben-, oder dadurch bekommt man die Vorteile, dass die Infrastruktur visioniert ist, dass sie testbar ist und dass sie auch zu jeder Zeit reproduzierbar ist. Also ich kann in diesem Fall auf jeden Fall auf Knopfdruck unterschiedliche Stages ausholen, oder wenn es notwendig ist eben komplett eine zweite Instanz von meiner Plattform jeder Zeit ohne zusätzlichen Aufwand und ohne die Fehler Anfälligkeit von manueller Provisionierung hochziehen.

Der Entwicklungsprozess in unserem Demoszenario, der gestaltet sich wie folgt: Die Entwickler arbeiten an dem Quellcode. Der Quellcode, der beinhaltet zum einen HiveMQ Extensions, zum anderen aber auch Dinge wie Kubernetes Manifeste, und alles Mögliche, was zum Beispiel in der Pipeline, in der Continuos Deployment Pipeline benötigt wird. Das ist alles in einem Quellcode Reposter, in einem Repository, auf dem die Entwickler arbeiten können, in dem die Entwickler ihre Arbeit dann in die Versionserweiterung überführen. An der Stelle nutzen wir auch Azure DevOps als Plattform.

Es ist so, dass durch das Commitment der Änderungen in Azure DevOps dann die entsprechenden Pipelines angestoßen werden. Hier auf der rechten Seite sieht man, welche Tools dann zum Einsatz kommen. Der Build-Prozess von HiveMQ Extensions wird zum Beispiel mit Maven durchgeführt. Dann der Entdocker-Container gebaut, und letztendlich wird die Infrastruktur über Terraform und Kubernetes eigene Tools dann in Azure, in die Plattform selbst überführt. Hier sieht man das Ganze nochmal dargestellt. Also der Commit führt letztlich dazu, dass die Pipelines angestoßen werden. Erst läuft eine Build-Pipeline die aus Quellcode letztendlich Programm-Artefakte macht, und die werden dann über Docker Registries und andere Mechanismen aufgerollt und in Azure deployed.

Werfen wir einen Blick auf unsere Event Hub Extension. Denn letztendlich ist diese Event Hub Extension in unserem Fall das Schlüsselstück für die Integration. Über das HiveMQ Extension Framework und das von HiveMQ angebotene Extension SDK kann man mit Java oder JBM basierten Sprachen den Broker erweitern und so auch quasi um neue Funktionalitäten anreichern. Und hat auch unter anderem die Möglichkeit, auf diese Weise natürlich seine Business-Logik schon in den Broker zu implementieren. Das ist ein großer Vorteil, den einem zum Beispiel der IoT Hub so an der Stelle nicht bietet. Der ist nicht erweiterbar. Das Verhalten kann ich an der Stelle nicht ändern.

In unserem konkreten Fall ist es so, dass ich die Extension in Kotlin entwickelt habe, sie ist konfigurierbar, und vom Grundprinzip her ist es so, dass sie die MQTT Nachrichten an einen oder mehrere Event Hubs weiterleitet. Und dabei natürlich versucht, die MQTT 5 Merkmale und Vorteile weitestgehend auch eben bei dieser Protokoll-Umsetzung beizubehalten. Hier sieht man das nochmal in der eigentlichen Funktionsweise. Also wir haben ein Thing, das heißt in diesem Fall Demo Device null, das hat zwei Features. Zum einen ebenso Bosch Sensor der Temperatur, Feuchtigkeit und Luftdruck ausgeben kann unter einer Batterie. Man schickt nun eine MQTT 5 Nachricht in diesem Format, das ist ein JSON-basiertes Nachrichtenformat, an den HiveMQ Broker, und die Event Hub Extension, die schickt dann letztendlich in Abhängigkeit zu der externen Konfiguration diese Nachricht dann an den Event Hub weiter. So sieht unser HiveMQ Cluster Setup aus in unserem Beispiel.

Wir haben in der Kubernetes als 3 Node Cluster, äh wir haben HiveMQ als 3 Node Cluster in den Kubernetes Cluster deployed. Dabei setzen wir eben neben der Event Hub Extension, die custom entwickelt ist, noch weitere Extensions, die man im HiveMQ Marketplace finden kann. Zum Beispiel die DNS-Extension, die notwendig ist, um HiveMQ im Cluster in Kubernetes zu betreiben. Und die schon angesprochene Prometheus Extension, um das Monitoring darzustellen. Ich hatte es schon erwähnt, hier ist es nochmal explizit dargestellt. Das HiveMQ Extension Framework ist auf jeden Fall das entsprechende Schlüsselstück, um eben eine vollständige Integration von HiveMQ in Ihre Infrastruktur zu ermöglichen. Und damit auch eine vollständige Integration in Ihre Business Plattform. Okay. Dann wird es jetzt Zeit, Ihnen zu zeigen, wie das tatsächlich konkret aussieht. Jetzt muss ich mal ganz kurz schauen. Als erstes möchte ich mal anfangen nochmal den Entwicklungsprozess zu visualisieren. Also, das ist jetzt hier nochmal dargestellt. Man sieht jetzt hier die Entwicklungsumgebung. Und der Entwickler würde jetzt hier an der Stelle in unsere HiveMQ Extension noch ein paar Änderungen einpflegen.

Angela Mayer: Sven wir sehen nur die Slide mit getting excited. Vielleicht nochmal probieren.

Sven Kobow: Ja, vielleicht muss ich diese Demo, vielleicht muss ich den Präsentationsmodus-, jetzt sehe ich, okay, alles klar. Dann fangen wir da nochmal an.

Man sieht hier die Entwicklungsumgebung, da habe ich jetzt eine einfache Änderung an der Extension vorgenommen. Und letztendlich möchte man diese Änderung natürlich dann auch in seiner Umgebung wiederfinden. Dazu benutze ich hier dann die entsprechende Änderung-, wird per Git in das Quellcode Repository überführt und gepusht. Und wenn das passiert ist, dann triggert man dadurch, dass die entsprechenden Pipelines in Azure DevOps loslaufen. Das sieht man jetzt hier an der Stelle, es wurde ein neuer Pipeline Run erzeugt, die Nummer 130, der dann auch die entsprechende Änderung enthält. Und hier werden dann von den Agents werden die notwendigen Schritte durchgeführt, also der Code wird ausgecheckt wieder auf dem Agent. Dann werden die entsprechenden Abhängigkeiten heruntergeladen, die Extension wird gebaut. Ich mache das mal ein bisschen schneller hier. Und dann wird letztendlich ein Docker Image erzeugt, was dann in eine Docker Registry gepusht wird und von da aus dann natürlich dann feste Deployments zur Verfügung stellt. Ich mache das mal noch ein bisschen schneller hier. (6 Sek.) Hier sieht man an der Stelle, das ist jetzt der Blick in Azure selbst gewesen. Man sieht da ist eine Ressourcengruppe die noch komplett leer ist. Das heißt, wir stehen quasi am Anfang, die Umgebung ist noch nicht deployed. Und nachdem jetzt die Bild Pipeline durchgelaufen ist erfolgreich, wird automatisch ein Release getriggert. ...

Angela Meyer: Sven, man hört dich gerade aktuell etwas schlechter. (Sven Kobow: Okay.) Ja jetzt bist du wieder deutlich zu hören.

Sven Kobow: Man sollte das Mikro nicht abdecken mit der Hand. Okay, also, was man jetzt hier im Hintergrund sieht, sind die einzelnen Schritte, die notwendig sind, um dann letztendlich die IoT-Plattform in Azure zu provisionieren, mit allem was dazu notwendig ist. Also es werden Ressourcengruppen erstellt, es werden Kubernetes Cluster provisioniert, örtliche IP-Adressen. Diese IP-Adressen werden mit Kubernetes zu den Services verbunden. Also das gesamte Setup, in seiner ganzen Komplexität, wird hier vollautomatisch durchgeführt. Ich habe das als Video gestaltet, weil in der Regel die Provisionierung von so einem Kubernetes Cluster durchaus einiges an Zeit in Anspruch nehmen kann. Und hier habe ich die Möglichkeit, einfach etwas schneller darüber hinwegzugehen. Wie man jetzt hier sieht, Terraform wird hier als Provisionierungs-Tool verwendet. Das heißt, in Terraform ist die Umgebung beschrieben mit all ihren Ressourcen und ihrer Konfiguration. Und kann so auf Azure angewendet werden. (8 Sek.) Genau, jetzt sieht man im Hintergrund die Ausgabe. Jetzt wird gerade der Event Hub erzeugt.

Was dann dabei natürlich zu beachten ist, ist, dass bei der Erzeugung von diesen Ressourcen natürlich auch zum Beispiel Verbindungszeichenketten und Primärschlüssel et cetera erzeugt werden, die dann am Ende an anderen Stellen notwendig sind, um die Komponenten weiter zu verbinden. Und auch das ist natürlich hier alles in dieser Pipeline enthalten, dass am Ende die HiveMQ Event Hub Extension dann auch die entsprechenden Schlüssel für die Verbindung mit dem Event Hub bekommt. So, jetzt ist der Vorgang abgeschlossen. Und wenn man dann wieder seine Sicht auf Azure aktualisiert, dann sieht man, dass hier die entsprechenden Ressourcen alle erzeugt worden sind. Was wir jetzt hier an der Stelle nochmal machen, ist einfach nochmal schauen, was ist denn alles in die Kubernetes Cluster alles erzeugt worden?

Zunächst einmal muss ich mir natürlich von dem neu erzeugten Kubernetes Cluster die Credentials, also das Passwort holen. Das geht mit den Azure CLI Tools, und dann kann ich einfach mit dem normalen Cube Control Befehl mir einfach eine Übersicht verschaffen über all das, was hier jetzt tatsächlich auch in dem Kubernetes Cluster passiert ist. Und jetzt sieht man hier, dass da zum Beispiel drei HiveMQ Nodes sind, entsprechende Services, die dann HiveMQ nach außen verfügbar macht über externe IPs et cetera. Genau. Was natürlich auch passiert ist im Hintergrund ist, dass die Ditto Instanz, die wir deployed haben, die wurde entsprechend konfiguriert. Ich sehe langsam, dass wir schon relativ viel Zeit gebraucht haben, deswegen gehe ich mal zum nächsten Video über. Was dann natürlich auch möglich ist, jetzt sieht man hier meine Konsole, in der ich Folgendes mache, das ist direkt im Anschluss.

Also, ich starte jetzt hier im unteren Bereich den Live View auf Ditto und habe im oberen Fenster eine Nachricht über MQTT versendet, und sehe das hier unten über den Ditto Live View oder das Live Streaming dann auch, dass es weitergesendet wird. Dann können wir uns einfach nochmal anschauen, wie sieht das jetzt grundsätzlich aus mit dem publishen von Nachrichten. Das wird hier auch nochmal dargestellt. So, und was jetzt im unteren Bereich gestartet wurde, ist tatsächlich ein selbst entwickelter Event Hub Client. Da nutze ich ganz einfach das Azure Event Hub SDK, um so einen kleinen Demo Client zu starten. Und an der Stelle, also dieser Client, der steht stellvertretend für zum Beispiel irgendeinen anderen Business Service, der auf dem Event Hub lauscht. Und im oberen Bereich wird jetzt gleich eine MQTT Nachricht gesendet, in dem Format, was wir in der Präsentation gesehen haben.

Und im unteren Bereich sieht man jetzt, dass die Nachricht dann entsprechend auf den Event Hub empfangen wurde. So sieht man, dass über MQTT Nachrichten über den Event Hub empfangen werden können. So, das war es auch schon so weit von der Demonstration. Ich hoffe, dass ich nicht zu schnell war, und dass ich einen guten Einblick darüber geben konnte, wie der Aufbau ist und wie wir uns das vorstellen, wie man entsprechend HiveMQ in Azure integrieren kann, um genau das zu erreichen, was wir eingangs beschrieben haben. Also, eine volle Integration von HiveMQ in eine Azure-basierte Unternehmensplattform. Damit wäre ich jetzt erst mal mit der Demo am Ende.

Hier findet man Infos darüber, wenn man sich für MQTT 5 interessiert. Wo findet man da weitere Quellen? HiveMQ hat da ausgezeichnetes Dokumentationsmaterial auf seinen Webseiten bereitgestellt. Auf der Webseite von HiveMQ findet man auch die Möglichkeit, sich HiveMQ als-, entweder in der Community Edition, oder auch als Testversion in der Enterprise Edition herunterzuladen. Wichtig ist aus unserer Sicht als nächste Schritte für jemanden, der plant eine IoT-Plattform aufzubauen, kennt euer Business, wisst genau, was ihr machen wollt. Denn letztendlich, es macht keinen Sinn, eine IoT-Plattform aufzubauen, weil es technisch möglich ist. Das gesamte Business-Konzept muss immer stimmig sein. Da können wir unterstützten bei Bedarf, gerne mit mir da in Kontakt treten. Genauso, wenn es um Themen geht wie Azure Konfiguration, oder auch die Entwicklung von HiveMQ Event Hub Extension, gerne mit mir in Kontakt treten. So Angela, ich wäre jetzt soweit am Ende und würde damit die Fragerunde einleiten.