MQTT mit Dominik Obermaier von HiveMQ #78

Moin zufolge 78 von einfach komplex spricht Gerrit, Ich hab mein Kompagnon dabei, Moin. Du meinst mich ne Hallo aus Hamburg, Moin Gerrit. Und zum Thema MQTT heute einen der größten Experten hier in Deutschland, kann man das so sagen. Hallo Dominik von Hive MQ Moin. Hi, Grüße euch. Schön, dass du da bist und uns an deinem Wissen und deinen Erfahrungen teilhaben lässt.

Magst du dich vorstellen und n bisschen was zu Hi FMQ sagen oder gerne auch n bisschen mehr, weil es ja sehr eng mal mit MQTT auch zusammenhängt, wenn ich es richtig sehe. Ja genau, genau mein Name ist Dominik Obermeier. Ich hab 2012 zusammen mit mit anderen Companions die Firma Hi MQ gegründet, hier in Deutschland mittlerweile auch sehr stark gewachsen, also sehr viel machen sehr viel in Deutschland zum Thema MQTT aber auch international.

Mittlerweile ist auch tatsächlich so, dass wir ungefähr 50% der Company ist in den USA 50% ist in in Deutschland beziehungsweise über ganz Europa und wir machen im Endeffekt seit 2014 mit den ja größten Firmen der Welt und auch in Deutschland helfen denen m curity Infrastrukturen aufzubauen, von Connected Cars über Smart Infecturing.

Mein persönlicher background ist Informatik, also ich bin studiert, Informatiker, hab dann im Endeffekt 2014 das Thema M Curity mit nach Deutschland gebracht, eben aus aus USA auch und bin 2014 auch im Standardisierungskomitee tätig und hab dann eben m curity versum 3 und versum 5 dann eben auch mit spezifiziert und ja du machst die letzten 10 Jahre nichts anderes im Endeffekt. Noch mal toll, dass du da bist. Und zum Start. Auch wenn wir das schon mal im

Podcast gemacht haben. Vor ein, anderthalb Jahren gibt es doch mal n Überblick über MQTT oder MQTT nicht nicht auch noch deutsch und Englisch mischen hier an der Stelle. Was ist das und was macht das so besonders? Ja, also MQTT ist in erster Linie n Kommunikationsprotokoll. Das bedeutet ähnlich wie es vielleicht viele, viele Zuhörer Zuhörerinnen des HHTTP fürs Web auch kennen und auch täglich

nutzen. Incuity wird benutzt für Maschine zu Maschine, Kommunikation, also es kommt tatsächlich daher 1999 also vor sehr sehr, sehr langer Zeit. Aus heutiger Sicht gab es ein sehr spezifisches Problem, dass eben Entwickler in USA, also von IBM und von der Firma Arkham, eher lösen mussten und zwar es ging darum, wie kann ich urtiblen Monitoring über Satellitenkommunikation über einen TCPIP Stack abbilden und ist heute immer noch so, dass es

relativ teuer ist. Wenn ich Satellitenkommunikation nutze. Auch in Zeiten von Starlink, also früher, war es natürlich noch viel, viel teurer. Und Andy Stan von Clark, das ist ein guter Freund von mir, der eben auch das MQT Protokoll 1999 mit erfunden hat.

Er meinte eben, dass ein einziges Byte, also wenn ich ein Byte mehr übertrage, kostet es pro Jahr ungefähr $10000 das bedeutet, wenn ich jetzt natürlich sehr, sehr, sag ich mal, schwergewichtige Protokolle, wie es HTTP auch ist, verwende um Nachrichten zu übertragen oder Daten zu übertragen, kostet es richtig Geld.

Und dementsprechend war so die Aufgabenstörung die die da war, OK. Wie schaffe ich es denn, dass ich öltables, die stehen da in der Mitte von nirgendwo, also das ist ja, es ist also in Deutschland ist das total schwierig, schwierig nachzuvollziehen, was nirgendwo bedeutet, also ich, ich wohne in Bayern, ich wohne nirgendwo, es ist aber immer noch 30 Minuten zur nächsten Stadt, so, hier ist es so, dass tatsächlich Stunden bis zur nächsten Infrastruktur

sind, Stunden und dementsprechend war es eben so, dass ausschließlich satellitenkomiker so nutzbar war für Öltablen Monitoring. Und Incuitive war die Lösung und die Idee dahinter ist sehr einfach, also für alle Architekten. Die meisten kennen das sogenannte Publish substribe Modell, es bedeutet klassisch Middleware, ich hab verschiedene Applikationen und ich entkopple die über eine Middleware und es gibt jetzt 2 Arten von von Middleware, es gibt sogenannte curing Systeme, das ist so

klassische Message Cues, einige werden vielleicht so Sachen kennen wie Rapid MQIBMMQ und eben diese Art von von Software, der andere Weg ist so Publish substribe. Das bedeutet, ich Abonniere und die Mittelwehr ist dafür zuständig, dass die Daten sag mal im Push Modell ausgeliefert werden, an die an die sogenannten Subsdriver, also an die Applikationen, die sich eben für bestimmte Daten

interessieren. Das ist eigentlich ganz schön, weil ich bekomm diese diese, was wir einst zu n Kommunikation nennen hin zum Beispiel Ich hab jetzt ein Ölpipeline mit dem Sensor, ich schickt jetzt mir irgendeinen Druckwert, schickt jetzt eben hoch in die Anführungszeichen Cloud. Und die Mittelwehr entscheidet nun, welche Applikationen interessieren sich denn für diese Datenpunkte? Und dann werden diese dann gepublisht. Das heißt, ich kann ein Datum bekommen und das kann dann an

hunderte 10 tausende. Wir haben Kunden, die haben buchstäblich Millionen von Geräten, wo dann diese eine Nachricht dann ausgeliefert wird und ein Push Modell bedeutet, wie man es jetzt auch kennt vom von Android oder auch von von Apple von IOS, das bedeutet wirkliche Push Kommunikation und das ist eben dann ganz schön, weil damit schaffe ich.

Genau diese, diese massiven Latenzverringerungen im Endeffekt. Ich krieg die Latenz vom Netzwerk eben hin und was sie damit erreicht haben ist, dass sie, in was sie damals aus Anführungszeichen Echtzeit nannten, wenn irgendwo irgendwas passiert, irgendwo in USA irgendein Problem mit der Ölpipeline da ist, wurden sofort Applikationen notified, die dann eben ganz woanders waren und das ganze zu möglichst maximal niedrigen Kosten.

Ja das da kommt das MQT Protokoll her, also was ist es ist ein Publisher Stripe kommunikationsprotokoll. Das entwickelt wurde für sehr sehr leichtgewichtig. Es wurde entwickelt für schnelle, also niedrige Latenzkommunikation und ist aber auch massiv skalierbar.

Wenn ich jetzt heute heute Blicke, wo wird MQOT eingesetzt, im Endeffekt für alle Connected Devices, also alles was was irgendwie IOT genannt wird, ist fast alles über MQOT abgebildet heutzutage auch für Applikations und Applikationskommunikation wird das sehr stark eingesetzt als Alternative zu sagen wir mal eher schwergewichtigen Message Brokern. Teilweise auch als Alternative zu Streaming Plattformen wie Kafka ist aber wie gesagt, da können wir vielleicht später

einsteigen. Gibt es verschiedene Use Casses auch wo man das auch einsetzen würde und ansonsten auch ganz viel wie gesagt physische Devices so Applikationskommunikation, also den Fabriken und so weiter. Dominik, Wenn ich es richtig verstanden hab, was du gesagt hast. Es ist halt es hat ne kleinere Latenz und es ist nicht so dick und ich spare beides genau wenn ich es verstanden hab aus 2 Gründen. Ich würd es dann mal auseinander nehmen wollen.

Weil nämlich einmal das Protokoll an sich, so es beschaffen ist. Und man kann sich es vielleicht

für unsere Zuhörer vorstellen. Ich hab natürlich die Daten, die ich senden will, also den echten Content, den Druck, den du gesagt hast, von der einen Pipeline zum Beispiel, ja, ja, das sind dann halt, das sind dann halt n paar Bytes, sag ich mal, die diesen Druckwert ausgeben, und jetzt muss ich immer, wenn ich irgendwas verschicken will, und das käme mir von der Post, ja, ich brauch halt irgendwie n briefumschlag ja, also die der Druckwert ist quasi der Brief und dann brauch

ich n Briefumschlag und was du gesagt hast ist der Briefumschlag. Der Umschlag bei MQTT ist besonders dünn, ja, und besonders leicht. Der verbraucht schon selber gar nicht viel. Ein paar anderen Protokollen wie dem HTTP oder was weiß ich was so gibt ist halt der Briefumschlag schon relativ

dick. Ja genau und ich kann halt quasi meine Daten ganz schmal verpacken, sodass ich keinen Overhead vom Protokoll mitbekomme, der im Notfall teuer sein kann, wenn ich, wenn ich dann nicht die dicke Leitung vom Internet habe, ja und aber das zweite was du gesagt hast ist auch, dass das das eine quasi was es schmal und elegant macht

und das zweite ist auch. Wenn ich es richtig verstanden hab, ist alleine das Kommunikationsmodell was anders ist, nämlich dieses Push, dieses Fire on forget, was ich ja auch gerne sag, irgendwie einmal eine Nachricht schicken und dann erst nach der Middelberg quasi an beliebig viele verteilen, ohne dass ich und jetzt noch mal das Gegenbeispiel im Internet müsst ich ja request Response machen, genau mit vielen anderen und so, aber vielleicht dröseln wir das noch mal für unsere Zuhörer aus.

Vielleicht magst du, wenn du das kannst einmal sagen, wenn es doch so cool ist. Und warum wird denn das nicht fürs normale Internet genutzt? Für unsere Webservice, also für für für Kommunikation mit einem ganz normalen Netzwerk, gibt es oder gibt es da sogar auch Bestrebungen? Wird auch genutzt, aber das ist noch mal.

Ist ja gut, weil wenn ich mir zum Beispiel klassische Webkommunikation anschaue, das ist ja HTTP, wird ja primär im Web auch verwendet, das Modell funktioniert so, ich hab hier irgendeinen Client, meistens im Webbrowser, kann aber auch ein Dienst sein, der zum Beispiel ein arrestful API benutzt und da hab ich request Respawns, das heißt der Client. Stellt eine Frage, geht zum Server und der antwortet dann.

Wenn ich jetzt aber wiederholt fragen Stelle, zum Beispiel also es ist super gut, wenn ich zum Beispiel Wikipedia aufrufe, ich möchte das wissen, OK, ich möchte das wissen, ich frage wieder Wikipedia Server, ich bekomme eine Webseite zurück und habe eine Antwort und es gibt jetzt eigentlich keinen Grund, dass ich ständig wieder zum Server gehe, weil die die Seite ist ein relativ statisch der Content, wenn ich jetzt Maschine zu Maschine Kommunikation aber habe ändern sich ja Daten, also

