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

Wie Sie mit dem HiveMQ MQTT Enterprise Broker MQTT 5 in Ihre Azure IoT Platform integrieren

Das erfahren Sie im Webinar:

Neben den technischen Vorteilen, die MQTT für die Kommunikation im Internet of Things bietet, besteht ein weiterer großer Vorteil darin, dass es auch von den IoT-Komponenten der großen Cloud Service Provider - und damit auch von Microsoft Azure - unterstützt wird. Bei genauerer Betrachtung muss man jedoch feststellen, dass die MQTT Unterstützung der Cloud Service Provider teilweise erheblichen Einschränkungen unterliegt. Eine vollständige Unterstützung von MQTT 5 kann keiner der Provider bieten. Wir wollen in unserem Webinar beispielhaft und praxisnah demonstrieren, wie der HiveMQ Enterprise MQTT Broker in eine Azure basierte Unternehmensplattform integriert werden und somit der volle Funktionsumfang von MQTT 5 für IoT Lösungen genutzt werden kann. Dabei beschränken wir uns nicht nur auf die Automatisierung des Deployments von HiveMQ, sondern gehen auch auf wesentliche Aspekte wie Monitoring, Authentifizierung und Autorisierung sowie Digital / Device Twin ein und zeigen so, wie HiveMQ mehr als eine Alternative zum Azure IoT Hub sein kann.

Jetzt online ansehen:

Die Referenten

Dominik Obermaier ist CTO und Co-Founder von HiveMQ und hat wesentlich zur Standardisierung des MQTT-Protokolls beigetragen, das heute im IoT unverzichtbar ist. Er unterstützt leidenschaftlich gerne Kunden bei der Entwicklung innovativer IoT-Lösungen und damit verbundener Produkte. Dominik ist Autor und Konferenzredner zu Themen wie MQTT, Java-Anwendungsarchitekturen, IoT und hochskalierbare Systeme.
Dominik Obermaier
CTO & Co-Founder, HiveMQ
Nach seinem Informatik-Studium war Sven Kobow einige Zeit als Consultant und Softwareentwickler selbstständig, bevor er bei der Maul-Theet GmbH 4 Jahre Leiter der Softwareentwicklung war. Mit einer zwischenzeitlichen Anstellung als Senior Software Developer bei Bosch, ist Sven Kobow seit April 2015 bei der diva-e als Senior Platform Architect tätig und unter anderem Founder des diva-e IoT Lab.
Sven Kobow
(ehem.) Senior Platform Architect, diva-e

Transkript zum 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.

Vorstellungsrunde diva-e und HiveMQ

Über Sven Kobow und diva-e

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.

Über Dominik Obermaier und HiveMQ

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.

Das Internet der Dinge

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.

Cloud Computing Plattformen

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.

IoT in der Cloud: Standard-Funktionalitäten

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.

MQTT im Detail

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?

HiveMQ: Eine 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.

Use Case: Integration von HiveMQ in eine Azure-Landschaft

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.

Die Architektur einer IoT-Plattform: Ein Beispiel

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.

HiveMQ als Message Broker

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.

Der digitale Zwilling

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.

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.

Umsetzung des Cases

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.

Quellcode

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.

Event Hub Extension

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.

HiveMQ Extension Framework

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.

Demonstration des Entwicklungsprozesses am Modell

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.

Was sind die nächsten Schritte?

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.

Q&A

Angela Meyer: Super. Ja, vielen Dank für die Insights Sven und Dominik. Genau, ich gehe jetzt mal auf die einzelnen Fragen ein, die hier jetzt reingekommen sind. Und die erste Frage lautet

Gibt es bereits HiveMQ Extensions für Service Bus oder Event Hub? Und woher bekommt man diese?

Sven Kobow: Dominik, möchtest du antworten, soll ich antworten?

