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.