trieben wir als Beispiel Temperatursensor. Und ich möchte Notifiziert werden, wenn sich irgendwas etwas ändert, dann würde jedes mal, wenn eine Änderung stattfindet würde dann im Publish Subscribe Modell würde der sogenannte Publisher diese Daten aktiv senden und die Empfänger würden aktiv benachrichtigt werden vom Server und das ist so wie der Webentwickler, das ist ein bisschen so wie Server Side Events oder inner vielleicht ein bisschen dran oder auch webstocket Kommunikation.

Weil das ist auch sehr häufig, dass man sagt, Ja, Moment, im Web kann ich das auch, ich mache ein Web Socket auf und der Server hat die Möglichkeit, mich zu notifizieren, als Beispiel. Das Spannende ist MQDT über Web Sockets funktioniert prima und im Endeffekt jetzt nutzen unsere Kunden auch seit 2014 bereits, also auch wo Web sockets noch relativ neu waren.

Ein Beispiel wäre zum Beispiel ich habe eine Webseite und ich habe zum Beispiel irgendeinen Livetracker und jedes Mal, wenn zum Beispiel Fußballtracker und jedes Mal wenn es ein Tor

geschossen wird dann. Würde man die Push Notification von Server bekommen, weil es wäre einfach viel zu ressourcentensiv und und viel zu teuer, auch wenn jetzt der die Webseite von 10 Tausenden Leuten oder 100 tausenden Leuten jede Sekunde beim Webserver nachfragen würde, gibt es ein Update, gibt es ein Update, gibt es ein Update im Endeffekt, man

sagt einfach nur wenn es ein Update gibt lieber Server, benachrichtig mich und dann bekomme ich das eben zurück und im Endeffekt genau diesen Umschlag den du genannt hast. Man kann genau auch Web sockets wäre auch ein so ein Umschlag,

das heißt man kann. Mit demselben Kommunikationsmodell und auch mit derselben Software, tatsächlich mit derselben Serversoftware kann ich physische Devices, Apps oder auch Mobiltelefone, aber auch Webseiten und andere Applikationen einfach damit verbinden, entweder direkt über ich sag mal raw TCPIP oder eben dann auch über über Web. Sock ist und tunnle ich das eben, dann sag ich mal eher für Applikationen. Hast du ne Idee ob das jetzt schon?

Also das hört sich ja gut an und tatsächlich hört sich das sehr sehr gut an. Ich war auch schon überzeugt davon und tatsächlich passiert unsere.

Webseite unser Frontend unser App Bilder auch genau auf dieser Technologie. Wir haben nämlich auch n Web Socket und da läuft einfach MQTT, aber Web socket, weil nämlich moderne Webseiten ja eben nicht mehr ganz so statisch sind wie Wikipedia, sondern immer mehr wir Richtung Web Services gehen und so weiter wir immer mehr immer mehr passiert auf dem Server. Ich hab immer stärker vernetzte Dinge wenn es die passieren und dann kann ich natürlich den

Krieg ich diesen Echtzeit Effekt hin, ohne dass ich halt dieses Polling machen muss mit requestry Response und. Dann noch mal. Also dann ist das doch vielleicht sogar ja ne ganz coole Entwicklung des Internets.

Man muss natürlich einmal dazu sagen, die Architektur sieht ja ganz anders aus, wenn man sich jetzt mal aufmalt, weil wir ja ne dritte Komponente haben, ne, das will ich noch mal betonen, wir haben für alle Zuhörer, wir haben ja diese Mittelwehr da drin, die ne echte dritte Komponente ist. So wie ich sehe, also wenn wir aus der alten Welt kommen, wo wir denken Client und Client gleich Browser und Server gleich irgendwie n Server in der im Internet.

Und wir request Response haben. Dann telefonieren die tatsächlich direkt miteinander. Ich ruf an beim Server, der sagt ja hier hast du was, schickt die Antwort und dann wird wieder aufgelegt, ist auch die Verbindung aufgelegt ja was das ja auch teuer macht, weil wir jedes Mal wieder SSL, Verschlüsselung und so weiter aufbauen müssen.

Ja während beim MQTT dann und ich denke da kommt eure Firma dann auch noch mal bis ins Spiel, vielleicht kannst du dann noch was dazu sagen, da brauche ich ja ne dritte Komponente, nämlich den nämlich den technischen Server zu dem ne Verbindung jetzt vom Klienten hergestellt wird. Der ist aber im besten Fall gar nicht, der hat nicht selbst die Business Logik um um die Events zu generieren.

Typischerweise ist dann das noch mal ein drittes Backend, also der eigentliche Server, der wird dann aber technisch umgekehrt als Client, sodass dass ich quasi den Stern hab. Ich hab also einen dicken Server, der ist aber eigentlich nur da um die Nachrichten nach vorne und nach hinten zu zu transportieren, richtig? Ja genau, genau das ist aber sehr gut dargestellt tatsächlich. Und man muss sich natürlich fragen, ja Moment, aber warum

sollte man das tun? Mehr Komponenten mit mehr Komplexität also ist nicht einfacher, besser und es stimmt einfach ist besser was der der Vorteil davon ist, ist eben tatsächlich, dass die sowohl die Sender als auch die Empfänger der Daten extrem trivial sind, also selbst im Vergleich zu HTTP diensten oder auch zu HTP Libraries und das ist zum Beispiel besonders wichtig und da kommt MQT auch hier, wenn ich jetzt besonders sag ich mal. Sag ich mal.

Ressource eingeschränkte Geräte, hab also irgendwelche. Mittlerweile ist es n bisschen besser geworden, weil einfach Computer besser geworden ist. Aber als Beispiel früher die ersten Raspberry Pies, Arduino S und so weiter also die typischen IOT Hardware selbst HTTP ist relativ teuer, das da auch zu tun weil es weil es einfach n sehr komplexes Protokoll auch ist und auch die Schnittstellen auch die sag ich mal wenn ich etwas empfangen möchte, ich bau mir NHTTP Server.

Es ist auch mit modernen Frameworks immer noch ein

bisschen kompliziert. Es wird massiv wie Backupstrahiert, aber wenn ich mir jetzt, wenn ich jetzt zum Beispiel hergehen würde, dann würde ich sagen, ich möchte mir jetzt eine HTTP bibliothek bauen und ich nutze keine Frameworks, sondern ich starte wirklich hier, weiß nicht direkt von Safe from scratch, es wäre wahnsinnig aufwendig und es wäre und es würden wahnsinnig viele Fehler passieren und MQDT ist tatsächlich extrem trivial, selbst ohne Bibliothek zu

entwickeln. Und das ist auch super wichtig, wenn ich zum Beispiel jetzt, wir machen viel mit Automotive Kunden, sehr häufig kann man eben ja diese Bibliothek und auch diesen Overhead sich gar nicht leisten und dementsprechend ist man sehr nah auch an der Hardwareentwicklung und da ist eben Equity sehr, sehr einfach und trivial.

Warum? Weil alle Komplexität geht immer auf diese dritte Komponente, auf diesen Equity Broker, das ist ja der Server und die Clients sind im Endeffekt relativ Anführungszeichen dumm und es ist ja eigentlich im Endeffekt, wenn sich ein für ein Entwickler sieht das so aus, also wenn ich jetzt. Zum Beispiel Java oder Java Script Entwickler bin oder auch Rust.

Oder kann ich irgendeine Programmiersprache nehmen im Endeffekt ich mach nur die Operation, Bau die Verbindung zum Server auf, das ist Operation 1 Operation 2 ist sendedaten, das ist in den meisten Programmiersprachen einfach nur ein Method Call oder OK, hier ist hier passieren Events ich subscribe mich und dann im Endeffekt bekomme ich Events zugespielt in der Push Manier.

Und das war es im Endeffekt und das bedeutet auch wenn ich, wenn jetzt sich zuhöre, jetzt Beispiele im Internet angucken würden, dann will meist sagen, ja, Moment, es ist ja wirklich trivial, die Daten zu bekommen und zu senden.

Der Grund dafür ist eben weil genau dieser, dieser Server alle Komplexität wegnimmt und dementsprechend hast du auch viel, sag ich mal geringere Time to market, du entwickelst die Apps auch viel viel schneller und obwohl HTTP heute immer immer tatsächlich recht leicht zu implementieren ist, weil wir so viel Frameworks drum rumgebaut haben. Ist es so, dass MQT in den meisten Fällen noch viel, viel leichter. Ist umzusetzen.

Ihr habt es gerade schon anklingen lassen, Thema Broker Thema Client, lass uns noch mal ganz kurz in die Komponenten gehen, dass du dir noch mal sagst, die dazu zählen, also Server, das ist der Broker im MQT und die Clients und die die Daten konsumieren oder abonnieren. Genau, es gibt 2 Arten von Clients. Es gibt sogenannte Publisher und Subscriber. Ein einzelner Client kann auf beides sein.

Tatsächlich also man kann Daten bidirektional, also so senden außer Empfang und die andere Komponente ist der Broker, das heißt ich hab tatsächlich 2 Komponenten und all diese Clients wie wie Burkhard erklärt hat, sind ja dann komplett entkoppelt, also alle kennen nur diesen Server, aber sind komplett entkoppelt, die wissen nichts voneinander und einer der Vorteile ist übrigens ja auch tatsächlich.

Wenn ich Applikationen habe, die sich weiterentwickeln, oder ich habe oder ich weiß gar nicht, wie viele Sendern Empfänger ich habe, da kann ich das so auch entkoppeln, dass ich die dynamisch hinzufügen kann, auch wegnehmen kann.

Das heißt, ich muss das vorher gar nicht wissen, wie sich das weiterentwickelt, sondern ich kann dann eben auch einfach Services, das Microservices als Beispiel einfach dazu hängen, ohne dass ich irgendwie auf allen Komponenten, sag ich mal, das noch mal irgendwie anpassen muss ich. Will vielleicht so ne ne Sache ergänzen. Jetzt, wo sie diesen obere Flugebene noch machen, was MQTT ist, welche Komponenten wir haben.

Jetzt könnte sich der gewiefte Zuführer Fragen, aber wie, woher weiß denn dann der Subscriber, also derjenige, der an Nachrichten interessiert ist? Wie kriegt er die dann zugestellt? Ja, ich glaub den Punkten haben wir noch nicht besprochen, es gibt die ich glaub das ist einmal wenigstens kurz sagen, es gibt das Konzept der Topics, das ist quasi so, das ist quasi die Adresse ja dieser Levisumweg 3 im Prinzip also der also immer wenn ein Event abgeschickt wird

von irgendjemand der publiziert. Der muss ganz genau sagen, zu

wem hin. Ja, und das nennt man Topic, das ist quasi die Event der Eventname ja vielleicht nicht der Name, besser so ne Art Adresse, genau tatsächlich auch hierarchisch aufgebaut von der Spezifikation her und die Subscriber, die können dann sagen alle Nachrichten dieser Adresse hätte ich gerne ja und und die haben sogar n bisschen mehr Möglichkeiten, die können sogar sagen Wildcard mäßig subscriben, die könnten dann sagen alles was mit so und so

anfängt oder irgendsowas Slash Stern grob gesprochen das ist n bisschen anders bei einem QT. Diese ganzen Events hätte ich