Dominik Obermaier: Genau, ich kann gerne beginnen. Also, es ist so, es gibt jetzt keine Standard Extension. Was wir hier gesehen haben, ist die Demo, die eben von diva-e entwickelt wurde, um eben genau diese Integration zu zeigen. Es gibt jetzt zum aktuellen Zeitpunkt hier keinen Standard Connector. Es ist eben dieser, sagen wir mal, projektspezifische Connector, der eben da verwendet werden kann. Und wie Sven auch gezeigt hat, ist es eben möglich, hier über das Extension SDK dann nicht nur Service Bus oder auch Event Hubs anzubinden, sondern auch so Dinge wie Event Gritt oder dann auch direkt irgendwelche anderen Dienste direkt aus dem Extension SDK.

Angela Meyer: Okay. Und um jetzt nochmal bei den Teilnehmern auch abzufragen, ob Sie bereits HiveMQ für ihren MQTT Service in Ihrem Unternehmen bereits nutzen, habe ich auch eine kurze Umfrage vorbereitet. Die ich jetzt mal kurz starten würde. Und dann können die Teilnehmer weiterhin Fragen stellen und hier schon mal die Kurzumfrage ausfüllen. (8 Sek.) Ich würde einfach mal euch die nächste Frage vorlesen. Und zwar

Mit welchen Systemen werden bei HiveMQ Credentials und Device Hubs verwaltet? Ist dies integriert mit Ditto?

Sven Kobow: Also ich kann ja in Bezug auf unser Setup da erst mal antworten und dann noch an den Dominik weitergeben. Also, in unserem konkreten Fall ist es so, dass wir Mutual TLS verwenden, was von HiveMQ unterstützt wird für die Authentifikation. HiveMQ selbst bietet so keine Möglichkeit, Devices zu verwalten. In unserem Fall ist es auch nicht so, dass HiveMQ und Ditto integriert sind, das ist allerdings etwas was man durchaus machen könnte. Man kann entsprechende Extensions entwickeln, in dem man natürlich auch direkt den Authentifikationsprozess oder die Verwaltung mit Ditto integriert. Ditto bringt da an der Stelle alle APs mit die man dafür braucht.

Dominik Obermaier: Ja, vielleicht da noch hinzuzufügen ist, Device Management ist etwas das genau eben-. Normalerweise beim Device Management ist ja auch das Thema auf der einen Seite Authentifizierung und Permissions ist das eine Thema. Aber sehr häufig habe ich auch das Thema Provisionierung, aber auch Revocation. Wenn zum Beispiel irgendwelche Geräte beim Kunden gehackt wurden, oder wie auch immer, da möchte ich auch die Revocation haben. Das heißt, das gesamte Life Cycle Management. Dazu gibt es Lösungen, die normalerweise APIs haben. Die meisten unserer Kunden haben entweder eine eigens entwickelte Lösung, vor allem bei großen IoT-Deployments ist es oft so. Es ist aber auch so, ich kann auch die direkt vom Cloud Provider verwendete Lösung eben über APIs mit anbinden. Es ist halt zum Beispiel auch möglich, jetzt in dem Beispiel wurde es jetzt nicht so weit integriert, aber es wäre zum Beispiel auch möglich über Ditto zumindest einen Teil abzubilden. Dazu ist das Extension SDK da. Das Thema ist, es ist in den meisten Fällen, ist genau das Thema, wenn es um Device Management und um Provisionierung geht, es ist sehr, sehr kundenspezifisch. Und dementsprechend werden diese Systeme angebunden. Sehr häufig haben diese eine Rest-Schnittstelle.