gerne. Ja und ich glaube, dann haben wir das Bild zusammen, weil dann haben wir dann haben wir diejenigen die Klienten, die die Daten tatsächlich publizieren, die packen da quasi in den Adress dran den Topic und dann haben wir den, dann geht es, wird es Hingespielt zum MQTT Broker und der hat jetzt die Aufgabe des Matchings, denn der ist der einzige, der alle kennt, tatsächlich, der kennt alle Publisher und alle Subscriber und der stellt jetzt

entsprechend nach einem reinkommenden Event die Weichen, weiß wer muss das jetzt alles bekommen und spielt es den den entsprechenden Subscribern. Die sich auf dieses Topic subscribt haben zu ja ich glaub dann haben wir da einmal das technische Bild. Kompliziert würd ich sagen oder

Dominik hab ich was vergessen. Nee, ich, ich glaube nicht, ich glaube nicht, das ist ist ja gut, was aber da auch ganz spannend ist, vielleicht zu den Topics noch als Ergänzung, die sind auch auch dynamisch und das ist auch sehr, sehr spannend, weil du damit auch sehr hohen, sehr hohen Eskalierungen erreichst. Also nur so ne Perspektive zu bringen. Man kann zum Beispiel mit MQDT auch sehr viel im Heimautomatisierungsbereich machen, hier hab ich weiß nicht vielleicht. 10 verschiedene

amcurity clients. Vielleicht hab ich ein paar Applikationen, aber es ist sehr klein das Geld wenn ich jetzt kommerziell gehe, dann kann ich hier viel viel mehr haben, also die meisten High viny Kunden haben irgendwas zwischen 10 topics und das größte Deployment das wir haben, das ist ein Automobilkunde, die haben mittlerweile 400000000 Topic, Subscriptions und topics auf einem einzelner Installationen, das heißt ich skaliere auch auch sehr schön damit mit mit

derselben Installation. Und wenn ich sowas jetzt mit irgendwelchen anderen Technologien machen würde, das das wäre gar nicht möglich. Tatsächlich, einfach nur weil das Protokoll so effizient getrimmt ist. Genau genau dieses eine Problem zu lösen, dass dieses dieses Routing dieser Nachrichten maximal effizient zu gestalten, und der ist in massiv hohen Skalierungen, aber auch in

klein. Und das hat es ja gerade so Rausgehört bei Booker, bei der, der der Publisher bringt sein Topic mit seiner Adresse, das heißt? Muss da vorher schon die Adresse existieren am Broker, damit das passieren kann, oder, oder, oder wie wie läuft das? Sagt der Publisher wirklich hier, da möchte ich das ganze

senden. Das ist einer, der das ist einer der Sachen, die MQDT auch wirklich attraktiv machen im Vergleich zum so anderen Mittelwert, weil weil dieses dieses Publish substribe existiert ja auch in anderen Protokollen, das ist ja auch nichts neues, CMS zum Beispiel in der Java Welt ist ja auch etwas, also. Auch viele, zum Beispiel im im Frontend Bereich, ist auch seit vielen Jahren genau diese eventgetriebene Sachen.

Also es ist auch nichts Neues für glaube ich für viele Entwickler. Das dynamische ist auch tatsächlich etwas, das m Curity abhebt von den meisten Kommunikationsprotokollen, weil du kannst. Der Publisher kann jederzeit seinen seine eigenen Topics mitbringen und es ist auch hierarchisch aufgebaut wie wie ein Filesystem muss man sich das vorstellen und und im Endeffekt wäre es so OK ich bin hier ein neuer neuer Publisher. Im Endeffekt erstellt im Fallsystem einen neuen Ordner.

Im Endeffekt, so kann man sich das das vielleicht wirklich vorstellen, das ist möglich und auch dynamisch, hat natürlich aber auch oft ist die Frage Hey Dominik, aber das ist ja cool, aber was tut denn jetzt, wenn ich das gar nicht will und da kommt dann eben auch das rein, wo dann?

Genau, vielen, wie wir Geld verdienen damit, damit wir eben genau auch, sagen wir diese Enterprise Create Security und so weiter drumrum anbieten, weil in kommerziellen Lösungen möchte man es vielleicht auch gar nicht, dass jeder einfach da mitbringen kann, aber für diese klassischen sag ich mal IOT Use cases und diese Proof of Concepts ist es massiv wichtig, weil du damit eben viel viel schneller die Applikation entwickeln kannst, weil du musst eben nicht vorher alles schon

wissen, du musst nicht immer Spezifikationen schreiben, wie diese Dinge zusammen funktionieren, weil du eben das das das Routing einfach massiv entkoppelt, eben hast.

Über diese dynamischen Topics. Ich würd gern noch mal auf ein Thema zurück, was du gesagt hast und was mir, wenn ich auch mal über MQTT erzähle, bei Kunden, was immer so als erste Klatsche kommt so AH OK kompliziertes System, wir haben noch ne Komponente mehr und Single Point of Failure der Arme Message Broker der ja. Skalieren muss mit der Anzahl der Publisher und der Subscriber.

Ja, je mehr ich da hab, desto mehr hat der natürlich Arbeit und je mehr die publizieren und Subscriben, desto mehr Messages pro Sekunde fliegen ja quasi über diesen Message Broker und wenn der Halt platt ist, dann ist platt, ja ist vorbei mit meiner Kommunikation. Ja und jetzt jetzt versteh ich

ja auch eure Firma so, dass. Dass das ja aber auch nur eine logische Mitte ist, das muss man ja sagen, denn jetzt kann ich mir vorstellen, jetzt noch mal, da ist da ein Beispiel von dem großen Automobilhersteller mit den, was hast du gesagt, 4000400 topics 400000. 400000000. 400000000 OK, alles klar, völlig unvorstellbar, das wird ja nicht, also das ist wahrscheinlich, geht das logisch über den gleichen Broker, aber wahrscheinlich technisch nicht über den Gleiche, die gleiche

Büchse sag ich mal über das gleiche Pizzarack was irgendwo im Server steht, sondern ihr werdet wahrscheinlich n ganzes Rechenzentrum haben, nein, vielleicht nicht ganz so groß.

Aber schon n Paar mehrere Server, die logisch die Aufgabe des Message Brokers übernehmen, sich technisch aber quasi untereinander mit einem stark vernetzten Netzwerk austauschen und verteilen und so weiter und ich glaub da liegt der Hase im Pfeffer, auch wenn man das Enterprise gerade aufziehen wollt, da seid ihr wahrscheinlich die Experten, ne.

Ja, genau das ist auch n bisschen so wie mit wie mit mit allen Komponenten. Also das Thema Hochverfügbarkeit ist ja dann n Thema, wenn ich jetzt. Mir das angucke wie wie macht man es denn auch Traditionelles in der HTTP Welt? Also da ist es oft so.

Ich hab dann so Komponenten wie Note Balancer, ich hab dann vielleicht die HTTP server sind vielleicht auch in einer Datenbank Datenbank sind auch sehr häufig so singlepoint Fälle bei den meisten Applikationen aber auch hier die kann man dann auch Clustern und so weiter das heißt aber für Web AP Architekturen ist es sehr sehr gut verstanden von den meisten wie kann ich denn das Hochverfügbar auch gestalten mit

den einzelnen Komponenten? Zum Beispiel HTTP Server sind sehr einfach zu sag ich mal zu skalieren, weil normalerweise haben sie sehr wenig state, weil alles state ist in der Datenbank oder im Frontend oder wie auch immer, aber man versucht ja oft, dass genau diese APIS kein State haben, sondern im Endeffekt einfach nur ja der der Anreichereißen dieses State sich irgendwo herholen, entweder von der Datenbank oder von von Storage und der Local Enser verteilt dann normalerweise an

verschiedene. Also wenn ich jetzt mehr mehr scale brauche, neue neue Server, dazu der Local Enser verteilt zu den Servern. Der Lopalancer ist ja auch meistens ein Single Point of Failure. Also man kriegt die fast nicht weg, aber man man verschiebt die irgendwo hin und und meistens outsourced man die, also die wenigsten betreiben Lopalancer selber, sondern man geht dann eben zu einem Cloud Provider oder holt sich einen von Lopalancer und hofft dann im Endeffekt, dass dass das

Ausfallsicher ist. Bei Inquity ist es ein bisschen anders und das ist auch genau das Problem. Es gibt zum Beispiel so Lösungen. Moskito ist er, der also fast jeder, der mit MQDT arbeitet, hat irgendwann mal n Moskito in der Hand gehabt.

Es ist auch super klein, ist auf allen Linux Distributionen verfügbar, ist auch der mit riesen Abstand populärste MQDT Broker und den gibt es auch seit 2011 bereits, also der ist auch sehr sehr sag mal Battle testet auch das Problem ist aber tatsächlich, dass es wahnsinnig schwierig ist.

Dieses MQT Server zu skalieren, also erstmal 2 Probleme nach oben zu skalieren und Auswahlsicher zu machen und der Grund dafür ist, man muss sich so vorstellen, ein MQT Broker ist wie eine Datenbank, es hat State und wenn es ja weg wäre, dann verliere ich ja alle Sachen wie alle Informationen. Wer hat dann eigentlich abonniert, wer hat welche Daten gesendet, MQT hat auch noch eine Funktionalität die es noch nicht besprochen haben wenn wenn ein Dienst offline ist oder ein

Gerät offline ist. Dann dann dann habe ich ein sogenanntes Message Curing, das heißt, die Daten werden vorgehalten für diesen Client, bis er wieder online geht. Das heißt, ich verliere auch keine Daten. Das Problem ist also, wenn natürlich dieser zentrale Komponente kaputt geht, Stromausfall Server weg, was auch immer, dann ist aller Status weg und das ist auch glaube ich der Grund warum m Curity sehr lange nicht wirklich populär war, bis in die 2000 Zehner Jahre.

Weil es einfach wahnsinnig schwierig ist zu machen.

Und es gibt auch keine Lösungen dafür, keine guten, und wir waren auch tatsächlich die erste Firma, die am Markt sich überlegt hat, OK, wie mache ich denn das hoch verfügbar und jetzt macht man normalerweise was für Clustering nennen, das heißt, ich habe mehrere, ich sag mal physische Instanzen also beziehungsweise Prozesse auf verschiedene Server meistens oder im Idealfall und verbindet die untereinander und ähnlich wie bei replizierten Datenbanken tauschen die dann die Daten aus.

Und stellen eben sicher, dass wenn jetzt ein Knoten ausfallen würde oder mehrere Knoten ausfallen würden, dass ich eben weiterhin keinen Zustand verliere und es so aussieht für den Client, wie wenn alles gut wäre und für die Leute, die jetzt technisch einsteigen wollen, gibt es aber jetzt noch etwas, was sehr viel schwieriger ist über HTTP, also bei HTTP, also mittlerweile ist es ein bisschen anders geworden, aber mit den alten Versionen von HTTP war es ja noch so, ich bau eine

Verbindung auf der Service beantwortet mir und die Verbindung ist weg. Es bedeutet jedes Mal ein neuer Verbindungsaufbau und alles wieder weg. Endgültige hat eine hat stehende TCP Verbindungen, das bedeutet ich baue die Verbindung auf und die ist in Anführungszeichen unendlich lange offen, solange bis der Client nicht mehr offen