Und diese werden dann über das Extensions System angebunden und das ist sehr, sehr einfach. Und das ist auch etwas, das genau Partner wie diva-e eben dann auch machen, und dann sehr einfach anbinden können. Um immer Use Case spezifisch das abbilden zu können. HiveMQ unterstützt natürlich Dinge wie Permissions, Authentifizierung, auch sehr, sehr fein granular. Man kann sogar soweit runter gehen, um genau MQTT Funktionalität für einzelne Devices sogar zu aktivieren und deaktivieren, wenn es nötig ist. Um wirklich auch ganz, ganz feingranular Devices, die Permissions zu verwalten. Es gibt hier, wenn man jetzt eben Out-of-the-Box was möchte, gibt es tatsächlich die Enterprise Security Extension, die sich eben mit Elder, mit Datenbanken, allen möglichen Datenbanken anbindet. Aber auch mit Ocean und so weiter. Das man direkt Out-of-the-Box verwenden kann. Jetzt hier in dem Cloud-Kontext ist es aber so, dass genau diese Integration mit Azure, wie es eben auch vom Sven gezeigt wurde, sich anbieten. Aber das ist auch etwas, da denke ich kann man auch gerne im Nachgang sprechen. Also mit den Kollegen von diva-e oder auch mit mir, um eben da mehr zu erfahren. Wie eben Kunden das konkret bei den konkreten Projekten auch machen.

Angela Meyer: Genau. Bei Interesse können wir das gerne im Nachgang auch besprechen. So, noch eine Frage kam hier rein.

Wurde die in der Demo gebaute Extension direkt in ein HiveMQ Image eingebettet? Werden die Extensions zur Laufzeit des Brokers nachgeladen? Und läuft die Extension außerhalb des Brokers?

Sven Kobow: Ja. Also in unserem konkreten Fall ist es so, dass wir die Extension in eine Pipeline bauen und gemeinsam mit HiveMQ in ein Docker Image verpacken. Die wird also gleich mit ausgeliefert. Grundsätzlich ist es so, dass man zur Laufzeit in HiveMQ Extensions aktivieren und deaktivieren kann. Man könnte also auch jederzeit so eine Extension in eine laufende HiveMQ Instanz rein deployen. In dem Demo-Beispiel haben wir uns jetzt mal dagegen entschieden das zu machen. Weil, letztendlich ist es so, dass da gewisse Rollout-Funktionalität ja auch von Kubernetes an der Stelle mitgebracht wird, um zum Beispiel die Ports wieder neu zu starten. Und wenn sich das Image ändert, da gibt es vielfältige Szenarien die denkbar sind. Grundsätzlich ist es so, dass die Extension natürlich dann in einem sehr separaten Bereich, aber innerhalb des HiveMQ Brokers, ausgeführt wird.

Dominik Obermaier: Genau. Vielleicht, wenn ich da noch etwas hinzuzufügen darf. Es ist ja auch so, dass genau diese Extension wird in einer Sandbox ausgeführt. Das heißt, ich habe eine Isolierung sichergestellt. Das heißt, ich kann auch nicht mit anderen Extensions sage ich mal-. Als Beispiel ich hätte eine Security relevante Extension und eine Extension, die nicht Security relevant ist, ist es nicht möglich, dass eben diese untereinander sage ich mal sich in die Quere kommen. Weil eben genau eine Isolierung sichergestellt wird vom Broker selbst. Und genau wie Sven auch gesagt hat, es ist zur Laufzeit möglich. Es ist auch hier, das ist noch nicht offiziell angekündigt, aber jetzt in den nächsten Wochen, wird auch für Kubernetes ein Operator von uns offiziell mit supportet auch. Der eben dann auch so Dinge ermöglicht, wie eben auch Reinladen von Extensions, eben direkt im Kubernetes Kontext. Es ist aber auch so, jetzt in der konkreten Demo, es ist natürlich schon ein sehr, sehr gutes Pattern, auch wenn ich diese Deployments machen kann, und jederzeit eben neu ausrolle und Kubernetes dafür benutze. Aber wenn ich jetzt eben-, ab und zu gibt es Projekt-Kontexte, wo eben das schwierig ist und wo ich im Kubernetes auch immer noch Extensions neu laden möchte. Und das ist dann eben möglich. Und mit dem Kubernetes Operator, der demnächst auch veröffentlicht wird und offiziell supportet wird, ist es dann sogar noch viel, viel leichter möglich. Weil eben dazu ein dediziertes Tool von offizieller Seite verfügbar ist.