haben möchte. Es ist wahnsinnig schwierig, dass du TCP Verbindung von einem Server zum anderen Transferierst ohne Verbindungsabbruch so und da da kommen dann die ganzen Details rein technologisch wo man sich denkt, OK. Es ist gar nicht so easy, weil aus kleinen Sicht möchte man es

einfach halten. Man möchte sich nur zum Engpunkt verbinden und all die Komplexität wie was tue ich denn mit all diesen ganzen technologischen Low Level gedöns möchte man ja outsourcen und genau das machen wir, also wir

haben das Problem gelöst. Wie kann ich 2 Probleme, wie kann ich es auf der einen Seite hoch verfügbar machen und zwar so, dass ich im Endeffekt Zero Downtime habe, also fast alle unsere Kunden haben gemeinsam, so dass ein Downtime bedeutet, sie verlieren richtig viel Geld. In Fabriken und auch bei Autos.

Und dementsprechend musst du auch so Sachen hoch Verfügbarkeit Rolling Upgrades, das heißt, dass du Updates sag ich mal zur Laufzeit machst, ohne dass du sag ich mal ne Service decodation bekommst das eine Problem das wir gelöst haben und das zweite Problem ist was tue ich denn wenn ich immer mehr Nutzer bekomme auf der Plattform und du kannst natürlich immer dickere Server hinstellen, das ist ein Jahr aber irgendwann wird es zu teuer und dann skalierst du horizontal

indem du eben dann mehr Server dazu machst. Und als Beispiel dieser eine Kunde, von dem ich, von dem ich gerade gesprochen habe, der kann, der hat es. Ich glaube, der ist auf 10 knoten oder 12 knoten. Das ist ja noch gar nicht zu viel. Das ist, wollte ich gerade sagen, das ist ja erstaunlich überschaubar, noch irgendwie. Ja, es ist relativ klein also und uns in Perspektive zu bringen im Vergleich zu normaler mittelwehr Kunde aus USA hat, der hatte sagen wir ein GMS

Produkt benutzt. Also es war sagen sie nicht welcher Hersteller es war, aber es war ein kommerzielles GMS Produkt. System für alle, die gerade jetzt nicht wissen, was JMS ist. Es ist auch eine eine, eine eine Publis Subscribe exakt Architektur, Implementierung von Java genau also in der Java Technologie sehr bekannt sag ich mal ja, aber n bisschen n bisschen mit dickerem Umschlag sag ich mal. Ja es ist.

Sehr gut mit dickerem Umschlag. Ja und und bei denen war sowas so, die hatten Probleme mit der Skalierung, weil die hatten also deren dein Geschäft ist gewachsen und die hatten tatsächlich dann immer mehr Daten. Die, die drüber gelaufen sind und irgendwann kamen, kamen die Software an. Skalierungsgrenzen hatte dann zu zu Downtime geführt, hatte dann zu Kundenunzufriedenheit geführt, weil eben dann dann sag ich mal, in dem konkreten Fall Pakete nicht mehr ausliefern, also echte Pakete.

Es war waren waren Logistikunternehmen und dementsprechend haben sie nach einer Lösung gesucht und haben dann eben erstmal entdeckt, haben wir mit uns gesprochen und wir haben im Endeffekt einfach nur diesen Use Case ersetzt ohne irgendwelche. Zusatzfeatures von Equity, die sie haben einfach ersetzt und sie haben 8 mal Server gespart.

Also das heißt sie konnten um sie konnten um das Achtfache, die die Ressourcen reduzieren, einfach nur durch ein Replacement, durch eine effizientere Software. Und das Schöne ist, sie können es. Auch immer weiter skalieren. Weil also in unserem konkreten Fall, also wir supporten bis zu 100000000 Geräte mit mit demselben Cluster verbunden, es ist. Viel, viel mehr als die meisten unserer Kunden jemals erreichen

werden. Und und das heißt, du kannst von einem Gerät bis zu 100000000, kannst du elastisch hochskalieren, je nachdem wie B sub benötigt wird, könnte dir noch mal ganz. Kurz n bisschen aufklären was Knoten sind und unter was unter dem Cluster zu verstehen ist. Also ein Cluster sind ja auch schon mehrere Server gegebenenfalls oder genau Cluster ist.

Mehrere Server weil normalerweise ist es ja so, man möchte sag ich mal eine Installation auf einem Server, zum Beispiel irgendwo in der Cloud.

Auf auf einer virtuellen Maschine zum Beispiel oder auch auf Cubanitas. Es wäre dann ein Knoten, das wäre ein Endpunkt und mit mit einem Cluster, was du eben machst, ist du fügst mehrere, ich sag mal, physische meistens habe dazu und auch wirklich softwareinstitutionen dazu und die Formen ein logisches, was wir Cluster nennen und der Effekt ist dann, dass wenn ich jetzt wenn wenn der Client, also zum Beispiel jetzt ein Auto sich verbinden würde.

Zu einem dieser Knoten zu zum Beispiel wenn ich 3 Knoten und zu einem dieser 3 Knoten sieht es so aus, wie wenn es dasselbe Server wäre. Und auch wenn der Server weg wäre und der neue kommen würde, ist es dem Kleinen vollkommen egal. Der muss sich nicht drum kümmern, wie die Infrastruktur aussieht, der kennt einfach nur das ist mein Endpunkt. Ja und und der Server kümmert sich dann darum, dass das im Endeffekt das einfach möglichst

einfach ist. Ist n schwieriges Problem tatsächlich, das hat ich glaube, es hat ungefähr 7 Jahre gedauert, bis wir das richtig hatten, also. Aber aber wie ist es es so, dass eben genau das so wird? Encurity eingesetzt bei den meisten Forschung verfahrenen Unternehmen Dominik, Jetzt stell ich dir.

Gerade noch mal aus privaten Interesse ne ne ne ganz tiefe frage, mal gucken ob die zuhört, damit das auch aber also ich hab mich natürlich auch schon mal mit diesem Problem befasst, weil wir auch ganz viel MQTT einsetzen, das ist bei uns ja das backbound Protokoll für unsere gesamte Software Anwendung, ihr schafft es dann wahrscheinlich auch und du hattest gesagt das ist schwierig und genau das ist der springende Punkt, dass der Klient. Immer den gleichen und jetzt?

Jetzt gehen wir mal richtig aufs Brett, also im Prinzip die gleiche IP Adresse, sieht das Socket das Listener Socket vom MQTT Broker bleibt stabil für jeden Client, obwohl tatsächlich der der logische MQTT Broker mit aus mehreren Knoten, also aus mehreren Servern besteht. Ja das kriegt ihr quasi auch hin

oder müssen. Wenn ich jetzt also sag, also ich mach es noch mal ganz plastisch, wir haben im im einfachsten Falle haben wir, sagen wir mal einen Computer, der ist der Client, der publiziert, und dann haben wir noch n anderen Computer, das der ist auch der Client, der konsumiert, ja, und dann haben wir irgendwo anders netzwerkmäßig, aber erreichbar natürlich einen Server, der ist der Message Broker, der verbindet die beiden ja, beide

wählen sich hinzu dem Stern in der Mitte und haben ne STEHENDE DCP Verbindung so. Und jetzt sagst du, jetzt müssen

wir skalieren. Das ist n schwieriges Problem aus den genannten Gründen die du hast, wiederhole ich nicht so und jetzt ist es ja aber wichtig, das weiß jeder der schon einmal im QTT gemacht hat, dass ich natürlich sage, als Klient oder als Konsument, was beides technisch die Klienten sind, wer ist denn mein Server, an wen will ich mich verbinden, also ich muss da ne Domain eingeben oder ne IP Adresse mit dem Port ja TCP ja ganz klassisch so so und jetzt ist es

so, dieser Server ist jetzt platt weil er kann nicht mehr der hat der ist an seiner Grenze und jetzt stellst du den nächsten da rein ja. Dann brauche ich ja eigentlich, wenn wenn ich das jetzt so ganz transparent machen will für die Clients auch so ne Art Load Balance Server, der ne stehende TCP Verbindung Load Balance ohne dass die Clients das merken.

Das kriegt ihr hin oder müssen die Clients dann schon mehrere eingangs also haben die quasi verschiedene Eingangsserver, dass die sich untereinander verteilen, das verstehe ich, das ist ja noch relativ einfach wahrscheinlich, aber wie schaffe ich es, dass die Clients davon nichts merken?

Also was du, was du. Normalerweise machst also eigentlich über HTTP übrigens fast nie benutzt man statische IP Adressen, das ist eigentlich so n antipattern und selbst wenn man die benutzt, nutzt man normalerweise elastische IP Adressen, was ja eigentlich auch nur sag ich mal so ne Art

nobalancer ist. Also APS zum Beispiel bietet sowas auch an, das heißt normalerweise hast du hier nobalancer davor, das ist normalerweise und du kannst es entweder über DNS machen, also DNS lobalancing, das heißt du hast dann hier. My computer.com und da ist eben dann hinterlegt, dass wenn eben jemand den DNS Request von den DNS überstellt, dann wird einer dieser zum Beispiel 3 IP

Adressen zurückgegeben. Und wenn ich jetzt aber noch mal fragen würde mich noch mal neu verbinde, würde wieder 1 dieser Adressen zurückgegeben werden, das heißt die echte IP Adresse ist ganz selten, dass man die wirklich statisch einbaut, das ist eigentlich ein Antipad dann also bei den meisten Applikationen, was aber der springende Punkt ist.

Wenn ich zum Beispiel, das ist auch bei vielen HTTP load balancers wenn ich jetzt mal von endgültig HTP gehe, was gern gemacht wird, ist, dass ich sogenannte Sticky Sessions habe, und das bedeutet, wenn ich jetzt eine eine Webanwendung habe und ich hab zum Beispiel zum Beispiel Session Cookie, wäre es eine Möglichkeit, dann möchte ich ja im Normalfall, dass per HTTP immer derselbe Client immer zum selben Server geht, ja.

Das Problem? Ist Sticky Sessions am Localancer sind relativ teuer und es ist schwierig zu skelieren, weil der Localancer an seine Grenzen kommt, weil der dann auf einmal stateful ist. Und bei MQDT ist eigentlich das Pad dann du hast n State Less localancer und der Localancer verteilt wie er es gerade lustig findet.

Entweder Now welcher Server hat am nächsten Ressourcen round Robin oder irgendwelche super sag mal ausgeklügelten Mechanismen, aber wichtig ist, dass du eben nicht stateful bist und das unterstützen wir, weil der der Trick, den wir haben, ist, und das ist auch das, was es schwierig macht, ist, dass wenn der Client sich neu verbindet, dass der woanders

hingeht. So wenn du jetzt aber ja auf deine Frage zurück, wenn ich jetzt aber den Fall hab, dass zum Beispiel der Server weggeht, also wegbricht, was passiert jetzt dann mit den TCP Verbindungen, also einfach wie TCPIP funktioniert? Du siehst einen Verbindungsabbruch, das ist unvermeidlich, also es gibt Wege, es gibt Wege, aber das musst du auf der curren Ebene machen, es geht nicht auf, der geht nicht auf der Applikationsebene. Und was passiert in der Praxis?

Du siehst eine TCP Disconnection und der Client wird sich sofort wieder verbinden und wird dann zu einem dieses Server geroutet werden und kann so weitermachen auf einem Server wie wenn nichts passiert wäre und das NQIT Protokoll beziehungsweise der Server QT auch Nachrichten das heißt es sieht eigentlich aus Clientsicht aus wie einfach nur bisschen mehr Latenz und eben diese eine Reconnection ja. Cool, ich muss auch sagen, mein

Eindruck ist ja auch, dass MQTT. Und wir, wir machen es ja auch. Battle Testing, also wir benutzen es auch für Frontend, Backend, Kommunikation und dann für Backend, Backend, weiterkommunikation und so weiter das ist kann ich jetzt ja auch mal so sagen, für jeden der Mal starten will, das funktioniert einfach unglaublich gut, das ist unglaublich schnell skaliert, also ist einfach n tolles Protokoll.

Ja jetzt machen wir ganz ganz tief in der Technik, ich guck gleich auch gerade noch mal in die Augen, der hat vielleicht noch n paar andere Fragen, aber jetzt noch mal ne ganz ganz aktuelle Frage auch zu eurer Firma so das heißt. Im Auto wenn ich jetzt n modernen BMW kaufe, sag ich mal ich weiß jetzt nicht du hast keine, es kann ja auch Mercedes sein oder irgendsowas also mir n modernes Auto kaufe sag ich mal ja dann sind da tatsächlich MQTT Clients drin oder wenigstens

einer oder irgendsowas und. Und die fahren alle so.

Durch die Gegend und und benutzen MQTT als Protokoll, nur um irgendwie mediamäßig mal so Hallo zu sagen. Oder ist das sogar schon auch tiefer integriert, dass ich irgendwelche. Was weiß ich irgendwelche fahrsicherheitssachen damit abdecke oder irgend so? Wie kannst du uns haben wenn du willst? Nur mal kurz was sagen wie wie krass ist das eingesetzt?

Ich kann über einen. Kunden reden über die meisten Kunden in dem Bereich kann ich leider nicht reden, aber ich kenne nur einen einzigen Autohersteller, von dem ich, von dem ich es nicht sicher weiß, hundertprozentig sicher, dass er nicht incurity benutzt und auch hier bin ich mal fast sicher, dass ich es benutzt von den meisten Autoherstellern, die ich kenne, die ich namentlich kenne. Wir nutzen MQT und zwar für sehr viele Sachen, also im Endeffekt für alle Kommunikation zum Auto,

also fast alle. Du hast immer noch ein bisschen so Sachen wie Firmware, Updates und so weiter würdest du normalerweise ungern machen über MQT, weil MQT ist funktioniert am besten für für kleine sag ich mal Daten, also auf jeden Fall unter 250 Megabyte, wenn das eine Firmware sehr oft größer

sind heutzutage. Aber ansonsten ist endgültig hier so gut wie überall verbaut, in Produktion seit weit über 5 Jahren und ein Kunde von dem ich reden kann, das ist kein deutscher Kunde. Wir arbeiten mit fast allen Deutschen und Automobilherstellern in verschiedenen Bereichen zusammen, aber ein Kunde wo ich drüber reden kann ist eine Firma, die heißt Autonomic, die wurde von Ford gekauft, das ist eine connect Car Plattform und dann wäre eben auch eine Case Study online.

Wer sich das im Detail angucken möchte und. Die Nutzen tatsächlich auch am Curity und es ist auch sehr ist auch beschrieben in der Case Study für was genau. Also das heißt, wenn alles was vom Auto rausgeht und ins Auto reingeht ist es weitestgehend am Curity und kannst du.

Auch was sagen hier? Es gibt ja, es gibt ja so tolle Sachen, so auch hier, wenn ich jetzt mir n Auto ausleihe oder n Fahrrad ausleihe hier in Hamburg gibt es das ja, ist das ja ganz Standard ja ich ich ich hab halt 40 Apps oder für die Elektroroller oder irgendwas ja und den den.

Dann mach ich das Ding auf und dann kann ich das live realtime ja entsperren und so. Ich kann das Auto aufschließen zu ich kann es fast hupen lassen und so weiter ja ja ist das weißt du das ist das auch MQTT Technologie dahinter oder ist das was anderes? Wird das da auch schon eingesetzt? Ja ja hast. Du auch diese Produkte, die ich kenne.

Es gibt ein Produkt, das war ist eine unserer ersten Case Studies, die haben wir 2014 und da haben wir auch ne Case study online, das ist eben mit BMW Carsharing, das heißt das hieß früher Drive Now das im Endeffekt ist es. Produkt, wo du mit einer App n Auto mieten kannst und aufsperren kannst und so weiter dann in der Case Study, die eben auch das beschreibt, eben wie m für die T die Benutzerexperience von teilweise über 30 Sekunden von der Zeit zum ich.

Ich möchte, dass das Auto sich aufsperrt über meine App bis er sich richtig aufsperrt hat er nicht HTTP unter Haube vorher und wir haben denen dann geholfen 2014 schon oder 15 um den Dreh also vor 10 Jahren haben wir denen dann geholfen, dass sie das dann im Durchschnitt auf unter eine

Sekunde reduzieren konnten. Was natürlich die Benutzerfreundlichkeit deutlich erhöht hat, weil wenn ich jetzt nämlich, ich muss da vorstellen, jetzt gerade einkaufen und ich gehe nicht gerne einkaufen, aber wenn ich einkaufen gehe, dann reden wir jetzt meistens, wenn ich zum Auto gehe und wenn du jetzt da vom vom Auto stehst und dann willst du dir noch mit der App jetzt irgendwie aufsperren und dann wartest du 30 Sekunden, bis das Ding mal was tut, dann ist es nicht gut für die App

Store Bewertungen und wir konnten denen dann helfen, eben auch die Benutzer Experience zu verbessern, das war unser unser erster Automobil uscase. Seitdem haben wir aber deutlich, sag ich mal deutlich missionskritischere Use Cases bei fast allen Automobilherstellern. Wir hatten es neulich, weil wir sind zu einem.

Kundentermin mit einem gemieteten Auto mit der App gemieteten Auto gefahren, wo gerade gesagt ich glaub das MQTT, da hast du nur n Problem. Wenn du und das MQTT hilft dir dann auch nicht, wenn du in der wie wir in der Tiefgarage standen und einfach das Beton, irgendwie das Internet verklatscht sondern und dann wartest du trotzdem auf dein Zuschließsignal. Das kommt dann trotzdem nicht an. Ich kann es lösen, indem wir zum Eingang gelaufen sind, sonst hätten wir noch n Hotspot

gemacht und das Gebrückt oder irgendwas. Ja OK Automotive. Ist das eine? Du hast auch schon mal Manufacturing fallen lassen und das interessiert glaub ich auch immer viele unserer Zuhörer und auch uns persönlich, weil da machen wir auch viel mit der Heisenware, da gibt es dann eben auch n Broker, zum Beispiel NHFMQ Broker oder n anderen. Wie ist da die Architektur? Typischerweise ist das denn in der Fabrik der Server um im kleinen Serverbild zu bleiben oder ist es eigentlich schon in

der Cloud? Ja, also da. Ist es so, dass du oft so Hybrid bist? Es kommt auch ein bisschen drauf an, aber ich sag mal in weit über 9 von 10 Fällen hast du den Fall, dass dass du nicht zu produzieren aufhören möchtest. Wenn die Cloud Verbindung gerade nicht da ist, weil es kann immer was passieren.

Teilweise ist es dein dein Telekommunikationsprovider macht Probleme, es hat auch schon Fälle gegeben wo auch ABS zum Beispiel einfach mal komplett komplette Downham hat und wir machen Diensten und so weiter oder oder Azure. Also, und normalerweise gehen Produktionsunternehmen nicht in das Risiko, dass sie aufhören zu produzieren, bloß halt mal irgendwas langsames übers Internet.

Das heißt in diesen Fällen, wo du es nicht möchtest, stellst du normalerweise eine Equity Infrastruktur in jede Fabrik und meistens dann in eine Cloud, das heißt du hast so dieses einen Server in der Cloud und dann in jeder Fabrik mindestens einen Equity Broker. Und das heißt, alle Applikationen, und das sind dann auch oft so irgendwelche Assets, die dann über zum Beispiel irgendwelche Gateways, also wie zum Beispiel auch so n Gateway, das sich genau auch mit diesen

industriellen Protokollen integriert, sag Open Source tatsächlich, und dann ist in Amcurity übersetzt und der Broker würde dann was, was Bridging genannt wird, würde dann praktisch die Brücke schlagen und dann Subset der Daten in den meisten Fällen, die in der Cloud relevant sind, eben dann in die Cloud schieben, aber auch von der Cloud der Daten empfangen, die dann zurückgehen sollen. Und man muss sich so vorstellen, der Incuity Broker, der dann lokal ist, agiert wie ein Client.

Das heißt, er kann auch aus der Cloud raus, Publishen und auch Subsriben und das dann weiterverteilen in ja zu dem End Client würde ich es mal sagen, also n ja dreischichtiges. Modell, wenn man so will, genau, genau man. Kann da auch also sehr weit gehen. Also wenn du zum Beispiel Security Anforderungen hast, also viele unserer Kunden haben sogenannte demilitarisierte Zonen, das bedeutet du hast auch zum Beispiel.

Du hast die die IT in der Fabrik möchtest du normalerweise abschirmen von von den wirklichen Produktionscomputern, erstmal weil in der in der Praxis diese oft sehr alt sind und oft nicht mehr gepflegt sind, wenn es um Sicherheits Updates geht, also auch so Windows 9802 1000 ist es nicht anhört oft, dass dass man das noch sieht und man möchte diese natürlich möglichst weit weg vom Internet auch halten, weil eben natürlich wenn da irgendwas kaputt geht dann.

Oder Ransomware. Oder wie auch immer du möchtest ja nicht, dass dass es hier zu Problemen kommt und da kannst du eben auch dann wirklich Cloud Broker IT Broker in der Fabrik, Produktionsbroker in der Fabrik und dann eben auch sehr selektiv das eben auch dann trennen. Und weil wir gerade bei Sicherheit. Sind will ich auch einfach noch mal aus aus meinem eigenen Ansporn was reinpacken. Es ist nämlich so, dass das MQTT, obwohl es n anderes

Protokoll ist als das HTTP, aber genauso sicher ist wie unser

HTTPS, weil. Der Sicherheitslayer und Dominik widerspricht mir, wenn ich Quatsch erzähle, aber der das MQTT basiert genauso wie das HTTP unten auf unserem TCP Stack und SSL Zertifikate SSL ist ja das alte Wort, aber TLS, Verschlüsselung und so weiter funktioniert auf diesem Level, nämlich auf dem TCP Stack. Ja und beide Protokolle überliegen diesem, das heißt modernes MQTT was jetzt die Brücke schlägt zwischen zum Beispiel OT und IT, also dem.