Angela Meyer: Okay. Also ich würde noch eine Frage mit aufnehmen, und dann können wir gerne alle weiteren Fragen im Nachgang klären, da die Zeit jetzt schon vorangeschritten ist.

Welche weiteren Services werden zum Betrieb des Brokers notwendig? Wie sieht ein übliches Setup mit etwas weniger selbst betriebenen Services aus?

Sven Kobow: Also welche weiteren Komponenten, die in unserem Fall jetzt notwendig waren, um das so zu betreiben. Also das Setup, das basiert eben auf dem AKS von Azure als Kubernetes Cluster. Man könnte letztendlich, da es Docker Images sind, auch andere Services auf Azure benutzen. Würde dann natürlich nicht in den Genuss von den Vorteilen von Kubernetes an der Stelle kommen. Um HiveMQ im Cluster zu betreiben, braucht man auf jeden Fall, soweit ich weiß, die DNS-Extension. Ich weiß nicht Dominik, wenn das nicht ganz richtig ist korrigiere mich gerne. Kannst du nochmals den zweiten Teil der Frage wiederholen?

Angela Meyer: Ja.

Wie sieht ein übliches Setup mit etwas weniger selbst betriebenen Services aus?

Sven Kobow: Mit etwas weniger selbst betriebenen Services. Also, ich versuche mal die Frage anders zu beantworten. Ich muss zugeben, ich verstehe sie glaube ich nicht ganz. Das Setup, das wir gebaut haben, soll ja genau hier an der Stelle ansetzen, dass jemand sich aus gutem Grund für einen Cloud Provider entschieden hat, um eben die Vorteile von Cloud Provider betriebenen Services zu kommen. Und letztendlich sind alle Services, die wir an der Stelle nutzen, bis auf natürlich Ditto und HiveMQ, an der Stelle gemanagte Services. Wobei man an der Stelle sagen muss, dass HiveMQ gerade auch mit der Fehlertoleranz, die so ein HiveMQ Cluster mitbringt, eigentlich aus meiner Sicht schon sehr stark wie eine Managed Komponente eigentlich auch anzusehen ist.

Angela Meyer: Ja der Teilnehmer meint hier konkret MongoDB, wenn ich das richtig ausspreche.

Sven Kobow: MongoDB. (Angela: Ja.) Man könnte, also dadurch, dass letztendlich einige Azure Services, ich glaube die Azure Datenbanken, bieten sogar MongoDB-Kompatibilität an. Insofern könnte man auch da an der Stelle Managed Services benutzen, und MongoDB APIs in seinen kleinen Applikationen verwenden.

Angela Meyer: Okay. Genau, wie gesagt, auf Grund der Zeit würde ich jetzt die Fragerunde hier beenden. Und alle weiteren Fragen werden dann im Nachgang von unseren Experten dann auch beantwortet. Und ihr könnt gerne eben auch auf Sven und auf Dominik zukommen, falls ihr noch weitere Fragen habt. Außerdem wird die Aufzeichnung auch im Nachgang zur Verfügung gestellt. Hier auch nochmal die Daten von Sven. Ihr könnt hin auch gerne über LinkedIn oder GitHub auch anschreiben und connecten. Und er steht euch für alle Fragen bereit und diskutiert gerne mit euch noch weiter über die IT-Services. Hier noch ein Hinweis zu unseren nächsten Webinaren. Wir veranstalten wöchentlich unsere diva-e Webinare rund um SEO, Content, oder auch mit unserem Partner Spryker. Meldet euch gerne auf unserer diva-e Website zu den nächsten Webinaren an. Wir freuen uns auf eure Teilnahme. Ja, und jetzt danke ich Sven und Dominik für eure Zeit, für eure Insights. Und danke auch die Teilnehmer, dass sie mit dabei waren, und wünsche euch allen noch einen schönen Tag und bis zum nächsten Mal.

Dominik Obermaier: Bis zum nächsten Mal. Danke für die Einladung. Tschüss.

Sven Kobow: Danke, Tschüss.