Operations Netzwerk, also den wichtigen Shopfrover. Was nicht gestört werden soll, kann auch TLS 12 moderne Verschlüsselung etablieren und die Daten genauso sicher zwischen dem Internet hin und herspielen, wie es ein HTTPS beim online banking kann. Ja, das heißt, da ist nichts neu erfunden, das basiert alles auf exakt der gleichen Technologie, also die genau die gleichen Implementierungen und Concodes und und und. Bibliotheken können da genommen

werden, exakt, und das ist auch. Total wichtig, weil. Es ist so, wenn ich jetzt mir die typischen SSL beziehungsweise TLS Bibliotheken angucke, ob es das Open SSLS oder was auch immer das wird, von jedem werden wir eingesetzt.

Wir haben wahrscheinlich Milliarden von diesen Installationen, das heißt, man kann davon ausgehen, es ist hinreichend sicher genug und selbst vor n paar Jahren hatten wir hier in der an Hardbeef oder auch an andere Sicherheitslücken in Rekordzeit wurden die jetzt auch gepatcht weil die gesamte globale Infrastruktur für alle IT davon abhängig war.

Und das ist sehr gut. Auch, dass tatsächlich das MQT nicht das Rad neu erfindet, einfach nur, weil bei speziell bei Sicherheit möchte man ja auf das Altbewährte setzen, dass sie jeder benutzt und nicht irgendwie was Neues erfinden, weil man irgendwie denkt, man ist gerade smarter als alle Menschheit zuvor und, und das ist auch so n bisschen das Thema, das ich ehrlich gesagt n bisschen bemängele, auch bei manchen offenen Protokollen oder auch bei die, die dann eben auch

sagen, ja, Moment, ich, ich entwickle mein eigenes Security Modell oder auch meine eigenen Bibliotheken, jetzt hast du zum Beispiel. Sag ich mal ab und zu.

Ich mein das geht auch anders, aber zum Beispiel ich, ich erinnere teilweise an manche Features von OPCUA, die ja sagen ja im Moment, es ist ja sehr gut, weil wir uns eigenes Sicherheitsmodell haben, das ist ist ein Thema natürlich, man kann ja auch TLS machen, aber es gibt ja auch andere Features, oder wenn ich jetzt Richtung gehe Quick als Beispiel, das ist ja auch weitestgehend auf UDP passiert und das Problem bei UUDP Kommunikation, also wenn ich jetzt tief in das Stack gehe

ist ja, dass ich hier genau kein TLS nutzen kann. Man muss sich eben eigene, sag ich mal, Wege finden, das zu machen. Das heißt nicht, dass es weniger

sicher ist. Es ist aber einfach nur das Risiko, dass etwas gefunden als ein Fehler gefunden wird, der vorher noch nicht bekannt war, ist einfach höher, weil einfach die Wahrscheinlichkeit, dass es aktuell SSL Fehler gibt, wo alle Computersysteme betroffen sind, die noch unentdeckt ist, ist viel viel geringer, wie wenn ich jetzt so ein Nischenprodukt habe. Deswegen ne eigene Security

mitbringt. Deshalb bin ich n großer Fan davon das zu nutzen, was jeder benutzt, ich auch und protokollebene nur das zu machen was da jetzt immer der Valual ist. Ja und total. Wichtig, dass wir den Punkt noch mal gemacht haben. Beide, das ist manchmal n bisschen Überzeugungsarbeit, die man noch liefern muss, wenn man an Kunden, die, sag ich mal, mit der Digitalisierung gerade noch anfangen.

Ja so was Neumodisches verkaufen will, was ist da los und so weiter ja, man kann einfach aus technischer Sicht nur sagen, ja, das ist genau das, was das ganze Internet ist, und das ist der Standard, der Sicherheitsstandard, der auch überall. Angewendet wird und wenn der nicht sicher ist, dann hast du auch bei deinem Online Banking Problem ne. Also dann haben wir alle ein Problem, ne das ist noch mal sehr wichtig und die

Wahrscheinlichkeit, dass. Jemand erstmal die Banden angreift wie die Firma, ist deutlich höher. Genau die Sicherheit, nicht die erste Firma dieser dieser angegriffen wird das nach das andere. Jetzt gehe ich aber noch mal. In in die Wunde tiefer, weil wir gerade über Sicherheit sprechen. Noch einen, vielleicht noch einen kleinen weiteren Ding, denn wir haben ja jetzt, wer jetzt ganz genau zugehört hat, der weiß, dass wir 2

Verbindungen haben. Weil wir nämlich die die dritte Komponente haben, die wir nicht bei Client Server haben, ne, also ich nehme auseinander was ich sagen will, wir haben im im HTTPHTTPS jetzt sagen wir mal direkt einen Client der direkt mit einem Server spricht, da ist in der Mitte nichts mehr dazwischen, während wir wenn wir mit MQTT sprechen, dann haben wir den Client der mit dem Broker spricht, der Weiterverbindet zu dem nächsten Client, also einen Mann in der

Mitte, sagen wir mal jetzt kann ich natürlich. Zweimal verschlüsseln. Ja, ich hab nämlich 2 TCP Verbindungen, da muss man jetzt aufpassen.

Ja, also der der Publisher, der Client zu dem Server published, der kann natürlich ne TLS Verbindung aufbauen und der Subscriber der eventuell interessiert ist an diesem Event kann das ja auch ja aber der Broker in der Mitte was da jetzt passiert, das weiß ich quasi als Nutzer jetzt sag ich mal nicht da muss ich jetzt auf einmal volles Vertrauen schenken in die Firma, den Broker in der Mitte zurechtstellt weil zwar wird es dahin verschlüsselt und der Weg davon auch wieder weg.

Aber auf dem Broker selber, wenn ich jetzt die Daten nicht, und das müssen wir auch kurz auseinandernehmen, wir sprechen ja bei TLS von Kanalverschlüsselung, das heißt, ich kann es, ist quasi wie n panzerkabel, da fließen die Bytes durch, keiner kann in dieses Kabel sich anhängen und reingucken, aber die die Daten die da durchfließen, die sind wenn ich wenn ich jetzt nichts Besonderes mache, schon im so wie sie sind im Play Format drinne, ja quasi als Bytes, aber

können quasi wieder zusammengebaut werden. Ja das heißt wenn ich jetzt. Ich jetzt wirklich kriminelle Energie aufbringen wollte, als als auch Softwareanbieter.

Also jetzt mal nicht voraussetzen so, aber ich könnte quasi die Daten sehen, weil die kommen an auf den Broker und werden da weiter geschickt und ich könnte sie manipulieren, ich könnte abzweigen, könnte was weiß ich ja und soweit ich das weiß Dominik von Hause aus bringt die Spezifikation jetzt nichts irgendwie mit mit Ende zu Ende Verschlüsselung oder und so weiter ja vielleicht magst du da ein 2 Sätze noch zu sagen ob das n Problem ist bei euren Kunden. Nämlich genau diese, dieses

Vertrauen, dass ich in diesem Broker haben muss, an der Stelle und ob es sogar welche gibt, die dann quasi mit einer angestückten Lösung, und das geht ja mit tivi Hellmann zum Beispiel, relativ einfach damit so da quasi so ne Art Datenverschlüsselung noch hinzufügen zu der Kanalverschlüsselung um so ne Ende zu Ende Verschlüsselung zu erreichen, oder ist das kein Thema?

Es ist n wichtiges Thema. Security an sich ist ja auf verschiedenen Layern, also du ja, das heißt von von von, von Netzwerk als Orkans tief unten bis auf Applikationsebene. Es ist n großes Thema. Ich hab tatsächlich vor vor Jahren also eine zehnteilige Blogpostserie genau geschrieben über die verschiedenen Ansätze die man machen kann. Es ist ja nicht nur die Verschlüsselung, sondern es ist auch Trust. Also selbst wenn jemand OK lass mal aufdröseln, also erstmal mit Trust.

Also die Komponente an sich, da ist es tatsächlich auch wichtig, dass die ich sag mal die Komponente trusted ist und ich sag es jetzt deshalb auch, weil es gibt wahnsinnig jetzt, wenn jemand jetzt sagt OK Hey Infinity, Ich geh jetzt irgendwo

hin. Es gibt viele Open Source und es ist auch sehr gut, weil Open Source kann man weitestgehend inspizieren, speziell wenn es so Sachen wie Moskito, der Quellcode der hier ist, landet auch in deinen Linux Repostories, das heißt das ist schon mal gut, weil das heißt also auch das, dass es gibt eine eine kleine Firma in Deutschland, die Support eben anbietet, dafür aber im Großen und ganzen ist es halt so. Ich bin auf mich alleine gestellt, auch sicherheitstechnisch, das heißt

es ist gut wenn ich den Quellcode inspizieren kann, das ist auch der eine der Benefits von Open Source. Und das wär eine Möglichkeit. Es gibt aber auch andere Dinge wie es gibt zum Beispiel ein Produkt aus China, das ist auch ein sehr, sehr populärer MQT Broker, der wieder aus China eben entwickelt, und der ist auch ein Großteil davon ist Open Source, der hat aber dann auch deutlich mehr Features wie Moskito und hier ist es oft so, ist genau trust.

Also als Beispiel möchte man jetzt wie wie stark vertraut man dem also es ist. Ich rede konkret vom Produkt,

ist es in Erlangen geschrieben. Erlang ist eine Programmiersprache. Es war Open Source, ist aber hat eine sehr kleine Community, das heißt, es gibt sehr wenig Leute, die auch tatsächlich erlang Quellcode verstehen können und erlang kann auch zur Laufzeit eben Quellcode austauschen, das heißt wenn ich jetzt dann mir ein Paket runterladen und es installiere, kann es zur Laufzeit modifiziert werden, was

eben zur Laufzeit passiert. Als Beispiel so, und da muss man eben gucken, welches Risiko gehe ich ein, möchte ich jetzt zum Beispiel meine Produktionsprozesse davon

abhängig machen. Da ist dann der Trust beim Vendor und bei uns ist es so. Ich mein, Wir sind im Bereich MPDT Broker, Wir sind eben da der Marktführer weltweit, auch ist es buchstäblich, damit verdienen wir unser Geld, seit im Endeffekt 2012 und wir haben die größten Firmen der Welt, da ist die die Komponente Trust. Ist aber erstmal keine Sicherheit, das ist erstmal nur wie weit vertraue ich dir so grundsätzlich würde ich jedem empfehlen niemandem vertrauen.

Keine Software vertrauen unter keinen Umständen so.

Deshalb machen wir auch genau erstmal kanalverschlüsselung, das ist schon mal gut, wenn wir das haben und dann kommen aber noch andere Punkte dazu bei Sicherheit, das heißt normalerweise zur zur Kanalverschlüsselung, habe ich oft noch das Thema Authentifizierung und Autorisierung, weil bloß weil ich mich jetzt sicher mit dem Server verbinden kann, heißt es ja nicht, dass dass ich mich verbinden darf, weil das Beispiel, angenommen, ich habe

hier einen hier einen Broker und ich habe der der Publisher als sendet einfach Daten. Wenn jetzt jeder auf der Welt einfach sich sicher über Kanalverschlüsselung einfach zum Server verbinden könnte und alle Daten abzweigt, dann zweigt er die Daten sicher ab. Das klingt ja, weil hier im Endeffekt, dann sind die Daten trotzdem weg, das heißt, hier gehe ich dann rein und hier möchte ich Authentifizierung, Autorisierung haben, hier komme ich dann in Gefilde rein wie

Zertifikatsbasiert basierte Authentifizierung, die eben dann auf der TLS Ebene ist. Kennt man HTTP vielleicht auch, da komme ich in Gefilde rein wie wie?

Chase and Web Tokens basiert also o auf in dem konkreten Fall würde man da auch in dem oder Open ID connect teilweise, also das heißt ich, ich komme in all diese anderen Sicherheitsstandards rein, die ich im Web auch habe, und das kann ich mit Endcuity auch benutzen, das ist ganz wichtig, das heißt, dann bin ich schon mal authentifiziert, also darf ich mich verbinden und also das Thema Autorisierung, ich darf mich zwar verbinden, aber darf ich diese Art von Daten

bekommen, das heißt, das ist dann, sag ich mal Enterprise Security, die man, die man normalerweise implementiert in echten Projekten, und dann? Um jetzt auf deine Frage zurückzukommen, was tu ich dann mit den Daten selber?

Ende zu Ende Verschlüsselung und da gibt es da auch verschiedene Wege, aber ich sag mal der einfachste Fall wäre bevor der Publisher seinen Daten absendert bevor es in den Umschlag packt gehe ich her und Verschlüssel das zum Beispiel mit dem ich einfach sagen Passwort, das heißt mit einer Phrase die nur ich kenne und verschicke die und wenn jetzt jemand trotzdem die Daten abzweigen würde, wie auch immer dann dann würde ich im

Endeffekt einfach nur hier. Hier was sehen, was mir nichts bringt, weil es ist verschlüsselt. Das sind dann einfach nur irgendwelche random Bytes und wenn ich nicht diese pass Phrase kenne, dann kann ich es nicht nicht entschlüsseln, das wäre dann, das wäre dann eben wieder symmetrische Verschlüsselung symmetrisch, ja genau.

Und. Wenn ich natürlich ganz weit gehe, und es ist natürlich Best practice, wäre asymmetrisch, das heißt, dass ich auch im Endeffekt, vereinfacht gesagt, Zertifikats passiert, das mache ich, das heißt, das heißt, ich kann, wenn ich es verschlüssele, kann ich es nicht damit wieder entschlüsseln, und wenn ich es entschlüsseln kann, kann ich es nicht verschlüsseln. Es wäre natürlich ideal.

In der Praxis ist es aber so, dass ich damit die Kopplung, also dass ich damit die die Endpunkte wieder kopple, genau das ist. Eigentlich Paradoxon zu dem, was wir eigentlich haben wollen. Lusely Coupled Components, die sich eigentlich so gut kennen sollen. Und wenn ich jetzt asymmetrische Verschlüsselung reinbringe habe ich wieder, musste ich wieder ziemlich viel wissen von den genau schon in den Kleinen das große Problem speziell. Sagen wir mal bei Internet der Dinge.

Wenn ich jetzt das bei mir in meinem Netzwerk mache, das ich unter Kontrolle hab, alles gut, weil da weiß ich das ja auch.

Aber stellen wir uns das mal vor als Beispiel, ich bin Autohersteller, es ist ein relativ schwieriges Problem, dass ich sicher eine Verschlüsselung auf die auf das Gerät bringe, dass ich auch meine Endkunden ausliefere, weil ich möchte ja auch verhindern, dass dass dieses Geheimnis, sage ich mal, genommen wird, um sich dann auszugeben, als jemand das heißt, wenn ich dann hier, da gehe ich dann in ein Produkt, Sicherheit rein bei physischen Geräten, also es ist ein

schwieriges Problem, es gibt viele Lösungen dafür. Aber tatsächlich, das das sind so Sachen da wo wir auch das Beratung anbieten in dem Bereich, und da gibt es auch andere Beratungsweise, die sehr gut sind. Also man kann das sehr tief gehen und sollte man auch.

Ich glaube, wichtig ist nur für, vielleicht für die Zuhörer, das ist, wieso eine so eine Zwiebel, also es gibt auf allen Layern, muss man eben sich das angucken und es reicht nicht nur SSL zu machen, im Web übrigens auch nicht aus meiner Sicht. Und dann zu gucken, OK wo brauch ich denn welche Sicherheitsmechanismen und die wie gesagt, dazu hab ich auch vor einiger Zeit vor einigen Jahren auch ne zehnteilige Blogpost Serie geschrieben, die genau diesen Zwiebel in 10 in 10

Teile eben zerlegt. Cool, danke für die. Antwort, Tipp Top können wir ja verlinken, ja. Können wir verlinken? Genau. Wollt ihr noch was technisches? Besprechen, ich, ich. Ich kann auf dem Niveau logischerweise nicht mitquatschen, aber ich find es ziemlich cool und wenn ihr nichts technisches mehr quatschen wollt, hätte ich noch so n bisschen organisatorische Fragen zu MGTT der Community.

Ich hab eine Pseudotechnische. Pseudotechnische natürlich auch geht ganz schnell, ich glaub sie antwortet auch schnell, es gibt ja das MQTT Protokoll, ja es es gibt im Prinzip 2 Versionen, will ich mal so sagen von MQTT in meinem Gehirn ne das 3 Elfer soweit ich weiß also quasi das letzte Protokoll von Version 3 und dann gibt es das Fünferprotokoll und immer ganz platt gesprochen was der Unterschied in meinem also ich benutze noch das 3 Elfer erstmal muss ich mich outen.

Reicht mir erstmal und das Fünferprotokoll führt requestresponse Pattern noch oben drüber noch dazu. Aber jetzt kommt meine Frage ist ich will gar nicht auf das Fünfer eingehen auf das 3 Elfer aber ich frag aber was wo ist eigentlich Version 4 geblieben? Sehr, sehr gute Frage. Also Version 3 ist tatsächlich 311 es ist tatsächlich die, die die 11 genau also. Ist die offizielle Version. Das ist die erste offiziell spezifizierte Version, die auch ein Standard ist bei Oasis und bei bei ISO.

Und MQTT gab es davor, war aber im Endeffekt einfach nur

proprietär. Gab es Implementierungen? IBM hat dann irgendwann mal gesagt, wir versprechen noch nicht zu verklagen, wenn ihr es implementiert, aber es hat nicht gut genug für einen offenen Standard so und als als wir einen offenen Standard entwickelt haben mit 311, gab es davor schon NQT, Version 3 ist nur 31 eigentlich um es um es genau zu sagen, und das ist dieser Classic Version, die wird aber dies im Endeffekt ging es im Einsatz.

Glaube ich. IBM hat bestimmt noch Kompatibilität. Wir haben auch tatsächlich Kompatibilität, aber nutzt schon sehr lange keiner mehr und und wenn ich jetzt mir es angucke, wenn ich jetzt wirklich den den den Traffic Entschlüsse, also praktisch mir angucke, auf was wird denn überhaupt übertragen auf der Ebene? Normalerweise funktionieren Protokolle so, dass wenn ich jetzt so eine Art handshake wird da gemacht, das heißt. Wenn der Client zum Server geht, dann injiziert das der Client

erstmal. Hey, ich möchte mit dir lieber Server bitte in Version 331 reden, das ist Classic 311 oder in Version 5. Das heißt der Client kann sich das aussuchen in welcher Version er reden möchte und endgültig ist so kompakt, dass die Versionsnummer 3 wurde verwendet für 31, also für die Classic Version und leider geht es nur mal nur nur ganz. Das heißt ich hab 345 und hochzellen so. Und dann wurde eben amcurity Version 311 hat nämlich tatsächlich nur die Nummer 4.

Das heißt, wenn ich jetzt wirklich das Entschlüssel und den Weiterschlag machen kann, sehe ich die Version Nummer 4.

Das ist eigentlich 4 so und da mal die Diskussion natürlich, was machen wir denn jetzt eigentlich, weil eigentlich müssten wir amcurity Version 40 ja veröffentlichen und da war so, das ist aber komisch, wenn Version 4 einfach mal die Nummer 5 hat ja so. Aber man kann eben dieses Feld auch nicht mehr ändern, weil ich ja damit genau diese Kompatibilität, die Rückwärtskompatibilität, nicht

mehr habe. Das heißt, was ist passiert, OK, wurde auf verso 5 genommen und da haben wir gesagt, OK, eigentlich ist es kommet doof, wir machen jetzt verso 5, nächste Version wird dann 67 und so weiter und allein das was ich sehe, weil sonst ist das Macht der Entwickler kaputt wenn du wenn du hier denkst so du du Kommunizierst mit verso 5 mit verso 4 siehst du auch in der 5 als Beispiel also für den für den Zweck des dünnen Umschlags. Ist die ist die Version, die

kommuniziert wird zwischen Client und Server auf einen einzelnen Client integer begrenzt und 311 hätte keinen Platz gefunden. Deswegen muss es intern 4 sein, was im Protokoll steht für 311, weswegen wir nicht die Viererversion nach außen haben und nur die Firma dann also gut es. Sein sollte. Marketing folgt der Technik und nicht anderen. Genau. Sehr cool. Ich bin fast durch, ich lass dich gleich noch dazu ich nur noch kurz ne Frage, ist das bashed du mich wenn ich jetzt

sage ich benutz noch 311? Und nicht 5 kannst du da ganz kurz sagen. Muss man eigentlich jetzt 5 nehmen oder ist es völlig in Ordnung, wenn ich jetzt die Features von 5 nicht brauche, dass ich bei 311 noch bin und ne ich würd euch nicht, ich würd euch. Nicht bashen, ich mein, es gibt ja auch noch Leute, die Windows 2000 benutzen. Nee, aber du bitte, willst du jetzt aber. Nicht einfach Spaß für Seite. Nee, Spaß für Seite, nee, nee, gar nicht.

Tatsächlich ist es so, es ist kompatibel, es ist Feature Complete, es ist Rock, solid wird eingesetzt.

Für neue Applikationen würde ich tatsächlich empfehlen, Miversum 5 anzugucken ist auch weil es ist im Endeffekt dasselbe, nur mehr das heißt ich hab mehr Funktionalität die ich die ich habe übrigens ist voll rückwärtskompatibel auf Miversum 3. Das bedeutet, wenn ich jetzt schon eine Installation habe wo alle 3 sprechen, kann ich trotzdem versum 5 dazu tun, denn es funktioniert immer noch und für neue Applikationen, weil ich hab hier echt viele neue

Funktionalität drin, die. Die gebraucht werden.

Also da haben wir auch gesehen, also auch wir noch andere Hersteller, dass wenn du also Funktionalität, die abgeht in der Version, die du aber kommerziell nutzen möchtest, in vielen Fällen, ich geb dir nur ein Beispiel, es gibt einfach das nennt sich Share Subsruptions, das bedeutet, ich kann sag ich mal, es ist eigentlich wie wie wie, wie Kafka das zum Beispiel macht mit mit Topics, das heißt, ich kann, kann es aufsplitten, man kann es auch teilen, also mit Kafka

nennen, des Consumer Groups. Bei MQD Shares uscriptions, das heißt, wenn ich so einen ganz dicken Kanal habe, wo ganz Hochfrequenz Daten rausgepumpt werden und ich habe zum Beispiel ein Backend und möchte eskalieren, dann brauche ich einen Weg, dass ich sage mal diesen Datenstrom aufteile und MQDD 3. Kann das nicht.

Also wenn du ein Produkt hast wie hifin Q wir supporten ist auch für Version 3, also kannst du es trotzdem nutzen, aber das ist nicht im Standard, das heißt das ist am Ende ein populäres Feature von uns. Und mit Version 5 jeder endgültige 5. Broker Open Source, kommerziell wie auch immer, musst es unterstützen und dementsprechend kriegst du genau diese Features umsonst.

Also es gibt eigentlich keinen Nachteil auf 5 zu gehen, weil du du musst diese Features ja nicht nutzen, aber du hast die Optionalität, deshalb würde ich empfehlen für neue Sachen auf 5 gehen. Ich würde aber nicht Produktionssysteme anfassen und wenn du jetzt keins diese Funktionalität benötigst, danke. Alles klar, so Gerrit jetzt. Hab ich alle meine meine mir auf dem Herzen brennenden Fragen rausgeschossen? Ja, jederzeit. Noch kommt noch was nachher rein, ne. Genau es. Es passt ja ganz.

Gut ins Thema genau, ich wollte dich mal Fragen, Dominik wie MQTT organisiert ist ne und du hast 1999 glaub ich als Grundsteinlegung nenn ich es jetzt mal oder Erfindungsjahr für MQTT genannt und du hast gesagt du bist auch aktiv im Standardisierungskomitee wie ist das organisiert? Wer beteiligt sich da und und wie werden vielleicht auch Entscheidungen getroffen? Ja, genau. Organisiert ist es als offener Standard, also ähnlich.

Wie ist es bei wie man es erwarten würde, ist ähnlich, wie es zum Beispiel HTP ist, es bei W 3 C organisiert endgültig, die ist bei bei Oasis organisiert. BPMN glaube ich ist hier zum Beispiel auch standardisiert, du hast ganz viele andere Kommunikationsprotokolle, die sind bei bei Oasis, das nennt sich Governing Buddy. Und die kümmern sich eben auch darum, dass eben auch alle Hersteller, dass es zum Beispiel so Sachen wie Patentrecht zum Beispiel auch passt.

Das bedeutet, dass jetzt niemand hergeht und zum Beispiel Sachen über MQTD patentiert und dann an alle User hingeht und sagt, ja, Moment hier, wir wollen jetzt aber Entschädigung oder Lizenzgebühren haben und so, und deshalb ist es auch wichtig, weil ein Standard aus meiner Sicht ist kein Standard, wenn du genau diesen governing Boarding nicht hast, weil bloß als Open Source ist. Heißt es ja nicht, dass das

nicht passieren kann. Das ist zum Beispiel auch der Unterschied zu so Open Source Software wie Kafka, Kafka als Beispiel ist ja immer, als Open wird es immer genannt, hat aber keinen governing Body, das heißt es könnten jederzeit, könnte, könnte die Firma die eben sag ich mal hauptkontribute ist könnte sag ich mal Änderung auch vornehmen, Kafka ist das echt bei Apache, das ist ähnlich, aber aber zum Beispiel nicht so stark wie Oasis, weil ja Apache ist zum Beispiel deutlich mehr

auf Code Ebene währenddessen. Oasis ist wirklich komplett für Spezifikationen gedacht, das heißt, es sind auch die Maßnahmen und auch im Endeffekt die ganzen Lidl Strukturen

drumherum sind dafür gebaut. Im Endeffekt Leute die die noch nie in in Gremien gearbeitet haben, es ist langweilig und träge uns uns so zu nennen jetzt tatsächlich ist es so du du hast hier Vertreter von vielen Firmen Masse wir waren die einzige deutsche Firma 2014 die eben damit gearbeitet hat, da war noch so viel mit Cisco war dabei.

IBM war dabei und IBM war damals der Haupttreiber für MQTV, also 5. In 2018 hat es ne andere Firma wie Microsoft noch dazu bekommen, nachdem die sich dann weitestgehend von IMQP verabschieden, verabschieden wollten und in Richtung MQT auch dann gegangen sind. Das heißt du hast dann da mehr Leute am Tisch und genau dann ist es so wie man es ganz langweilige Meetings Leute machen, Vorschläge wird bearbeitet, wird ne Spezialisierung geschrieben wird, review wird diskutiert.

Und irgendwann bist du n Punkt, wo es dann einfach final ist.

Und es dauert normalerweise Jahre und dann das Schöne ist aber dann, wenn du also MQTT ist nicht nur n Oasis Standard, die meisten werden davon wahrscheinlich noch nie gehört haben von Oasis, es ist aber auch n ISO Standard und das ist das ist tatsächlich sehr wichtig, weil konkret in Deutschland ist es ja so, dass ISO wird sehr, also es ist sehr wichtig für viele, dass eben das auch hier unter unterm Bekanntenkomitee auch ist und von daher.

Wenn du Oasis n neuen Standard Rausbringt für MQT ist es auch automatisch n ISO zertifizierter Standard und Kontributionen. Jetzt zum zur wirklichen Technik. Du hast ja gerade gesagt, zum Beispiel bei bei der Version 5 gibt es neue Features, die kann theoretisch jeder machen oder auch nur n begrenzter Kreis wie läuft das also?

Ja, also im Großen und Ganzen. Jeder kann die Vorschläge machen, es war auch offen, also es war auch wirklich n Community afford und da wurde ganz ganz viel gesammelt von Herstellern, von Endnutzern, ganz vielen auch die.

Und dann so ein bisschen zu gucken, OK, was sind denn so auch die die Patterns und das Problem, dass eben viele Standards haben ist, dass dass die immer aufgeblähter werden und immer komplexer werden und und das ist auch so tatsächlich, das ist, auch wenn ich jetzt mir aktuelle HTTP version angucke, es ist wahnsinnig flexibel, ich kann total viel machen, aber es bringt dir ja nichts, wenn die Bibliotheken nicht alle Features supporten, weil am besten ist es, du hast einen Standard, der

einfach ist, aber dafür ist es komplett introperabel. Weil die Idee hinter Standards ist ja, dass du 100% Interoperabel bist von der Programmiersprache, von der Plattform und halt auch von den Herstellern. Das heißt, dass du als Nutzer, als Programmierer oder Software Developer, dass du in hier in kein Risiko reingehst, dass du in irgendein Login reingehst entweder Plattform oder wenn du Login oder oder oder auch selbst bei den Programmiersprachen, es wäre zum Beispiel ziemlich fatal.

Es ist das Problem, dass zum Beispiel Java Messaging Service hat, na ja, es ist halt für Java, ist es doof, moderne Standards. Sind normalerweise Agnostisch gegenüber Programmiersprachen. Ob es Linux, Windows, irgendwas

anderes ist. Also Plattform ist aber auch Agnostisch gegenüber den Herstellern und von daher ist es schon so, dass bei NQET konkret wird drauf geachtet, hey, wir wollen unter keinen Umständen zu viel aufgebläht haben, es war wirklich das Minimum Set und und dann haben wir es so flexibel gestaltet, dass sag ich mal diese Special Interest Features. Sehr einfach und top gebaut werden können dann kommerziell, damit es dann später wieder zurückgehen kann.

Also das ist die Philosophie, es ist im Endeffekt ist eine Unix Philosophie, Mach ein Ding und mach es richtig gut, ähnlich wie TCP und deshalb bau ich es auch darauf auf die anderen Bausteine und ich glaube wir waren sehr erfolgreich damit. WSN 5 hat deutlich mehr Funktionalität währenddessen WSN 3 ist definitiv das absolute Minimum Set also es wäre sehr schwierig irgendeine Funktionalität wegzunehmen, also da ist aus meiner Sicht nichts drauf was aufgebläht ist.

OK dann würde. Ich sagen, kommen wir so langsam Richtung Ende. In Anbetracht der Zeit, ich würd aber noch dir die Gelegenheit geben, Dominik noch ja sag noch

mal, haben wir was vergessen heute, was du Dominik noch loswerden möchtest? Zum Thema MQTTHIMQ the Community oder irgendwie n Aufruf? Glaube nicht, also ich find es.

Find es sehr gut. Also wir sind tatsächlich auch sehr tief in ne Technik rein reingegangen und ich glaube wenn es da Zuhörerinnen und Zuhörer das spannend finden und sagen, Hey ich möchte noch tiefer reingehen oder ich möchte vielleicht auch Bilder sehen, was ich jetzt hier die Bilder, die jetzt verbal gemalt wurden, ich möchte die auch sehen und so weiter. Es gibt auch viele Ressourcen, die, die wir auch gemacht haben, die ich auch persönlich gemacht

hab. Die hab ich in erster Linie für mich selber aufgemacht, weil ich vergesse es ja häufig Sachen so, dass ich die auch griffbereit habe für Leute, die gerne lesen, gibt es, ich sag mal NPDF, aber auch als Blogpostser, das nennen sich MQDC Essentials, das ist auf hivingcube.com zu finden und ist auch immer noch unsere beliebteste Blogserie tatsächlich, also die wird wahnsinnig viel gelesen, wird auch in Universitäten eingesetzt. Um eben das Thema MQDT auch näher zu bringen.

Mittlerweile gibt es auch seit einigen Jahren dazu Video Content, das heißt auf Youtube findet man eben auch einfach nach MQDT Essentials suchen, da gibt es dann ne zehnteilige Videoserie, die dann wirklich auf alle Details, alle Features alles abbildet und dann auch erklärt, warum sollten wir es eigentlich einsetzen, also was ist denn der Vorteil? Als Entwickler kann ich. Sehr empfehlen hab ich auch

gelesen. Ich weiß nicht ob ich jedes Video gesehen hab, aber und auch selbst für Leute die MQDT schon n bisschen benutzt haben kann man ruhig noch mal lesen. Da stecken, da stecken alle Details drin, die man wissen muss. Ja, manchmal hat man ja noch noch ne Erkenntnis. Genau und ansonsten? Wenn wenn Leute spannend finden, was wir besprochen haben.

Ich bin auch auf linkedin zu finden, mein Name ist Dominik Obermeier, also es sollte relativ einfach zu finden sein und ich freu mich über jede Verbindung und auch über alle Gespräche zum Thema, auch ja endgültige und und auch IT Architektur cool. Perfekte letzte Worte muss ich gar nichts mehr sagen. Vielen herzlichen Dank, dass du hier warst, uns diese Einblicke gegeben hast und euch weiterhin alles gute und viel Erfolg auch mit mit Hifem Q, danke dir cool,

danke euch wünsche ich dir. Auch. Dominik, vielen Dank war richtig spannend. Die Folge, danke Tschüss. Tschüss aus Hamburg. Einfach komplex wird. Präsentiert und produziert von Heiseware. Wir freuen uns auf deine Fragen und deinfeedbackanpodcast@heiseware.com vielen Dank fürs Hören dieser Folge bis Dienstag in 2 Wochen und Tschüss aus Hamburg.