1 00:00:03,040 --> 00:00:07,280 Moin zufolge 78 von einfach komplex spricht Gerrit, Ich hab 2 00:00:07,280 --> 00:00:11,440 mein Kompagnon dabei, Moin. Du meinst mich ne Hallo aus 3 00:00:11,440 --> 00:00:17,120 Hamburg, Moin Gerrit. Und zum Thema MQTT heute einen 4 00:00:17,120 --> 00:00:19,840 der größten Experten hier in Deutschland, kann man das so 5 00:00:19,840 --> 00:00:22,480 sagen. Hallo Dominik von Hive MQ Moin. 6 00:00:22,800 --> 00:00:26,640 Hi, Grüße euch. Schön, dass du da bist und uns 7 00:00:26,640 --> 00:00:28,880 an deinem Wissen und deinen Erfahrungen teilhaben lässt. 8 00:00:29,440 --> 00:00:33,200 Magst du dich vorstellen und n bisschen was zu Hi FMQ sagen 9 00:00:33,200 --> 00:00:36,800 oder gerne auch n bisschen mehr, weil es ja sehr eng mal mit MQTT 10 00:00:36,800 --> 00:00:38,240 auch zusammenhängt, wenn ich es richtig sehe. 11 00:00:38,320 --> 00:00:40,880 Ja genau, genau mein Name ist Dominik Obermeier. 12 00:00:41,200 --> 00:00:46,880 Ich hab 2012 zusammen mit mit anderen Companions die Firma Hi 13 00:00:46,880 --> 00:00:49,920 MQ gegründet, hier in Deutschland mittlerweile auch 14 00:00:49,920 --> 00:00:52,320 sehr stark gewachsen, also sehr viel machen sehr viel in 15 00:00:52,320 --> 00:00:55,360 Deutschland zum Thema MQTT aber auch international. 16 00:00:55,840 --> 00:00:57,360 Mittlerweile ist auch tatsächlich so, dass wir 17 00:00:57,360 --> 00:01:00,400 ungefähr 50% der Company ist in den USA 50% ist in in 18 00:01:00,400 --> 00:01:03,600 Deutschland beziehungsweise über ganz Europa und wir machen im 19 00:01:04,319 --> 00:01:08,920 Endeffekt seit 2014 mit den ja größten Firmen der Welt und auch 20 00:01:08,920 --> 00:01:10,240 in Deutschland helfen denen m curity Infrastrukturen 21 00:01:10,240 --> 00:01:14,400 aufzubauen, von Connected Cars über Smart Infecturing. 22 00:01:14,640 --> 00:01:21,120 Mein persönlicher background ist Informatik, also ich bin 23 00:01:21,120 --> 00:01:25,520 studiert, Informatiker, hab dann im Endeffekt 2014 das Thema M 24 00:01:25,520 --> 00:01:28,480 Curity mit nach Deutschland gebracht, eben aus aus USA auch 25 00:01:28,880 --> 00:01:33,440 und bin 2014 auch im Standardisierungskomitee tätig 26 00:01:33,440 --> 00:01:37,040 und hab dann eben m curity versum 3 und versum 5 dann eben 27 00:01:37,040 --> 00:01:41,120 auch mit spezifiziert und ja du machst die letzten 10 Jahre 28 00:01:41,120 --> 00:01:44,000 nichts anderes im Endeffekt. Noch mal toll, dass du da bist. 29 00:01:44,000 --> 00:01:47,120 Und zum Start. Auch wenn wir das schon mal im 30 00:01:47,120 --> 00:01:49,600 Podcast gemacht haben. Vor ein, anderthalb Jahren gibt 31 00:01:49,600 --> 00:01:54,000 es doch mal n Überblick über MQTT oder MQTT nicht nicht auch 32 00:01:54,000 --> 00:01:55,520 noch deutsch und Englisch mischen hier an der Stelle. 33 00:01:56,000 --> 00:01:58,800 Was ist das und was macht das so besonders? 34 00:01:59,360 --> 00:02:03,760 Ja, also MQTT ist in erster Linie n Kommunikationsprotokoll. 35 00:02:03,760 --> 00:02:08,400 Das bedeutet ähnlich wie es vielleicht viele, viele Zuhörer 36 00:02:08,400 --> 00:02:12,960 Zuhörerinnen des HHTTP fürs Web auch kennen und auch täglich 37 00:02:12,960 --> 00:02:15,520 nutzen. Incuity wird benutzt für 38 00:02:15,520 --> 00:02:17,840 Maschine zu Maschine, Kommunikation, also es kommt 39 00:02:17,840 --> 00:02:22,560 tatsächlich daher 1999 also vor sehr sehr, sehr langer Zeit. 40 00:02:22,800 --> 00:02:25,760 Aus heutiger Sicht gab es ein sehr spezifisches Problem, dass 41 00:02:25,760 --> 00:02:29,280 eben Entwickler in USA, also von IBM und von der Firma Arkham, 42 00:02:29,680 --> 00:02:32,160 eher lösen mussten und zwar es ging darum, wie kann ich 43 00:02:32,320 --> 00:02:36,800 urtiblen Monitoring über Satellitenkommunikation über 44 00:02:37,040 --> 00:02:41,160 einen TCPIP Stack abbilden und ist heute immer noch so, dass es 45 00:02:41,160 --> 00:02:43,000 relativ teuer ist. Wenn ich Satellitenkommunikation 46 00:02:43,000 --> 00:02:45,040 nutze. Auch in Zeiten von Starlink, 47 00:02:45,680 --> 00:02:47,360 also früher, war es natürlich noch viel, viel teurer. 48 00:02:48,080 --> 00:02:51,280 Und Andy Stan von Clark, das ist ein guter Freund von mir, der 49 00:02:51,280 --> 00:02:54,640 eben auch das MQT Protokoll 1999 mit erfunden hat. 50 00:02:55,200 --> 00:02:58,160 Er meinte eben, dass ein einziges Byte, also wenn ich ein 51 00:02:58,160 --> 00:03:03,040 Byte mehr übertrage, kostet es pro Jahr ungefähr $10000 das 52 00:03:03,040 --> 00:03:05,560 bedeutet, wenn ich jetzt natürlich sehr, sehr, sag ich 53 00:03:05,560 --> 00:03:07,760 mal, schwergewichtige Protokolle, wie es HTTP auch 54 00:03:07,760 --> 00:03:11,360 ist, verwende um Nachrichten zu übertragen oder Daten zu 55 00:03:11,360 --> 00:03:13,440 übertragen, kostet es richtig Geld. 56 00:03:13,720 --> 00:03:16,560 Und dementsprechend war so die Aufgabenstörung die die da war, 57 00:03:16,560 --> 00:03:17,760 OK. Wie schaffe ich es denn, dass 58 00:03:18,000 --> 00:03:22,160 ich öltables, die stehen da in der Mitte von nirgendwo, also 59 00:03:22,240 --> 00:03:25,000 das ist ja, es ist also in Deutschland ist das total 60 00:03:25,000 --> 00:03:27,240 schwierig, schwierig nachzuvollziehen, was nirgendwo 61 00:03:27,240 --> 00:03:30,480 bedeutet, also ich, ich wohne in Bayern, ich wohne nirgendwo, es 62 00:03:30,480 --> 00:03:33,640 ist aber immer noch 30 Minuten zur nächsten Stadt, so, hier ist 63 00:03:33,640 --> 00:03:36,240 es so, dass tatsächlich Stunden bis zur nächsten Infrastruktur 64 00:03:36,240 --> 00:03:38,800 sind, Stunden und dementsprechend war es eben so, 65 00:03:38,800 --> 00:03:41,440 dass ausschließlich satellitenkomiker so nutzbar war 66 00:03:41,760 --> 00:03:45,120 für Öltablen Monitoring. Und Incuitive war die Lösung und 67 00:03:45,120 --> 00:03:47,280 die Idee dahinter ist sehr einfach, also für alle 68 00:03:47,280 --> 00:03:49,680 Architekten. Die meisten kennen das 69 00:03:49,760 --> 00:03:53,160 sogenannte Publish substribe Modell, es bedeutet klassisch 70 00:03:53,160 --> 00:03:56,320 Middleware, ich hab verschiedene Applikationen und ich entkopple 71 00:03:56,320 --> 00:04:00,120 die über eine Middleware und es gibt jetzt 2 Arten von von 72 00:04:00,120 --> 00:04:02,800 Middleware, es gibt sogenannte curing Systeme, das ist so 73 00:04:02,800 --> 00:04:05,200 klassische Message Cues, einige werden vielleicht so Sachen 74 00:04:05,200 --> 00:04:09,120 kennen wie Rapid MQIBMMQ und eben diese Art von von Software, 75 00:04:09,520 --> 00:04:11,200 der andere Weg ist so Publish substribe. 76 00:04:11,560 --> 00:04:14,400 Das bedeutet, ich Abonniere und die Mittelwehr ist dafür 77 00:04:14,400 --> 00:04:18,399 zuständig, dass die Daten sag mal im Push Modell ausgeliefert 78 00:04:18,399 --> 00:04:21,279 werden, an die an die sogenannten Subsdriver, also an 79 00:04:21,279 --> 00:04:23,800 die Applikationen, die sich eben für bestimmte Daten 80 00:04:23,800 --> 00:04:25,400 interessieren. Das ist eigentlich ganz schön, 81 00:04:25,400 --> 00:04:28,360 weil ich bekomm diese diese, was wir einst zu n Kommunikation 82 00:04:28,360 --> 00:04:31,120 nennen hin zum Beispiel Ich hab jetzt ein Ölpipeline mit dem 83 00:04:31,120 --> 00:04:34,680 Sensor, ich schickt jetzt mir irgendeinen Druckwert, schickt 84 00:04:34,680 --> 00:04:36,560 jetzt eben hoch in die Anführungszeichen Cloud. 85 00:04:37,280 --> 00:04:40,280 Und die Mittelwehr entscheidet nun, welche Applikationen 86 00:04:40,280 --> 00:04:42,080 interessieren sich denn für diese Datenpunkte? 87 00:04:42,400 --> 00:04:44,200 Und dann werden diese dann gepublisht. 88 00:04:44,200 --> 00:04:46,640 Das heißt, ich kann ein Datum bekommen und das kann dann an 89 00:04:46,640 --> 00:04:49,600 hunderte 10 tausende. Wir haben Kunden, die haben 90 00:04:49,680 --> 00:04:52,520 buchstäblich Millionen von Geräten, wo dann diese eine 91 00:04:52,520 --> 00:04:55,920 Nachricht dann ausgeliefert wird und ein Push Modell bedeutet, 92 00:04:55,920 --> 00:04:59,080 wie man es jetzt auch kennt vom von Android oder auch von von 93 00:04:59,080 --> 00:05:02,400 Apple von IOS, das bedeutet wirkliche Push Kommunikation und 94 00:05:02,400 --> 00:05:05,360 das ist eben dann ganz schön, weil damit schaffe ich. 95 00:05:05,600 --> 00:05:09,360 Genau diese, diese massiven Latenzverringerungen im 96 00:05:09,360 --> 00:05:11,360 Endeffekt. Ich krieg die Latenz vom 97 00:05:11,360 --> 00:05:13,920 Netzwerk eben hin und was sie damit erreicht haben ist, dass 98 00:05:13,920 --> 00:05:16,320 sie, in was sie damals aus Anführungszeichen Echtzeit 99 00:05:16,320 --> 00:05:19,680 nannten, wenn irgendwo irgendwas passiert, irgendwo in USA 100 00:05:19,680 --> 00:05:22,960 irgendein Problem mit der Ölpipeline da ist, wurden sofort 101 00:05:22,960 --> 00:05:26,640 Applikationen notified, die dann eben ganz woanders waren und das 102 00:05:26,640 --> 00:05:28,640 ganze zu möglichst maximal niedrigen Kosten. 103 00:05:28,720 --> 00:05:31,840 Ja das da kommt das MQT Protokoll her, also was ist es 104 00:05:31,840 --> 00:05:34,080 ist ein Publisher Stripe kommunikationsprotokoll. 105 00:05:34,400 --> 00:05:37,720 Das entwickelt wurde für sehr sehr leichtgewichtig. 106 00:05:37,720 --> 00:05:40,760 Es wurde entwickelt für schnelle, also niedrige 107 00:05:40,760 --> 00:05:44,080 Latenzkommunikation und ist aber auch massiv skalierbar. 108 00:05:44,720 --> 00:05:47,600 Wenn ich jetzt heute heute Blicke, wo wird MQOT eingesetzt, 109 00:05:48,080 --> 00:05:50,960 im Endeffekt für alle Connected Devices, also alles was was 110 00:05:50,960 --> 00:05:54,320 irgendwie IOT genannt wird, ist fast alles über MQOT abgebildet 111 00:05:54,320 --> 00:05:58,280 heutzutage auch für Applikations und Applikationskommunikation 112 00:05:58,280 --> 00:06:01,400 wird das sehr stark eingesetzt als Alternative zu sagen wir mal 113 00:06:01,400 --> 00:06:03,200 eher schwergewichtigen Message Brokern. 114 00:06:03,840 --> 00:06:06,240 Teilweise auch als Alternative zu Streaming Plattformen wie 115 00:06:06,240 --> 00:06:08,960 Kafka ist aber wie gesagt, da können wir vielleicht später 116 00:06:08,960 --> 00:06:10,800 einsteigen. Gibt es verschiedene Use Casses 117 00:06:10,800 --> 00:06:13,760 auch wo man das auch einsetzen würde und ansonsten auch ganz 118 00:06:13,760 --> 00:06:16,760 viel wie gesagt physische Devices so 119 00:06:16,760 --> 00:06:19,120 Applikationskommunikation, also den Fabriken und so weiter. 120 00:06:20,080 --> 00:06:22,000 Dominik, Wenn ich es richtig verstanden hab, was du gesagt 121 00:06:22,000 --> 00:06:24,080 hast. Es ist halt es hat ne kleinere 122 00:06:24,080 --> 00:06:26,880 Latenz und es ist nicht so dick und ich spare beides genau wenn 123 00:06:26,880 --> 00:06:28,320 ich es verstanden hab aus 2 Gründen. 124 00:06:28,320 --> 00:06:29,840 Ich würd es dann mal auseinander nehmen wollen. 125 00:06:30,080 --> 00:06:32,400 Weil nämlich einmal das Protokoll an sich, so es 126 00:06:32,400 --> 00:06:33,960 beschaffen ist. Und man kann sich es vielleicht 127 00:06:33,960 --> 00:06:36,360 für unsere Zuhörer vorstellen. Ich hab natürlich die Daten, die 128 00:06:36,360 --> 00:06:38,840 ich senden will, also den echten Content, den Druck, den du 129 00:06:38,840 --> 00:06:41,120 gesagt hast, von der einen Pipeline zum Beispiel, ja, ja, 130 00:06:41,360 --> 00:06:43,680 das sind dann halt, das sind dann halt n paar Bytes, sag ich 131 00:06:43,680 --> 00:06:46,240 mal, die diesen Druckwert ausgeben, und jetzt muss ich 132 00:06:46,240 --> 00:06:47,880 immer, wenn ich irgendwas verschicken will, und das käme 133 00:06:47,880 --> 00:06:50,000 mir von der Post, ja, ich brauch halt irgendwie n briefumschlag 134 00:06:50,000 --> 00:06:53,280 ja, also die der Druckwert ist quasi der Brief und dann brauch 135 00:06:53,280 --> 00:06:56,000 ich n Briefumschlag und was du gesagt hast ist der 136 00:06:56,000 --> 00:06:59,080 Briefumschlag. Der Umschlag bei MQTT ist 137 00:06:59,080 --> 00:07:00,760 besonders dünn, ja, und besonders leicht. 138 00:07:00,760 --> 00:07:02,240 Der verbraucht schon selber gar nicht viel. 139 00:07:02,240 --> 00:07:06,000 Ein paar anderen Protokollen wie dem HTTP oder was weiß ich was 140 00:07:06,000 --> 00:07:08,160 so gibt ist halt der Briefumschlag schon relativ 141 00:07:08,160 --> 00:07:10,040 dick. Ja genau und ich kann halt quasi 142 00:07:10,040 --> 00:07:12,800 meine Daten ganz schmal verpacken, sodass ich keinen 143 00:07:13,040 --> 00:07:16,080 Overhead vom Protokoll mitbekomme, der im Notfall teuer 144 00:07:16,080 --> 00:07:18,960 sein kann, wenn ich, wenn ich dann nicht die dicke Leitung vom 145 00:07:18,960 --> 00:07:22,640 Internet habe, ja und aber das zweite was du gesagt hast ist 146 00:07:22,640 --> 00:07:25,840 auch, dass das das eine quasi was es schmal und elegant macht 147 00:07:25,840 --> 00:07:28,160 und das zweite ist auch. Wenn ich es richtig verstanden 148 00:07:28,160 --> 00:07:29,920 hab, ist alleine das Kommunikationsmodell was anders 149 00:07:29,920 --> 00:07:33,760 ist, nämlich dieses Push, dieses Fire on forget, was ich ja auch 150 00:07:33,760 --> 00:07:37,760 gerne sag, irgendwie einmal eine Nachricht schicken und dann erst 151 00:07:37,760 --> 00:07:40,880 nach der Middelberg quasi an beliebig viele verteilen, ohne 152 00:07:40,880 --> 00:07:43,640 dass ich und jetzt noch mal das Gegenbeispiel im Internet müsst 153 00:07:43,640 --> 00:07:47,200 ich ja request Response machen, genau mit vielen anderen und so, 154 00:07:47,440 --> 00:07:49,440 aber vielleicht dröseln wir das noch mal für unsere Zuhörer aus. 155 00:07:49,440 --> 00:07:52,560 Vielleicht magst du, wenn du das kannst einmal sagen, wenn es 156 00:07:52,560 --> 00:07:55,000 doch so cool ist. Und warum wird denn das nicht 157 00:07:55,000 --> 00:07:57,840 fürs normale Internet genutzt? Für unsere Webservice, also für 158 00:07:58,400 --> 00:08:01,360 für für Kommunikation mit einem ganz normalen Netzwerk, gibt es 159 00:08:01,360 --> 00:08:03,360 oder gibt es da sogar auch Bestrebungen? 160 00:08:03,440 --> 00:08:04,800 Wird auch genutzt, aber das ist noch mal. 161 00:08:04,800 --> 00:08:06,960 Ist ja gut, weil wenn ich mir zum Beispiel klassische 162 00:08:06,960 --> 00:08:11,040 Webkommunikation anschaue, das ist ja HTTP, wird ja primär im 163 00:08:11,040 --> 00:08:14,080 Web auch verwendet, das Modell funktioniert so, ich hab hier 164 00:08:14,080 --> 00:08:16,720 irgendeinen Client, meistens im Webbrowser, kann aber auch ein 165 00:08:16,720 --> 00:08:20,120 Dienst sein, der zum Beispiel ein arrestful API benutzt und da 166 00:08:20,120 --> 00:08:22,080 hab ich request Respawns, das heißt der Client. 167 00:08:22,320 --> 00:08:25,920 Stellt eine Frage, geht zum Server und der antwortet dann. 168 00:08:26,480 --> 00:08:29,680 Wenn ich jetzt aber wiederholt fragen Stelle, zum Beispiel also 169 00:08:30,160 --> 00:08:32,080 es ist super gut, wenn ich zum Beispiel Wikipedia aufrufe, ich 170 00:08:32,080 --> 00:08:35,280 möchte das wissen, OK, ich möchte das wissen, ich frage 171 00:08:35,280 --> 00:08:37,440 wieder Wikipedia Server, ich bekomme eine Webseite zurück und 172 00:08:37,440 --> 00:08:40,520 habe eine Antwort und es gibt jetzt eigentlich keinen Grund, 173 00:08:40,520 --> 00:08:44,080 dass ich ständig wieder zum Server gehe, weil die die Seite 174 00:08:44,080 --> 00:08:46,720 ist ein relativ statisch der Content, wenn ich jetzt Maschine 175 00:08:46,720 --> 00:08:49,480 zu Maschine Kommunikation aber habe ändern sich ja Daten, also 176 00:08:49,920 --> 00:08:51,840 trieben wir als Beispiel Temperatursensor. 177 00:08:52,880 --> 00:08:54,880 Und ich möchte Notifiziert werden, wenn sich irgendwas 178 00:08:54,880 --> 00:08:57,560 etwas ändert, dann würde jedes mal, wenn eine Änderung 179 00:08:57,560 --> 00:09:02,160 stattfindet würde dann im Publish Subscribe Modell würde 180 00:09:02,160 --> 00:09:06,320 der sogenannte Publisher diese Daten aktiv senden und die 181 00:09:06,320 --> 00:09:10,080 Empfänger würden aktiv benachrichtigt werden vom Server 182 00:09:10,720 --> 00:09:12,920 und das ist so wie der Webentwickler, das ist ein 183 00:09:12,920 --> 00:09:14,880 bisschen so wie Server Side Events oder inner vielleicht ein 184 00:09:14,880 --> 00:09:16,640 bisschen dran oder auch webstocket Kommunikation. 185 00:09:17,200 --> 00:09:19,280 Weil das ist auch sehr häufig, dass man sagt, Ja, Moment, im 186 00:09:19,280 --> 00:09:21,400 Web kann ich das auch, ich mache ein Web Socket auf und der 187 00:09:21,400 --> 00:09:23,840 Server hat die Möglichkeit, mich zu notifizieren, als Beispiel. 188 00:09:24,320 --> 00:09:28,680 Das Spannende ist MQDT über Web Sockets funktioniert prima und 189 00:09:28,680 --> 00:09:31,600 im Endeffekt jetzt nutzen unsere Kunden auch seit 2014 bereits, 190 00:09:32,640 --> 00:09:34,880 also auch wo Web sockets noch relativ neu waren. 191 00:09:35,160 --> 00:09:38,000 Ein Beispiel wäre zum Beispiel ich habe eine Webseite und ich 192 00:09:38,000 --> 00:09:40,600 habe zum Beispiel irgendeinen Livetracker und jedes Mal, wenn 193 00:09:40,600 --> 00:09:43,320 zum Beispiel Fußballtracker und jedes Mal wenn es ein Tor 194 00:09:43,320 --> 00:09:46,400 geschossen wird dann. Würde man die Push Notification 195 00:09:46,400 --> 00:09:49,040 von Server bekommen, weil es wäre einfach viel zu 196 00:09:49,040 --> 00:09:52,400 ressourcentensiv und und viel zu teuer, auch wenn jetzt der die 197 00:09:52,400 --> 00:09:56,400 Webseite von 10 Tausenden Leuten oder 100 tausenden Leuten jede 198 00:09:56,400 --> 00:09:58,800 Sekunde beim Webserver nachfragen würde, gibt es ein 199 00:09:58,800 --> 00:10:02,240 Update, gibt es ein Update, gibt es ein Update im Endeffekt, man 200 00:10:02,240 --> 00:10:04,240 sagt einfach nur wenn es ein Update gibt lieber Server, 201 00:10:04,240 --> 00:10:08,240 benachrichtig mich und dann bekomme ich das eben zurück und 202 00:10:08,320 --> 00:10:10,480 im Endeffekt genau diesen Umschlag den du genannt hast. 203 00:10:10,520 --> 00:10:13,440 Man kann genau auch Web sockets wäre auch ein so ein Umschlag, 204 00:10:13,680 --> 00:10:15,680 das heißt man kann. Mit demselben 205 00:10:15,680 --> 00:10:17,680 Kommunikationsmodell und auch mit derselben Software, 206 00:10:17,680 --> 00:10:19,920 tatsächlich mit derselben Serversoftware kann ich 207 00:10:19,920 --> 00:10:23,680 physische Devices, Apps oder auch Mobiltelefone, aber auch 208 00:10:23,680 --> 00:10:26,200 Webseiten und andere Applikationen einfach damit 209 00:10:26,200 --> 00:10:31,280 verbinden, entweder direkt über ich sag mal raw TCPIP oder eben 210 00:10:31,280 --> 00:10:33,360 dann auch über über Web. Sock ist und tunnle ich das 211 00:10:33,360 --> 00:10:35,360 eben, dann sag ich mal eher für Applikationen. 212 00:10:36,120 --> 00:10:37,600 Hast du ne Idee ob das jetzt schon? 213 00:10:37,600 --> 00:10:39,960 Also das hört sich ja gut an und tatsächlich hört sich das sehr 214 00:10:39,960 --> 00:10:41,600 sehr gut an. Ich war auch schon überzeugt 215 00:10:41,600 --> 00:10:43,360 davon und tatsächlich passiert unsere. 216 00:10:43,840 --> 00:10:46,600 Webseite unser Frontend unser App Bilder auch genau auf dieser 217 00:10:46,600 --> 00:10:48,560 Technologie. Wir haben nämlich auch n Web 218 00:10:48,560 --> 00:10:51,720 Socket und da läuft einfach MQTT, aber Web socket, weil 219 00:10:51,720 --> 00:10:54,840 nämlich moderne Webseiten ja eben nicht mehr ganz so statisch 220 00:10:54,840 --> 00:10:58,160 sind wie Wikipedia, sondern immer mehr wir Richtung Web 221 00:10:58,160 --> 00:11:00,800 Services gehen und so weiter wir immer mehr immer mehr passiert 222 00:11:00,800 --> 00:11:03,280 auf dem Server. Ich hab immer stärker vernetzte 223 00:11:03,760 --> 00:11:07,720 Dinge wenn es die passieren und dann kann ich natürlich den 224 00:11:07,720 --> 00:11:10,000 Krieg ich diesen Echtzeit Effekt hin, ohne dass ich halt dieses 225 00:11:10,000 --> 00:11:13,280 Polling machen muss mit requestry Response und. 226 00:11:13,520 --> 00:11:15,360 Dann noch mal. Also dann ist das doch 227 00:11:15,360 --> 00:11:18,800 vielleicht sogar ja ne ganz coole Entwicklung des Internets. 228 00:11:18,800 --> 00:11:22,120 Man muss natürlich einmal dazu sagen, die Architektur sieht ja 229 00:11:22,120 --> 00:11:24,120 ganz anders aus, wenn man sich jetzt mal aufmalt, weil wir ja 230 00:11:24,120 --> 00:11:26,320 ne dritte Komponente haben, ne, das will ich noch mal betonen, 231 00:11:26,320 --> 00:11:28,600 wir haben für alle Zuhörer, wir haben ja diese Mittelwehr da 232 00:11:28,600 --> 00:11:30,960 drin, die ne echte dritte Komponente ist. 233 00:11:30,960 --> 00:11:33,320 So wie ich sehe, also wenn wir aus der alten Welt kommen, wo 234 00:11:33,320 --> 00:11:36,160 wir denken Client und Client gleich Browser und Server gleich 235 00:11:36,160 --> 00:11:37,920 irgendwie n Server in der im Internet. 236 00:11:38,520 --> 00:11:40,640 Und wir request Response haben. Dann telefonieren die 237 00:11:40,640 --> 00:11:43,120 tatsächlich direkt miteinander. Ich ruf an beim Server, der sagt 238 00:11:43,120 --> 00:11:45,720 ja hier hast du was, schickt die Antwort und dann wird wieder 239 00:11:45,720 --> 00:11:48,640 aufgelegt, ist auch die Verbindung aufgelegt ja was das 240 00:11:48,640 --> 00:11:50,560 ja auch teuer macht, weil wir jedes Mal wieder SSL, 241 00:11:50,560 --> 00:11:52,880 Verschlüsselung und so weiter aufbauen müssen. 242 00:11:52,880 --> 00:11:57,720 Ja während beim MQTT dann und ich denke da kommt eure Firma 243 00:11:57,720 --> 00:11:59,280 dann auch noch mal bis ins Spiel, vielleicht kannst du dann 244 00:11:59,280 --> 00:12:02,560 noch was dazu sagen, da brauche ich ja ne dritte Komponente, 245 00:12:02,880 --> 00:12:05,960 nämlich den nämlich den technischen Server zu dem ne 246 00:12:05,960 --> 00:12:08,160 Verbindung jetzt vom Klienten hergestellt wird. 247 00:12:08,800 --> 00:12:11,480 Der ist aber im besten Fall gar nicht, der hat nicht selbst die 248 00:12:11,480 --> 00:12:14,840 Business Logik um um die Events zu generieren. 249 00:12:14,840 --> 00:12:17,520 Typischerweise ist dann das noch mal ein drittes Backend, also 250 00:12:17,520 --> 00:12:21,320 der eigentliche Server, der wird dann aber technisch umgekehrt 251 00:12:21,320 --> 00:12:23,680 als Client, sodass dass ich quasi den Stern hab. 252 00:12:23,680 --> 00:12:25,680 Ich hab also einen dicken Server, der ist aber eigentlich 253 00:12:25,680 --> 00:12:28,120 nur da um die Nachrichten nach vorne und nach hinten zu zu 254 00:12:28,120 --> 00:12:31,200 transportieren, richtig? Ja genau, genau das ist aber 255 00:12:31,200 --> 00:12:32,480 sehr gut dargestellt tatsächlich. 256 00:12:32,960 --> 00:12:34,920 Und man muss sich natürlich fragen, ja Moment, aber warum 257 00:12:34,920 --> 00:12:36,880 sollte man das tun? Mehr Komponenten mit mehr 258 00:12:36,880 --> 00:12:40,160 Komplexität also ist nicht einfacher, besser und es stimmt 259 00:12:40,160 --> 00:12:44,240 einfach ist besser was der der Vorteil davon ist, ist eben 260 00:12:44,240 --> 00:12:47,360 tatsächlich, dass die sowohl die Sender als auch die Empfänger 261 00:12:47,360 --> 00:12:51,600 der Daten extrem trivial sind, also selbst im Vergleich zu HTTP 262 00:12:51,600 --> 00:12:55,720 diensten oder auch zu HTP Libraries und das ist zum 263 00:12:55,720 --> 00:12:58,400 Beispiel besonders wichtig und da kommt MQT auch hier, wenn ich 264 00:12:58,400 --> 00:13:00,720 jetzt besonders sag ich mal. Sag ich mal. 265 00:13:00,720 --> 00:13:02,800 Ressource eingeschränkte Geräte, hab also irgendwelche. 266 00:13:03,280 --> 00:13:05,440 Mittlerweile ist es n bisschen besser geworden, weil einfach 267 00:13:05,520 --> 00:13:07,800 Computer besser geworden ist. Aber als Beispiel früher die 268 00:13:07,800 --> 00:13:11,920 ersten Raspberry Pies, Arduino S und so weiter also die typischen 269 00:13:11,920 --> 00:13:16,800 IOT Hardware selbst HTTP ist relativ teuer, das da auch zu 270 00:13:16,800 --> 00:13:19,240 tun weil es weil es einfach n sehr komplexes Protokoll auch 271 00:13:19,240 --> 00:13:23,040 ist und auch die Schnittstellen auch die sag ich mal wenn ich 272 00:13:23,040 --> 00:13:25,520 etwas empfangen möchte, ich bau mir NHTTP Server. 273 00:13:26,520 --> 00:13:28,960 Es ist auch mit modernen Frameworks immer noch ein 274 00:13:28,960 --> 00:13:30,880 bisschen kompliziert. Es wird massiv wie 275 00:13:30,880 --> 00:13:33,320 Backupstrahiert, aber wenn ich mir jetzt, wenn ich jetzt zum 276 00:13:33,320 --> 00:13:35,360 Beispiel hergehen würde, dann würde ich sagen, ich möchte mir 277 00:13:35,360 --> 00:13:38,560 jetzt eine HTTP bibliothek bauen und ich nutze keine Frameworks, 278 00:13:38,560 --> 00:13:41,560 sondern ich starte wirklich hier, weiß nicht direkt von Safe 279 00:13:41,560 --> 00:13:45,120 from scratch, es wäre wahnsinnig aufwendig und es wäre und es 280 00:13:45,120 --> 00:13:48,520 würden wahnsinnig viele Fehler passieren und MQDT ist 281 00:13:48,520 --> 00:13:52,240 tatsächlich extrem trivial, selbst ohne Bibliothek zu 282 00:13:52,240 --> 00:13:54,440 entwickeln. Und das ist auch super wichtig, 283 00:13:54,440 --> 00:13:56,480 wenn ich zum Beispiel jetzt, wir machen viel mit Automotive 284 00:13:56,480 --> 00:13:59,680 Kunden, sehr häufig kann man eben ja diese Bibliothek und 285 00:13:59,680 --> 00:14:01,520 auch diesen Overhead sich gar nicht leisten und 286 00:14:01,520 --> 00:14:04,160 dementsprechend ist man sehr nah auch an der Hardwareentwicklung 287 00:14:04,720 --> 00:14:07,040 und da ist eben Equity sehr, sehr einfach und trivial. 288 00:14:07,200 --> 00:14:09,680 Warum? Weil alle Komplexität geht immer 289 00:14:09,680 --> 00:14:12,880 auf diese dritte Komponente, auf diesen Equity Broker, das ist ja 290 00:14:12,880 --> 00:14:15,840 der Server und die Clients sind im Endeffekt relativ 291 00:14:15,840 --> 00:14:18,880 Anführungszeichen dumm und es ist ja eigentlich im Endeffekt, 292 00:14:18,960 --> 00:14:21,280 wenn sich ein für ein Entwickler sieht das so aus, also wenn ich 293 00:14:21,280 --> 00:14:23,600 jetzt. Zum Beispiel Java oder Java 294 00:14:23,600 --> 00:14:26,480 Script Entwickler bin oder auch Rust. 295 00:14:26,480 --> 00:14:29,520 Oder kann ich irgendeine Programmiersprache nehmen im 296 00:14:29,520 --> 00:14:32,680 Endeffekt ich mach nur die Operation, Bau die Verbindung 297 00:14:32,680 --> 00:14:36,640 zum Server auf, das ist Operation 1 Operation 2 ist 298 00:14:36,640 --> 00:14:39,360 sendedaten, das ist in den meisten Programmiersprachen 299 00:14:39,360 --> 00:14:44,760 einfach nur ein Method Call oder OK, hier ist hier passieren 300 00:14:44,760 --> 00:14:47,360 Events ich subscribe mich und dann im Endeffekt bekomme ich 301 00:14:47,360 --> 00:14:50,560 Events zugespielt in der Push Manier. 302 00:14:51,040 --> 00:14:54,000 Und das war es im Endeffekt und das bedeutet auch wenn ich, wenn 303 00:14:54,000 --> 00:14:58,160 jetzt sich zuhöre, jetzt Beispiele im Internet angucken 304 00:14:58,160 --> 00:15:00,720 würden, dann will meist sagen, ja, Moment, es ist ja wirklich 305 00:15:00,720 --> 00:15:03,440 trivial, die Daten zu bekommen und zu senden. 306 00:15:03,920 --> 00:15:06,400 Der Grund dafür ist eben weil genau dieser, dieser Server alle 307 00:15:06,400 --> 00:15:09,040 Komplexität wegnimmt und dementsprechend hast du auch 308 00:15:09,040 --> 00:15:11,920 viel, sag ich mal geringere Time to market, du entwickelst die 309 00:15:11,920 --> 00:15:14,800 Apps auch viel viel schneller und obwohl HTTP heute immer 310 00:15:14,880 --> 00:15:17,480 immer tatsächlich recht leicht zu implementieren ist, weil wir 311 00:15:17,480 --> 00:15:19,440 so viel Frameworks drum rumgebaut haben. 312 00:15:19,920 --> 00:15:22,520 Ist es so, dass MQT in den meisten Fällen noch viel, viel 313 00:15:22,520 --> 00:15:23,680 leichter. Ist umzusetzen. 314 00:15:24,320 --> 00:15:27,040 Ihr habt es gerade schon anklingen lassen, Thema Broker 315 00:15:27,040 --> 00:15:30,000 Thema Client, lass uns noch mal ganz kurz in die Komponenten 316 00:15:30,000 --> 00:15:33,120 gehen, dass du dir noch mal sagst, die dazu zählen, also 317 00:15:33,120 --> 00:15:36,120 Server, das ist der Broker im MQT und die Clients und die die 318 00:15:36,120 --> 00:15:39,280 Daten konsumieren oder abonnieren. 319 00:15:39,600 --> 00:15:41,680 Genau, es gibt 2 Arten von Clients. 320 00:15:41,680 --> 00:15:43,760 Es gibt sogenannte Publisher und Subscriber. 321 00:15:44,640 --> 00:15:46,080 Ein einzelner Client kann auf beides sein. 322 00:15:46,080 --> 00:15:49,520 Tatsächlich also man kann Daten bidirektional, also so senden 323 00:15:49,520 --> 00:15:53,560 außer Empfang und die andere Komponente ist der Broker, das 324 00:15:53,560 --> 00:15:56,960 heißt ich hab tatsächlich 2 Komponenten und all diese 325 00:15:56,960 --> 00:16:02,160 Clients wie wie Burkhard erklärt hat, sind ja dann komplett 326 00:16:02,160 --> 00:16:06,200 entkoppelt, also alle kennen nur diesen Server, aber sind 327 00:16:06,200 --> 00:16:08,640 komplett entkoppelt, die wissen nichts voneinander und einer der 328 00:16:08,640 --> 00:16:10,640 Vorteile ist übrigens ja auch tatsächlich. 329 00:16:10,880 --> 00:16:14,360 Wenn ich Applikationen habe, die sich weiterentwickeln, oder ich 330 00:16:14,360 --> 00:16:17,200 habe oder ich weiß gar nicht, wie viele Sendern Empfänger ich 331 00:16:17,200 --> 00:16:19,560 habe, da kann ich das so auch entkoppeln, dass ich die 332 00:16:19,560 --> 00:16:22,240 dynamisch hinzufügen kann, auch wegnehmen kann. 333 00:16:22,280 --> 00:16:24,000 Das heißt, ich muss das vorher gar nicht wissen, wie sich das 334 00:16:24,000 --> 00:16:27,120 weiterentwickelt, sondern ich kann dann eben auch einfach 335 00:16:27,120 --> 00:16:29,920 Services, das Microservices als Beispiel einfach dazu hängen, 336 00:16:30,240 --> 00:16:33,200 ohne dass ich irgendwie auf allen Komponenten, sag ich mal, 337 00:16:33,200 --> 00:16:34,560 das noch mal irgendwie anpassen muss ich. 338 00:16:35,080 --> 00:16:36,880 Will vielleicht so ne ne Sache ergänzen. 339 00:16:37,280 --> 00:16:40,080 Jetzt, wo sie diesen obere Flugebene noch machen, was MQTT 340 00:16:40,080 --> 00:16:41,280 ist, welche Komponenten wir haben. 341 00:16:41,560 --> 00:16:44,240 Jetzt könnte sich der gewiefte Zuführer Fragen, aber wie, woher 342 00:16:44,240 --> 00:16:47,640 weiß denn dann der Subscriber, also derjenige, der an 343 00:16:47,640 --> 00:16:49,920 Nachrichten interessiert ist? Wie kriegt er die dann 344 00:16:49,920 --> 00:16:51,800 zugestellt? Ja, ich glaub den Punkten haben 345 00:16:51,800 --> 00:16:53,680 wir noch nicht besprochen, es gibt die ich glaub das ist 346 00:16:53,680 --> 00:16:56,800 einmal wenigstens kurz sagen, es gibt das Konzept der Topics, das 347 00:16:56,800 --> 00:17:01,040 ist quasi so, das ist quasi die Adresse ja dieser Levisumweg 3 348 00:17:01,040 --> 00:17:03,920 im Prinzip also der also immer wenn ein Event abgeschickt wird 349 00:17:03,920 --> 00:17:08,160 von irgendjemand der publiziert. Der muss ganz genau sagen, zu 350 00:17:08,160 --> 00:17:10,160 wem hin. Ja, und das nennt man Topic, das 351 00:17:10,160 --> 00:17:12,640 ist quasi die Event der Eventname ja vielleicht nicht 352 00:17:12,640 --> 00:17:15,040 der Name, besser so ne Art Adresse, genau tatsächlich auch 353 00:17:15,040 --> 00:17:19,359 hierarchisch aufgebaut von der Spezifikation her und die 354 00:17:19,359 --> 00:17:22,800 Subscriber, die können dann sagen alle Nachrichten dieser 355 00:17:22,800 --> 00:17:25,319 Adresse hätte ich gerne ja und und die haben sogar n bisschen 356 00:17:25,319 --> 00:17:28,640 mehr Möglichkeiten, die können sogar sagen Wildcard mäßig 357 00:17:28,640 --> 00:17:31,120 subscriben, die könnten dann sagen alles was mit so und so 358 00:17:31,120 --> 00:17:34,720 anfängt oder irgendsowas Slash Stern grob gesprochen das ist n 359 00:17:34,720 --> 00:17:37,120 bisschen anders bei einem QT. Diese ganzen Events hätte ich 360 00:17:37,120 --> 00:17:38,200 gerne. Ja und ich glaube, dann haben 361 00:17:38,200 --> 00:17:40,680 wir das Bild zusammen, weil dann haben wir dann haben wir 362 00:17:40,680 --> 00:17:42,800 diejenigen die Klienten, die die Daten tatsächlich publizieren, 363 00:17:42,800 --> 00:17:46,440 die packen da quasi in den Adress dran den Topic und dann 364 00:17:46,440 --> 00:17:49,120 haben wir den, dann geht es, wird es Hingespielt zum MQTT 365 00:17:49,120 --> 00:17:52,680 Broker und der hat jetzt die Aufgabe des Matchings, denn der 366 00:17:52,680 --> 00:17:55,160 ist der einzige, der alle kennt, tatsächlich, der kennt alle 367 00:17:55,160 --> 00:17:57,720 Publisher und alle Subscriber und der stellt jetzt 368 00:17:57,720 --> 00:18:00,000 entsprechend nach einem reinkommenden Event die Weichen, 369 00:18:00,000 --> 00:18:03,120 weiß wer muss das jetzt alles bekommen und spielt es den den 370 00:18:03,120 --> 00:18:05,640 entsprechenden Subscribern. Die sich auf dieses Topic 371 00:18:05,640 --> 00:18:07,920 subscribt haben zu ja ich glaub dann haben wir da einmal das 372 00:18:08,320 --> 00:18:11,280 technische Bild. Kompliziert würd ich sagen oder 373 00:18:11,280 --> 00:18:14,040 Dominik hab ich was vergessen. Nee, ich, ich glaube nicht, ich 374 00:18:14,040 --> 00:18:16,680 glaube nicht, das ist ist ja gut, was aber da auch ganz 375 00:18:16,680 --> 00:18:19,640 spannend ist, vielleicht zu den Topics noch als Ergänzung, die 376 00:18:19,640 --> 00:18:22,640 sind auch auch dynamisch und das ist auch sehr, sehr spannend, 377 00:18:22,640 --> 00:18:25,120 weil du damit auch sehr hohen, sehr hohen Eskalierungen 378 00:18:25,120 --> 00:18:26,960 erreichst. Also nur so ne Perspektive zu 379 00:18:26,960 --> 00:18:29,760 bringen. Man kann zum Beispiel mit MQDT 380 00:18:29,760 --> 00:18:32,320 auch sehr viel im Heimautomatisierungsbereich 381 00:18:32,320 --> 00:18:35,440 machen, hier hab ich weiß nicht vielleicht. 10 verschiedene 382 00:18:35,440 --> 00:18:37,560 amcurity clients. Vielleicht hab ich ein paar 383 00:18:37,560 --> 00:18:40,080 Applikationen, aber es ist sehr klein das Geld wenn ich jetzt 384 00:18:40,080 --> 00:18:43,360 kommerziell gehe, dann kann ich hier viel viel mehr haben, also 385 00:18:43,760 --> 00:18:45,840 die meisten High viny Kunden haben irgendwas zwischen 10 386 00:18:45,840 --> 00:18:49,600 topics und das größte Deployment das wir haben, das ist ein 387 00:18:49,600 --> 00:18:54,720 Automobilkunde, die haben mittlerweile 400000000 Topic, 388 00:18:54,720 --> 00:18:58,080 Subscriptions und topics auf einem einzelner Installationen, 389 00:18:58,160 --> 00:19:01,120 das heißt ich skaliere auch auch sehr schön damit mit mit 390 00:19:01,120 --> 00:19:04,000 derselben Installation. Und wenn ich sowas jetzt mit 391 00:19:04,000 --> 00:19:05,840 irgendwelchen anderen Technologien machen würde, das 392 00:19:06,400 --> 00:19:08,880 das wäre gar nicht möglich. Tatsächlich, einfach nur weil 393 00:19:08,880 --> 00:19:11,200 das Protokoll so effizient getrimmt ist. 394 00:19:11,200 --> 00:19:15,120 Genau genau dieses eine Problem zu lösen, dass dieses dieses 395 00:19:15,120 --> 00:19:18,760 Routing dieser Nachrichten maximal effizient zu gestalten, 396 00:19:18,760 --> 00:19:21,200 und der ist in massiv hohen Skalierungen, aber auch in 397 00:19:21,200 --> 00:19:22,960 klein. Und das hat es ja gerade so 398 00:19:22,960 --> 00:19:26,480 Rausgehört bei Booker, bei der, der der Publisher bringt sein 399 00:19:26,720 --> 00:19:29,520 Topic mit seiner Adresse, das heißt? 400 00:19:29,840 --> 00:19:32,880 Muss da vorher schon die Adresse existieren am Broker, damit das 401 00:19:32,880 --> 00:19:35,040 passieren kann, oder, oder, oder wie wie läuft das? 402 00:19:35,280 --> 00:19:37,680 Sagt der Publisher wirklich hier, da möchte ich das ganze 403 00:19:37,760 --> 00:19:40,000 senden. Das ist einer, der das ist einer 404 00:19:40,000 --> 00:19:43,240 der Sachen, die MQDT auch wirklich attraktiv machen im 405 00:19:43,240 --> 00:19:46,080 Vergleich zum so anderen Mittelwert, weil weil dieses 406 00:19:46,080 --> 00:19:49,520 dieses Publish substribe existiert ja auch in anderen 407 00:19:49,520 --> 00:19:52,320 Protokollen, das ist ja auch nichts neues, CMS zum Beispiel 408 00:19:52,320 --> 00:19:55,280 in der Java Welt ist ja auch etwas, also. 409 00:19:55,520 --> 00:19:58,240 Auch viele, zum Beispiel im im Frontend Bereich, ist auch seit 410 00:19:58,240 --> 00:20:00,280 vielen Jahren genau diese eventgetriebene Sachen. 411 00:20:00,280 --> 00:20:02,160 Also es ist auch nichts Neues für glaube ich für viele 412 00:20:02,160 --> 00:20:04,720 Entwickler. Das dynamische ist auch 413 00:20:04,720 --> 00:20:08,960 tatsächlich etwas, das m Curity abhebt von den meisten 414 00:20:08,960 --> 00:20:11,760 Kommunikationsprotokollen, weil du kannst. 415 00:20:11,760 --> 00:20:14,720 Der Publisher kann jederzeit seinen seine eigenen Topics 416 00:20:14,720 --> 00:20:18,040 mitbringen und es ist auch hierarchisch aufgebaut wie wie 417 00:20:18,040 --> 00:20:21,520 ein Filesystem muss man sich das vorstellen und und im Endeffekt 418 00:20:21,520 --> 00:20:24,080 wäre es so OK ich bin hier ein neuer neuer Publisher. 419 00:20:24,840 --> 00:20:27,000 Im Endeffekt erstellt im Fallsystem einen neuen Ordner. 420 00:20:27,000 --> 00:20:29,520 Im Endeffekt, so kann man sich das das vielleicht wirklich 421 00:20:29,520 --> 00:20:33,480 vorstellen, das ist möglich und auch dynamisch, hat natürlich 422 00:20:33,480 --> 00:20:36,560 aber auch oft ist die Frage Hey Dominik, aber das ist ja cool, 423 00:20:36,560 --> 00:20:38,800 aber was tut denn jetzt, wenn ich das gar nicht will und da 424 00:20:38,800 --> 00:20:40,880 kommt dann eben auch das rein, wo dann? 425 00:20:41,520 --> 00:20:44,040 Genau, vielen, wie wir Geld verdienen damit, damit wir eben 426 00:20:44,040 --> 00:20:46,240 genau auch, sagen wir diese Enterprise Create Security und 427 00:20:46,240 --> 00:20:49,160 so weiter drumrum anbieten, weil in kommerziellen Lösungen möchte 428 00:20:49,160 --> 00:20:51,120 man es vielleicht auch gar nicht, dass jeder einfach da 429 00:20:51,120 --> 00:20:54,400 mitbringen kann, aber für diese klassischen sag ich mal IOT Use 430 00:20:54,400 --> 00:20:56,960 cases und diese Proof of Concepts ist es massiv wichtig, 431 00:20:57,360 --> 00:20:59,360 weil du damit eben viel viel schneller die Applikation 432 00:20:59,360 --> 00:21:02,000 entwickeln kannst, weil du musst eben nicht vorher alles schon 433 00:21:02,000 --> 00:21:04,640 wissen, du musst nicht immer Spezifikationen schreiben, wie 434 00:21:04,640 --> 00:21:07,440 diese Dinge zusammen funktionieren, weil du eben das 435 00:21:07,440 --> 00:21:09,600 das das Routing einfach massiv entkoppelt, eben hast. 436 00:21:09,600 --> 00:21:12,800 Über diese dynamischen Topics. Ich würd gern noch mal auf ein 437 00:21:12,800 --> 00:21:15,440 Thema zurück, was du gesagt hast und was mir, wenn ich auch mal 438 00:21:15,440 --> 00:21:18,720 über MQTT erzähle, bei Kunden, was immer so als erste Klatsche 439 00:21:18,720 --> 00:21:21,840 kommt so AH OK kompliziertes System, wir haben noch ne 440 00:21:21,840 --> 00:21:25,840 Komponente mehr und Single Point of Failure der Arme Message 441 00:21:25,840 --> 00:21:29,120 Broker der ja. Skalieren muss mit der Anzahl 442 00:21:29,120 --> 00:21:30,720 der Publisher und der Subscriber. 443 00:21:30,720 --> 00:21:32,960 Ja, je mehr ich da hab, desto mehr hat der natürlich Arbeit 444 00:21:32,960 --> 00:21:36,000 und je mehr die publizieren und Subscriben, desto mehr Messages 445 00:21:36,000 --> 00:21:39,000 pro Sekunde fliegen ja quasi über diesen Message Broker und 446 00:21:39,000 --> 00:21:41,160 wenn der Halt platt ist, dann ist platt, ja ist vorbei mit 447 00:21:41,160 --> 00:21:44,480 meiner Kommunikation. Ja und jetzt jetzt versteh ich 448 00:21:44,480 --> 00:21:47,600 ja auch eure Firma so, dass. Dass das ja aber auch nur eine 449 00:21:47,600 --> 00:21:50,440 logische Mitte ist, das muss man ja sagen, denn jetzt kann ich 450 00:21:50,440 --> 00:21:52,360 mir vorstellen, jetzt noch mal, da ist da ein Beispiel von dem 451 00:21:52,360 --> 00:21:55,960 großen Automobilhersteller mit den, was hast du gesagt, 4000400 452 00:21:55,960 --> 00:22:01,200 topics 400000. 400000000. 400000000 OK, alles klar, völlig 453 00:22:01,200 --> 00:22:04,400 unvorstellbar, das wird ja nicht, also das ist 454 00:22:04,400 --> 00:22:07,240 wahrscheinlich, geht das logisch über den gleichen Broker, aber 455 00:22:07,240 --> 00:22:09,480 wahrscheinlich technisch nicht über den Gleiche, die gleiche 456 00:22:09,480 --> 00:22:12,360 Büchse sag ich mal über das gleiche Pizzarack was irgendwo 457 00:22:12,360 --> 00:22:14,080 im Server steht, sondern ihr werdet wahrscheinlich n ganzes 458 00:22:14,080 --> 00:22:15,960 Rechenzentrum haben, nein, vielleicht nicht ganz so groß. 459 00:22:16,160 --> 00:22:20,440 Aber schon n Paar mehrere Server, die logisch die Aufgabe 460 00:22:20,440 --> 00:22:23,280 des Message Brokers übernehmen, sich technisch aber quasi 461 00:22:23,440 --> 00:22:26,040 untereinander mit einem stark vernetzten Netzwerk austauschen 462 00:22:26,040 --> 00:22:28,160 und verteilen und so weiter und ich glaub da liegt der Hase im 463 00:22:28,160 --> 00:22:30,880 Pfeffer, auch wenn man das Enterprise gerade aufziehen 464 00:22:30,880 --> 00:22:32,720 wollt, da seid ihr wahrscheinlich die Experten, ne. 465 00:22:32,880 --> 00:22:35,320 Ja, genau das ist auch n bisschen so wie mit wie mit mit 466 00:22:35,320 --> 00:22:37,320 allen Komponenten. Also das Thema Hochverfügbarkeit 467 00:22:37,320 --> 00:22:39,680 ist ja dann n Thema, wenn ich jetzt. 468 00:22:40,400 --> 00:22:43,280 Mir das angucke wie wie macht man es denn auch Traditionelles 469 00:22:43,280 --> 00:22:45,440 in der HTTP Welt? Also da ist es oft so. 470 00:22:45,440 --> 00:22:47,840 Ich hab dann so Komponenten wie Note Balancer, ich hab dann 471 00:22:47,840 --> 00:22:51,360 vielleicht die HTTP server sind vielleicht auch in einer 472 00:22:51,360 --> 00:22:53,840 Datenbank Datenbank sind auch sehr häufig so singlepoint Fälle 473 00:22:53,840 --> 00:22:57,080 bei den meisten Applikationen aber auch hier die kann man dann 474 00:22:57,080 --> 00:23:00,080 auch Clustern und so weiter das heißt aber für Web AP 475 00:23:00,080 --> 00:23:03,680 Architekturen ist es sehr sehr gut verstanden von den meisten 476 00:23:03,680 --> 00:23:06,120 wie kann ich denn das Hochverfügbar auch gestalten mit 477 00:23:06,120 --> 00:23:09,320 den einzelnen Komponenten? Zum Beispiel HTTP Server sind 478 00:23:09,320 --> 00:23:13,000 sehr einfach zu sag ich mal zu skalieren, weil normalerweise 479 00:23:13,000 --> 00:23:15,520 haben sie sehr wenig state, weil alles state ist in der Datenbank 480 00:23:15,920 --> 00:23:18,600 oder im Frontend oder wie auch immer, aber man versucht ja oft, 481 00:23:18,600 --> 00:23:21,320 dass genau diese APIS kein State haben, sondern im Endeffekt 482 00:23:21,320 --> 00:23:24,000 einfach nur ja der der Anreichereißen dieses State sich 483 00:23:24,000 --> 00:23:26,400 irgendwo herholen, entweder von der Datenbank oder von von 484 00:23:26,400 --> 00:23:30,400 Storage und der Local Enser verteilt dann normalerweise an 485 00:23:30,400 --> 00:23:32,240 verschiedene. Also wenn ich jetzt mehr mehr 486 00:23:32,240 --> 00:23:35,800 scale brauche, neue neue Server, dazu der Local Enser verteilt zu 487 00:23:35,800 --> 00:23:37,840 den Servern. Der Lopalancer ist ja auch 488 00:23:37,840 --> 00:23:39,120 meistens ein Single Point of Failure. 489 00:23:39,120 --> 00:23:42,160 Also man kriegt die fast nicht weg, aber man man verschiebt die 490 00:23:42,160 --> 00:23:45,560 irgendwo hin und und meistens outsourced man die, also die 491 00:23:45,560 --> 00:23:48,160 wenigsten betreiben Lopalancer selber, sondern man geht dann 492 00:23:48,160 --> 00:23:51,080 eben zu einem Cloud Provider oder holt sich einen von 493 00:23:51,080 --> 00:23:53,760 Lopalancer und hofft dann im Endeffekt, dass dass das 494 00:23:53,760 --> 00:23:56,480 Ausfallsicher ist. Bei Inquity ist es ein bisschen 495 00:23:56,480 --> 00:23:58,720 anders und das ist auch genau das Problem. 496 00:23:59,320 --> 00:24:00,560 Es gibt zum Beispiel so Lösungen. 497 00:24:00,560 --> 00:24:04,640 Moskito ist er, der also fast jeder, der mit MQDT arbeitet, 498 00:24:04,640 --> 00:24:06,280 hat irgendwann mal n Moskito in der Hand gehabt. 499 00:24:06,280 --> 00:24:09,920 Es ist auch super klein, ist auf allen Linux Distributionen 500 00:24:09,920 --> 00:24:13,240 verfügbar, ist auch der mit riesen Abstand populärste MQDT 501 00:24:13,240 --> 00:24:17,360 Broker und den gibt es auch seit 2011 bereits, also der ist auch 502 00:24:17,680 --> 00:24:21,960 sehr sehr sag mal Battle testet auch das Problem ist aber 503 00:24:21,960 --> 00:24:24,880 tatsächlich, dass es wahnsinnig schwierig ist. 504 00:24:25,000 --> 00:24:27,920 Dieses MQT Server zu skalieren, also erstmal 2 Probleme nach 505 00:24:27,920 --> 00:24:30,360 oben zu skalieren und Auswahlsicher zu machen und der 506 00:24:30,360 --> 00:24:33,600 Grund dafür ist, man muss sich so vorstellen, ein MQT Broker 507 00:24:33,600 --> 00:24:37,400 ist wie eine Datenbank, es hat State und wenn es ja weg wäre, 508 00:24:37,400 --> 00:24:40,000 dann verliere ich ja alle Sachen wie alle Informationen. 509 00:24:40,000 --> 00:24:41,840 Wer hat dann eigentlich abonniert, wer hat welche Daten 510 00:24:41,840 --> 00:24:45,200 gesendet, MQT hat auch noch eine Funktionalität die es noch nicht 511 00:24:45,200 --> 00:24:47,960 besprochen haben wenn wenn ein Dienst offline ist oder ein 512 00:24:47,960 --> 00:24:50,760 Gerät offline ist. Dann dann dann habe ich ein 513 00:24:50,760 --> 00:24:53,200 sogenanntes Message Curing, das heißt, die Daten werden 514 00:24:53,200 --> 00:24:55,600 vorgehalten für diesen Client, bis er wieder online geht. 515 00:24:56,080 --> 00:24:57,520 Das heißt, ich verliere auch keine Daten. 516 00:24:58,160 --> 00:25:00,000 Das Problem ist also, wenn natürlich dieser zentrale 517 00:25:00,000 --> 00:25:02,840 Komponente kaputt geht, Stromausfall Server weg, was 518 00:25:02,840 --> 00:25:06,080 auch immer, dann ist aller Status weg und das ist auch 519 00:25:06,080 --> 00:25:09,120 glaube ich der Grund warum m Curity sehr lange nicht wirklich 520 00:25:09,120 --> 00:25:11,280 populär war, bis in die 2000 Zehner Jahre. 521 00:25:11,680 --> 00:25:13,960 Weil es einfach wahnsinnig schwierig ist zu machen. 522 00:25:13,960 --> 00:25:16,520 Und es gibt auch keine Lösungen dafür, keine guten, und wir 523 00:25:16,520 --> 00:25:18,920 waren auch tatsächlich die erste Firma, die am Markt sich 524 00:25:18,920 --> 00:25:21,320 überlegt hat, OK, wie mache ich denn das hoch verfügbar und 525 00:25:21,640 --> 00:25:24,120 jetzt macht man normalerweise was für Clustering nennen, das 526 00:25:24,120 --> 00:25:27,760 heißt, ich habe mehrere, ich sag mal physische Instanzen also 527 00:25:27,760 --> 00:25:29,840 beziehungsweise Prozesse auf verschiedene Server meistens 528 00:25:30,240 --> 00:25:34,000 oder im Idealfall und verbindet die untereinander und ähnlich 529 00:25:34,000 --> 00:25:37,200 wie bei replizierten Datenbanken tauschen die dann die Daten aus. 530 00:25:37,440 --> 00:25:39,760 Und stellen eben sicher, dass wenn jetzt ein Knoten ausfallen 531 00:25:39,760 --> 00:25:42,520 würde oder mehrere Knoten ausfallen würden, dass ich eben 532 00:25:42,520 --> 00:25:45,720 weiterhin keinen Zustand verliere und es so aussieht für 533 00:25:45,720 --> 00:25:50,200 den Client, wie wenn alles gut wäre und für die Leute, die 534 00:25:50,200 --> 00:25:52,080 jetzt technisch einsteigen wollen, gibt es aber jetzt noch 535 00:25:52,080 --> 00:25:55,920 etwas, was sehr viel schwieriger ist über HTTP, also bei HTTP, 536 00:25:55,920 --> 00:25:58,960 also mittlerweile ist es ein bisschen anders geworden, aber 537 00:25:58,960 --> 00:26:02,480 mit den alten Versionen von HTTP war es ja noch so, ich bau eine 538 00:26:02,480 --> 00:26:04,520 Verbindung auf der Service beantwortet mir und die 539 00:26:04,520 --> 00:26:07,040 Verbindung ist weg. Es bedeutet jedes Mal ein neuer 540 00:26:07,040 --> 00:26:09,040 Verbindungsaufbau und alles wieder weg. 541 00:26:09,040 --> 00:26:13,200 Endgültige hat eine hat stehende TCP Verbindungen, das bedeutet 542 00:26:13,840 --> 00:26:16,560 ich baue die Verbindung auf und die ist in Anführungszeichen 543 00:26:16,560 --> 00:26:19,000 unendlich lange offen, solange bis der Client nicht mehr offen 544 00:26:19,000 --> 00:26:21,560 haben möchte. Es ist wahnsinnig schwierig, 545 00:26:21,560 --> 00:26:24,440 dass du TCP Verbindung von einem Server zum anderen Transferierst 546 00:26:24,440 --> 00:26:27,840 ohne Verbindungsabbruch so und da da kommen dann die ganzen 547 00:26:27,840 --> 00:26:30,080 Details rein technologisch wo man sich denkt, OK. 548 00:26:30,720 --> 00:26:33,920 Es ist gar nicht so easy, weil aus kleinen Sicht möchte man es 549 00:26:33,920 --> 00:26:35,640 einfach halten. Man möchte sich nur zum Engpunkt 550 00:26:35,640 --> 00:26:38,560 verbinden und all die Komplexität wie was tue ich denn 551 00:26:38,560 --> 00:26:42,240 mit all diesen ganzen technologischen Low Level gedöns 552 00:26:42,400 --> 00:26:44,800 möchte man ja outsourcen und genau das machen wir, also wir 553 00:26:44,800 --> 00:26:47,120 haben das Problem gelöst. Wie kann ich 2 Probleme, wie 554 00:26:47,120 --> 00:26:51,120 kann ich es auf der einen Seite hoch verfügbar machen und zwar 555 00:26:51,120 --> 00:26:55,040 so, dass ich im Endeffekt Zero Downtime habe, also fast alle 556 00:26:55,040 --> 00:26:57,080 unsere Kunden haben gemeinsam, so dass ein Downtime bedeutet, 557 00:26:57,080 --> 00:27:00,560 sie verlieren richtig viel Geld. In Fabriken und auch bei Autos. 558 00:27:01,120 --> 00:27:03,000 Und dementsprechend musst du auch so Sachen hoch 559 00:27:03,000 --> 00:27:07,400 Verfügbarkeit Rolling Upgrades, das heißt, dass du Updates sag 560 00:27:07,400 --> 00:27:09,920 ich mal zur Laufzeit machst, ohne dass du sag ich mal ne 561 00:27:09,920 --> 00:27:13,000 Service decodation bekommst das eine Problem das wir gelöst 562 00:27:13,000 --> 00:27:16,720 haben und das zweite Problem ist was tue ich denn wenn ich immer 563 00:27:16,720 --> 00:27:19,760 mehr Nutzer bekomme auf der Plattform und du kannst 564 00:27:19,760 --> 00:27:22,040 natürlich immer dickere Server hinstellen, das ist ein Jahr 565 00:27:22,040 --> 00:27:26,240 aber irgendwann wird es zu teuer und dann skalierst du horizontal 566 00:27:26,800 --> 00:27:28,640 indem du eben dann mehr Server dazu machst. 567 00:27:29,200 --> 00:27:31,360 Und als Beispiel dieser eine Kunde, von dem ich, von dem ich 568 00:27:31,360 --> 00:27:34,880 gerade gesprochen habe, der kann, der hat es. 569 00:27:34,880 --> 00:27:38,080 Ich glaube, der ist auf 10 knoten oder 12 knoten. 570 00:27:38,400 --> 00:27:39,760 Das ist ja noch gar nicht zu viel. 571 00:27:39,760 --> 00:27:41,440 Das ist, wollte ich gerade sagen, das ist ja erstaunlich 572 00:27:41,440 --> 00:27:43,840 überschaubar, noch irgendwie. Ja, es ist relativ klein also 573 00:27:43,840 --> 00:27:47,480 und uns in Perspektive zu bringen im Vergleich zu normaler 574 00:27:47,480 --> 00:27:52,720 mittelwehr Kunde aus USA hat, der hatte sagen wir ein GMS 575 00:27:52,720 --> 00:27:55,320 Produkt benutzt. Also es war sagen sie nicht 576 00:27:55,320 --> 00:27:57,640 welcher Hersteller es war, aber es war ein kommerzielles GMS 577 00:27:57,640 --> 00:27:59,560 Produkt. System für alle, die gerade 578 00:27:59,560 --> 00:28:02,480 jetzt nicht wissen, was JMS ist. Es ist auch eine eine, eine eine 579 00:28:02,480 --> 00:28:06,400 Publis Subscribe exakt Architektur, Implementierung von 580 00:28:06,400 --> 00:28:09,600 Java genau also in der Java Technologie sehr bekannt sag ich 581 00:28:09,600 --> 00:28:11,600 mal ja, aber n bisschen n bisschen mit dickerem Umschlag 582 00:28:11,600 --> 00:28:13,320 sag ich mal. Ja es ist. 583 00:28:13,520 --> 00:28:17,360 Sehr gut mit dickerem Umschlag. Ja und und bei denen war sowas 584 00:28:17,360 --> 00:28:20,440 so, die hatten Probleme mit der Skalierung, weil die hatten also 585 00:28:20,440 --> 00:28:23,760 deren dein Geschäft ist gewachsen und die hatten 586 00:28:23,760 --> 00:28:25,920 tatsächlich dann immer mehr Daten. 587 00:28:26,080 --> 00:28:28,920 Die, die drüber gelaufen sind und irgendwann kamen, kamen die 588 00:28:28,920 --> 00:28:31,520 Software an. Skalierungsgrenzen hatte dann zu 589 00:28:31,520 --> 00:28:34,280 zu Downtime geführt, hatte dann zu Kundenunzufriedenheit 590 00:28:34,280 --> 00:28:37,520 geführt, weil eben dann dann sag ich mal, in dem konkreten Fall 591 00:28:37,520 --> 00:28:39,240 Pakete nicht mehr ausliefern, also echte Pakete. 592 00:28:39,240 --> 00:28:42,960 Es war waren waren Logistikunternehmen und 593 00:28:43,120 --> 00:28:45,680 dementsprechend haben sie nach einer Lösung gesucht und haben 594 00:28:45,680 --> 00:28:49,800 dann eben erstmal entdeckt, haben wir mit uns gesprochen und 595 00:28:49,800 --> 00:28:53,600 wir haben im Endeffekt einfach nur diesen Use Case ersetzt ohne 596 00:28:53,600 --> 00:28:56,360 irgendwelche. Zusatzfeatures von Equity, die 597 00:28:56,360 --> 00:29:00,560 sie haben einfach ersetzt und sie haben 8 mal Server gespart. 598 00:29:00,880 --> 00:29:05,280 Also das heißt sie konnten um sie konnten um das Achtfache, 599 00:29:05,280 --> 00:29:08,760 die die Ressourcen reduzieren, einfach nur durch ein 600 00:29:08,760 --> 00:29:10,600 Replacement, durch eine effizientere Software. 601 00:29:11,680 --> 00:29:12,680 Und das Schöne ist, sie können es. 602 00:29:12,680 --> 00:29:16,320 Auch immer weiter skalieren. Weil also in unserem konkreten 603 00:29:16,320 --> 00:29:21,000 Fall, also wir supporten bis zu 100000000 Geräte mit mit 604 00:29:21,000 --> 00:29:23,360 demselben Cluster verbunden, es ist. 605 00:29:23,760 --> 00:29:26,320 Viel, viel mehr als die meisten unserer Kunden jemals erreichen 606 00:29:26,320 --> 00:29:28,560 werden. Und und das heißt, du kannst von 607 00:29:28,560 --> 00:29:31,200 einem Gerät bis zu 100000000, kannst du elastisch 608 00:29:31,200 --> 00:29:35,280 hochskalieren, je nachdem wie B sub benötigt wird, könnte dir 609 00:29:35,280 --> 00:29:37,840 noch mal ganz. Kurz n bisschen aufklären was 610 00:29:37,840 --> 00:29:41,640 Knoten sind und unter was unter dem Cluster zu verstehen ist. 611 00:29:41,640 --> 00:29:43,280 Also ein Cluster sind ja auch schon mehrere Server 612 00:29:43,280 --> 00:29:45,280 gegebenenfalls oder genau Cluster ist. 613 00:29:45,280 --> 00:29:47,360 Mehrere Server weil normalerweise ist es ja so, man 614 00:29:47,360 --> 00:29:51,280 möchte sag ich mal eine Installation auf einem Server, 615 00:29:51,280 --> 00:29:52,480 zum Beispiel irgendwo in der Cloud. 616 00:29:53,280 --> 00:29:55,600 Auf auf einer virtuellen Maschine zum Beispiel oder auch 617 00:29:55,800 --> 00:29:58,840 auf Cubanitas. Es wäre dann ein Knoten, das 618 00:29:58,840 --> 00:30:01,320 wäre ein Endpunkt und mit mit einem Cluster, was du eben 619 00:30:01,320 --> 00:30:05,400 machst, ist du fügst mehrere, ich sag mal, physische meistens 620 00:30:05,400 --> 00:30:08,880 habe dazu und auch wirklich softwareinstitutionen dazu und 621 00:30:08,880 --> 00:30:12,040 die Formen ein logisches, was wir Cluster nennen und der 622 00:30:12,040 --> 00:30:14,720 Effekt ist dann, dass wenn ich jetzt wenn wenn der Client, also 623 00:30:14,720 --> 00:30:17,840 zum Beispiel jetzt ein Auto sich verbinden würde. 624 00:30:18,240 --> 00:30:21,160 Zu einem dieser Knoten zu zum Beispiel wenn ich 3 Knoten und 625 00:30:21,160 --> 00:30:24,120 zu einem dieser 3 Knoten sieht es so aus, wie wenn es dasselbe 626 00:30:24,120 --> 00:30:26,880 Server wäre. Und auch wenn der Server weg 627 00:30:26,880 --> 00:30:29,680 wäre und der neue kommen würde, ist es dem Kleinen vollkommen 628 00:30:29,680 --> 00:30:30,600 egal. Der muss sich nicht drum 629 00:30:30,600 --> 00:30:32,800 kümmern, wie die Infrastruktur aussieht, der kennt einfach nur 630 00:30:32,800 --> 00:30:37,680 das ist mein Endpunkt. Ja und und der Server kümmert 631 00:30:37,680 --> 00:30:40,160 sich dann darum, dass das im Endeffekt das einfach möglichst 632 00:30:40,160 --> 00:30:42,800 einfach ist. Ist n schwieriges Problem 633 00:30:42,800 --> 00:30:44,960 tatsächlich, das hat ich glaube, es hat ungefähr 7 Jahre 634 00:30:44,960 --> 00:30:47,000 gedauert, bis wir das richtig hatten, also. 635 00:30:47,920 --> 00:30:52,000 Aber aber wie ist es es so, dass eben genau das so wird? 636 00:30:52,000 --> 00:30:54,240 Encurity eingesetzt bei den meisten Forschung verfahrenen 637 00:30:54,240 --> 00:30:56,560 Unternehmen Dominik, Jetzt stell ich dir. 638 00:30:56,560 --> 00:30:58,880 Gerade noch mal aus privaten Interesse ne ne ne ganz tiefe 639 00:30:58,880 --> 00:31:01,720 frage, mal gucken ob die zuhört, damit das auch aber also ich hab 640 00:31:01,720 --> 00:31:03,760 mich natürlich auch schon mal mit diesem Problem befasst, weil 641 00:31:03,760 --> 00:31:06,640 wir auch ganz viel MQTT einsetzen, das ist bei uns ja 642 00:31:06,640 --> 00:31:09,480 das backbound Protokoll für unsere gesamte Software 643 00:31:09,480 --> 00:31:12,400 Anwendung, ihr schafft es dann wahrscheinlich auch und du 644 00:31:12,400 --> 00:31:14,720 hattest gesagt das ist schwierig und genau das ist der springende 645 00:31:14,720 --> 00:31:18,560 Punkt, dass der Klient. Immer den gleichen und jetzt? 646 00:31:18,560 --> 00:31:20,400 Jetzt gehen wir mal richtig aufs Brett, also im Prinzip die 647 00:31:20,400 --> 00:31:24,160 gleiche IP Adresse, sieht das Socket das Listener Socket vom 648 00:31:24,160 --> 00:31:31,280 MQTT Broker bleibt stabil für jeden Client, obwohl tatsächlich 649 00:31:31,280 --> 00:31:34,960 der der logische MQTT Broker mit aus mehreren Knoten, also aus 650 00:31:34,960 --> 00:31:38,240 mehreren Servern besteht. Ja das kriegt ihr quasi auch hin 651 00:31:38,240 --> 00:31:40,520 oder müssen. Wenn ich jetzt also sag, also 652 00:31:40,520 --> 00:31:42,480 ich mach es noch mal ganz plastisch, wir haben im im 653 00:31:42,480 --> 00:31:45,200 einfachsten Falle haben wir, sagen wir mal einen Computer, 654 00:31:45,200 --> 00:31:47,640 der ist der Client, der publiziert, und dann haben wir 655 00:31:47,640 --> 00:31:50,120 noch n anderen Computer, das der ist auch der Client, der 656 00:31:50,120 --> 00:31:53,040 konsumiert, ja, und dann haben wir irgendwo anders 657 00:31:53,840 --> 00:31:57,920 netzwerkmäßig, aber erreichbar natürlich einen Server, der ist 658 00:31:57,920 --> 00:32:01,200 der Message Broker, der verbindet die beiden ja, beide 659 00:32:01,200 --> 00:32:04,840 wählen sich hinzu dem Stern in der Mitte und haben ne STEHENDE 660 00:32:04,840 --> 00:32:07,480 DCP Verbindung so. Und jetzt sagst du, jetzt müssen 661 00:32:07,480 --> 00:32:09,080 wir skalieren. Das ist n schwieriges Problem 662 00:32:09,080 --> 00:32:11,240 aus den genannten Gründen die du hast, wiederhole ich nicht so 663 00:32:11,240 --> 00:32:13,280 und jetzt ist es ja aber wichtig, das weiß jeder der 664 00:32:13,280 --> 00:32:16,400 schon einmal im QTT gemacht hat, dass ich natürlich sage, als 665 00:32:16,400 --> 00:32:19,840 Klient oder als Konsument, was beides technisch die Klienten 666 00:32:19,840 --> 00:32:22,720 sind, wer ist denn mein Server, an wen will ich mich verbinden, 667 00:32:22,720 --> 00:32:24,880 also ich muss da ne Domain eingeben oder ne IP Adresse mit 668 00:32:24,880 --> 00:32:29,160 dem Port ja TCP ja ganz klassisch so so und jetzt ist es 669 00:32:29,160 --> 00:32:31,040 so, dieser Server ist jetzt platt weil er kann nicht mehr 670 00:32:31,040 --> 00:32:32,880 der hat der ist an seiner Grenze und jetzt stellst du den 671 00:32:32,880 --> 00:32:35,520 nächsten da rein ja. Dann brauche ich ja eigentlich, 672 00:32:35,520 --> 00:32:37,800 wenn wenn ich das jetzt so ganz transparent machen will für die 673 00:32:37,800 --> 00:32:42,320 Clients auch so ne Art Load Balance Server, der ne stehende 674 00:32:42,320 --> 00:32:46,720 TCP Verbindung Load Balance ohne dass die Clients das merken. 675 00:32:46,720 --> 00:32:50,240 Das kriegt ihr hin oder müssen die Clients dann schon mehrere 676 00:32:50,240 --> 00:32:53,600 eingangs also haben die quasi verschiedene Eingangsserver, 677 00:32:53,600 --> 00:32:55,400 dass die sich untereinander verteilen, das verstehe ich, das 678 00:32:55,400 --> 00:32:58,000 ist ja noch relativ einfach wahrscheinlich, aber wie schaffe 679 00:32:58,000 --> 00:32:59,760 ich es, dass die Clients davon nichts merken? 680 00:33:00,000 --> 00:33:02,080 Also was du, was du. Normalerweise machst also 681 00:33:02,080 --> 00:33:06,680 eigentlich über HTTP übrigens fast nie benutzt man statische 682 00:33:06,680 --> 00:33:10,360 IP Adressen, das ist eigentlich so n antipattern und selbst wenn 683 00:33:10,360 --> 00:33:13,000 man die benutzt, nutzt man normalerweise elastische IP 684 00:33:13,000 --> 00:33:15,480 Adressen, was ja eigentlich auch nur sag ich mal so ne Art 685 00:33:15,480 --> 00:33:18,120 nobalancer ist. Also APS zum Beispiel bietet 686 00:33:18,120 --> 00:33:21,440 sowas auch an, das heißt normalerweise hast du hier 687 00:33:21,840 --> 00:33:25,360 nobalancer davor, das ist normalerweise und du kannst es 688 00:33:25,360 --> 00:33:28,600 entweder über DNS machen, also DNS lobalancing, das heißt du 689 00:33:28,600 --> 00:33:32,320 hast dann hier. My computer.com und da ist eben 690 00:33:32,320 --> 00:33:36,000 dann hinterlegt, dass wenn eben jemand den DNS Request von den 691 00:33:36,000 --> 00:33:39,720 DNS überstellt, dann wird einer dieser zum Beispiel 3 IP 692 00:33:39,720 --> 00:33:43,520 Adressen zurückgegeben. Und wenn ich jetzt aber noch mal 693 00:33:43,680 --> 00:33:46,480 fragen würde mich noch mal neu verbinde, würde wieder 1 dieser 694 00:33:46,480 --> 00:33:48,880 Adressen zurückgegeben werden, das heißt die echte IP Adresse 695 00:33:49,600 --> 00:33:51,720 ist ganz selten, dass man die wirklich statisch einbaut, das 696 00:33:51,720 --> 00:33:53,600 ist eigentlich ein Antipad dann also bei den meisten 697 00:33:53,720 --> 00:33:57,520 Applikationen, was aber der springende Punkt ist. 698 00:33:58,560 --> 00:34:02,640 Wenn ich zum Beispiel, das ist auch bei vielen HTTP load 699 00:34:02,640 --> 00:34:06,520 balancers wenn ich jetzt mal von endgültig HTP gehe, was gern 700 00:34:06,520 --> 00:34:09,120 gemacht wird, ist, dass ich sogenannte Sticky Sessions habe, 701 00:34:10,159 --> 00:34:13,000 und das bedeutet, wenn ich jetzt eine eine Webanwendung habe und 702 00:34:13,000 --> 00:34:15,639 ich hab zum Beispiel zum Beispiel Session Cookie, wäre es 703 00:34:15,639 --> 00:34:19,239 eine Möglichkeit, dann möchte ich ja im Normalfall, dass per 704 00:34:19,239 --> 00:34:24,000 HTTP immer derselbe Client immer zum selben Server geht, ja. 705 00:34:24,880 --> 00:34:26,159 Das Problem? Ist Sticky Sessions am 706 00:34:26,159 --> 00:34:28,239 Localancer sind relativ teuer und es ist schwierig zu 707 00:34:28,239 --> 00:34:30,719 skelieren, weil der Localancer an seine Grenzen kommt, weil der 708 00:34:30,719 --> 00:34:34,480 dann auf einmal stateful ist. Und bei MQDT ist eigentlich das 709 00:34:34,480 --> 00:34:37,639 Pad dann du hast n State Less localancer und der Localancer 710 00:34:37,639 --> 00:34:39,360 verteilt wie er es gerade lustig findet. 711 00:34:39,679 --> 00:34:42,800 Entweder Now welcher Server hat am nächsten Ressourcen round 712 00:34:42,800 --> 00:34:46,560 Robin oder irgendwelche super sag mal ausgeklügelten 713 00:34:46,960 --> 00:34:50,239 Mechanismen, aber wichtig ist, dass du eben nicht stateful bist 714 00:34:50,639 --> 00:34:53,239 und das unterstützen wir, weil der der Trick, den wir haben, 715 00:34:53,239 --> 00:34:55,440 ist, und das ist auch das, was es schwierig macht, ist, dass 716 00:34:55,440 --> 00:34:57,920 wenn der Client sich neu verbindet, dass der woanders 717 00:34:57,920 --> 00:35:01,120 hingeht. So wenn du jetzt aber ja auf 718 00:35:01,120 --> 00:35:03,440 deine Frage zurück, wenn ich jetzt aber den Fall hab, dass 719 00:35:03,440 --> 00:35:06,480 zum Beispiel der Server weggeht, also wegbricht, was passiert 720 00:35:06,480 --> 00:35:08,960 jetzt dann mit den TCP Verbindungen, also einfach wie 721 00:35:08,960 --> 00:35:11,520 TCPIP funktioniert? Du siehst einen 722 00:35:11,520 --> 00:35:14,320 Verbindungsabbruch, das ist unvermeidlich, also es gibt 723 00:35:14,320 --> 00:35:17,360 Wege, es gibt Wege, aber das musst du auf der curren Ebene 724 00:35:17,360 --> 00:35:19,360 machen, es geht nicht auf, der geht nicht auf der 725 00:35:19,360 --> 00:35:22,960 Applikationsebene. Und was passiert in der Praxis? 726 00:35:23,040 --> 00:35:27,400 Du siehst eine TCP Disconnection und der Client wird sich sofort 727 00:35:27,400 --> 00:35:31,120 wieder verbinden und wird dann zu einem dieses Server geroutet 728 00:35:31,120 --> 00:35:34,000 werden und kann so weitermachen auf einem Server wie wenn nichts 729 00:35:34,000 --> 00:35:36,800 passiert wäre und das NQIT Protokoll beziehungsweise der 730 00:35:36,800 --> 00:35:40,160 Server QT auch Nachrichten das heißt es sieht eigentlich aus 731 00:35:40,160 --> 00:35:43,200 Clientsicht aus wie einfach nur bisschen mehr Latenz und eben 732 00:35:43,200 --> 00:35:46,880 diese eine Reconnection ja. Cool, ich muss auch sagen, mein 733 00:35:46,880 --> 00:35:50,480 Eindruck ist ja auch, dass MQTT. Und wir, wir machen es ja auch. 734 00:35:50,480 --> 00:35:53,040 Battle Testing, also wir benutzen es auch für Frontend, 735 00:35:53,040 --> 00:35:55,440 Backend, Kommunikation und dann für Backend, Backend, 736 00:35:55,440 --> 00:35:58,080 weiterkommunikation und so weiter das ist kann ich jetzt ja 737 00:35:58,080 --> 00:35:59,600 auch mal so sagen, für jeden der Mal starten will, das 738 00:35:59,600 --> 00:36:02,400 funktioniert einfach unglaublich gut, das ist unglaublich schnell 739 00:36:02,400 --> 00:36:05,440 skaliert, also ist einfach n tolles Protokoll. 740 00:36:05,440 --> 00:36:08,440 Ja jetzt machen wir ganz ganz tief in der Technik, ich guck 741 00:36:08,440 --> 00:36:10,240 gleich auch gerade noch mal in die Augen, der hat vielleicht 742 00:36:10,240 --> 00:36:13,200 noch n paar andere Fragen, aber jetzt noch mal ne ganz ganz 743 00:36:13,200 --> 00:36:15,680 aktuelle Frage auch zu eurer Firma so das heißt. 744 00:36:16,240 --> 00:36:18,840 Im Auto wenn ich jetzt n modernen BMW kaufe, sag ich mal 745 00:36:18,840 --> 00:36:21,360 ich weiß jetzt nicht du hast keine, es kann ja auch Mercedes 746 00:36:21,360 --> 00:36:23,920 sein oder irgendsowas also mir n modernes Auto kaufe sag ich mal 747 00:36:23,920 --> 00:36:28,280 ja dann sind da tatsächlich MQTT Clients drin oder wenigstens 748 00:36:28,280 --> 00:36:31,800 einer oder irgendsowas und. Und die fahren alle so. 749 00:36:31,800 --> 00:36:37,840 Durch die Gegend und und benutzen MQTT als Protokoll, nur 750 00:36:37,840 --> 00:36:40,240 um irgendwie mediamäßig mal so Hallo zu sagen. 751 00:36:40,240 --> 00:36:42,200 Oder ist das sogar schon auch tiefer integriert, dass ich 752 00:36:42,200 --> 00:36:44,960 irgendwelche. Was weiß ich irgendwelche 753 00:36:44,960 --> 00:36:46,960 fahrsicherheitssachen damit abdecke oder irgend so? 754 00:36:46,960 --> 00:36:48,760 Wie kannst du uns haben wenn du willst? 755 00:36:48,760 --> 00:36:51,520 Nur mal kurz was sagen wie wie krass ist das eingesetzt? 756 00:36:51,840 --> 00:36:54,160 Ich kann über einen. Kunden reden über die meisten 757 00:36:54,160 --> 00:36:57,960 Kunden in dem Bereich kann ich leider nicht reden, aber ich 758 00:36:57,960 --> 00:37:02,720 kenne nur einen einzigen Autohersteller, von dem ich, von 759 00:37:02,720 --> 00:37:06,760 dem ich es nicht sicher weiß, hundertprozentig sicher, dass er 760 00:37:06,760 --> 00:37:08,920 nicht incurity benutzt und auch hier bin ich mal fast sicher, 761 00:37:08,920 --> 00:37:10,800 dass ich es benutzt von den meisten Autoherstellern, die ich 762 00:37:10,800 --> 00:37:16,320 kenne, die ich namentlich kenne. Wir nutzen MQT und zwar für sehr 763 00:37:16,320 --> 00:37:19,800 viele Sachen, also im Endeffekt für alle Kommunikation zum Auto, 764 00:37:19,800 --> 00:37:22,400 also fast alle. Du hast immer noch ein bisschen 765 00:37:22,400 --> 00:37:24,320 so Sachen wie Firmware, Updates und so weiter würdest du 766 00:37:24,320 --> 00:37:27,520 normalerweise ungern machen über MQT, weil MQT ist funktioniert 767 00:37:27,520 --> 00:37:32,000 am besten für für kleine sag ich mal Daten, also auf jeden Fall 768 00:37:32,000 --> 00:37:35,840 unter 250 Megabyte, wenn das eine Firmware sehr oft größer 769 00:37:35,840 --> 00:37:39,120 sind heutzutage. Aber ansonsten ist endgültig 770 00:37:39,120 --> 00:37:44,240 hier so gut wie überall verbaut, in Produktion seit weit über 5 771 00:37:44,240 --> 00:37:47,120 Jahren und ein Kunde von dem ich reden kann, das ist kein 772 00:37:47,120 --> 00:37:49,600 deutscher Kunde. Wir arbeiten mit fast allen 773 00:37:49,600 --> 00:37:50,760 Deutschen und Automobilherstellern in 774 00:37:50,760 --> 00:37:53,040 verschiedenen Bereichen zusammen, aber ein Kunde wo ich 775 00:37:53,040 --> 00:37:56,240 drüber reden kann ist eine Firma, die heißt Autonomic, die 776 00:37:56,240 --> 00:37:59,240 wurde von Ford gekauft, das ist eine connect Car Plattform und 777 00:37:59,240 --> 00:38:00,800 dann wäre eben auch eine Case Study online. 778 00:38:00,800 --> 00:38:04,560 Wer sich das im Detail angucken möchte und. 779 00:38:04,800 --> 00:38:07,880 Die Nutzen tatsächlich auch am Curity und es ist auch sehr ist 780 00:38:07,880 --> 00:38:10,360 auch beschrieben in der Case Study für was genau. 781 00:38:10,360 --> 00:38:14,320 Also das heißt, wenn alles was vom Auto rausgeht und ins Auto 782 00:38:14,320 --> 00:38:17,600 reingeht ist es weitestgehend am Curity und kannst du. 783 00:38:17,600 --> 00:38:19,520 Auch was sagen hier? Es gibt ja, es gibt ja so tolle 784 00:38:19,520 --> 00:38:22,040 Sachen, so auch hier, wenn ich jetzt mir n Auto ausleihe oder n 785 00:38:22,040 --> 00:38:24,160 Fahrrad ausleihe hier in Hamburg gibt es das ja, ist das ja ganz 786 00:38:24,160 --> 00:38:27,040 Standard ja ich ich ich hab halt 40 Apps oder für die 787 00:38:27,040 --> 00:38:29,200 Elektroroller oder irgendwas ja und den den. 788 00:38:29,680 --> 00:38:32,720 Dann mach ich das Ding auf und dann kann ich das live realtime 789 00:38:32,800 --> 00:38:35,280 ja entsperren und so. Ich kann das Auto aufschließen 790 00:38:35,280 --> 00:38:37,840 zu ich kann es fast hupen lassen und so weiter ja ja ist das 791 00:38:37,840 --> 00:38:40,480 weißt du das ist das auch MQTT Technologie dahinter oder ist 792 00:38:40,480 --> 00:38:41,680 das was anderes? Wird das da auch schon 793 00:38:41,680 --> 00:38:43,560 eingesetzt? Ja ja hast. 794 00:38:43,560 --> 00:38:44,880 Du auch diese Produkte, die ich kenne. 795 00:38:45,440 --> 00:38:48,720 Es gibt ein Produkt, das war ist eine unserer ersten Case 796 00:38:48,720 --> 00:38:51,560 Studies, die haben wir 2014 und da haben wir auch ne Case study 797 00:38:51,560 --> 00:38:54,720 online, das ist eben mit BMW Carsharing, das heißt das hieß 798 00:38:54,720 --> 00:38:56,880 früher Drive Now das im Endeffekt ist es. 799 00:38:57,160 --> 00:38:59,120 Produkt, wo du mit einer App n Auto mieten kannst und 800 00:38:59,120 --> 00:39:02,160 aufsperren kannst und so weiter dann in der Case Study, die eben 801 00:39:02,160 --> 00:39:05,280 auch das beschreibt, eben wie m für die T die Benutzerexperience 802 00:39:05,280 --> 00:39:09,680 von teilweise über 30 Sekunden von der Zeit zum ich. 803 00:39:09,920 --> 00:39:12,680 Ich möchte, dass das Auto sich aufsperrt über meine App bis er 804 00:39:12,680 --> 00:39:14,960 sich richtig aufsperrt hat er nicht HTTP unter Haube vorher 805 00:39:15,120 --> 00:39:18,480 und wir haben denen dann geholfen 2014 schon oder 15 um 806 00:39:18,480 --> 00:39:22,080 den Dreh also vor 10 Jahren haben wir denen dann geholfen, 807 00:39:22,360 --> 00:39:24,360 dass sie das dann im Durchschnitt auf unter eine 808 00:39:24,360 --> 00:39:27,760 Sekunde reduzieren konnten. Was natürlich die 809 00:39:27,760 --> 00:39:30,160 Benutzerfreundlichkeit deutlich erhöht hat, weil wenn ich jetzt 810 00:39:30,160 --> 00:39:33,640 nämlich, ich muss da vorstellen, jetzt gerade einkaufen und ich 811 00:39:33,640 --> 00:39:35,200 gehe nicht gerne einkaufen, aber wenn ich einkaufen gehe, dann 812 00:39:35,200 --> 00:39:37,160 reden wir jetzt meistens, wenn ich zum Auto gehe und wenn du 813 00:39:37,160 --> 00:39:39,400 jetzt da vom vom Auto stehst und dann willst du dir noch mit der 814 00:39:39,400 --> 00:39:43,040 App jetzt irgendwie aufsperren und dann wartest du 30 Sekunden, 815 00:39:43,040 --> 00:39:46,400 bis das Ding mal was tut, dann ist es nicht gut für die App 816 00:39:46,400 --> 00:39:49,040 Store Bewertungen und wir konnten denen dann helfen, eben 817 00:39:49,040 --> 00:39:52,200 auch die Benutzer Experience zu verbessern, das war unser unser 818 00:39:52,200 --> 00:39:55,920 erster Automobil uscase. Seitdem haben wir aber deutlich, 819 00:39:55,920 --> 00:39:58,800 sag ich mal deutlich missionskritischere Use Cases 820 00:39:58,800 --> 00:40:00,320 bei fast allen Automobilherstellern. 821 00:40:00,800 --> 00:40:02,320 Wir hatten es neulich, weil wir sind zu einem. 822 00:40:02,320 --> 00:40:05,200 Kundentermin mit einem gemieteten Auto mit der App 823 00:40:05,200 --> 00:40:07,440 gemieteten Auto gefahren, wo gerade gesagt ich glaub das 824 00:40:07,440 --> 00:40:10,800 MQTT, da hast du nur n Problem. Wenn du und das MQTT hilft dir 825 00:40:10,800 --> 00:40:12,960 dann auch nicht, wenn du in der wie wir in der Tiefgarage 826 00:40:12,960 --> 00:40:15,120 standen und einfach das Beton, irgendwie das Internet 827 00:40:15,120 --> 00:40:17,360 verklatscht sondern und dann wartest du trotzdem auf dein 828 00:40:17,360 --> 00:40:19,640 Zuschließsignal. Das kommt dann trotzdem nicht 829 00:40:19,640 --> 00:40:21,640 an. Ich kann es lösen, indem wir zum 830 00:40:21,640 --> 00:40:23,720 Eingang gelaufen sind, sonst hätten wir noch n Hotspot 831 00:40:23,720 --> 00:40:25,440 gemacht und das Gebrückt oder irgendwas. 832 00:40:25,520 --> 00:40:27,680 Ja OK Automotive. Ist das eine? 833 00:40:27,680 --> 00:40:29,400 Du hast auch schon mal Manufacturing fallen lassen und 834 00:40:29,400 --> 00:40:31,360 das interessiert glaub ich auch immer viele unserer Zuhörer und 835 00:40:31,360 --> 00:40:33,400 auch uns persönlich, weil da machen wir auch viel mit der 836 00:40:33,400 --> 00:40:36,600 Heisenware, da gibt es dann eben auch n Broker, zum Beispiel 837 00:40:36,600 --> 00:40:40,080 NHFMQ Broker oder n anderen. Wie ist da die Architektur? 838 00:40:40,080 --> 00:40:44,000 Typischerweise ist das denn in der Fabrik der Server um im 839 00:40:44,000 --> 00:40:46,120 kleinen Serverbild zu bleiben oder ist es eigentlich schon in 840 00:40:46,120 --> 00:40:47,960 der Cloud? Ja, also da. 841 00:40:47,960 --> 00:40:49,680 Ist es so, dass du oft so Hybrid bist? 842 00:40:50,480 --> 00:40:54,080 Es kommt auch ein bisschen drauf an, aber ich sag mal in weit 843 00:40:54,080 --> 00:40:58,080 über 9 von 10 Fällen hast du den Fall, dass dass du nicht zu 844 00:40:58,080 --> 00:41:00,680 produzieren aufhören möchtest. Wenn die Cloud Verbindung gerade 845 00:41:00,680 --> 00:41:03,680 nicht da ist, weil es kann immer was passieren. 846 00:41:04,000 --> 00:41:08,080 Teilweise ist es dein dein Telekommunikationsprovider macht 847 00:41:08,080 --> 00:41:12,560 Probleme, es hat auch schon Fälle gegeben wo auch ABS zum 848 00:41:12,560 --> 00:41:15,360 Beispiel einfach mal komplett komplette Downham hat und wir 849 00:41:15,360 --> 00:41:17,400 machen Diensten und so weiter oder oder Azure. 850 00:41:17,760 --> 00:41:20,840 Also, und normalerweise gehen Produktionsunternehmen nicht in 851 00:41:20,840 --> 00:41:24,160 das Risiko, dass sie aufhören zu produzieren, bloß halt mal 852 00:41:24,160 --> 00:41:25,760 irgendwas langsames übers Internet. 853 00:41:26,320 --> 00:41:29,400 Das heißt in diesen Fällen, wo du es nicht möchtest, stellst du 854 00:41:29,400 --> 00:41:34,640 normalerweise eine Equity Infrastruktur in jede Fabrik und 855 00:41:34,640 --> 00:41:38,560 meistens dann in eine Cloud, das heißt du hast so dieses einen 856 00:41:38,560 --> 00:41:41,200 Server in der Cloud und dann in jeder Fabrik mindestens einen 857 00:41:41,200 --> 00:41:43,880 Equity Broker. Und das heißt, alle 858 00:41:43,880 --> 00:41:46,560 Applikationen, und das sind dann auch oft so irgendwelche Assets, 859 00:41:46,560 --> 00:41:49,840 die dann über zum Beispiel irgendwelche Gateways, also wie 860 00:41:49,840 --> 00:41:51,720 zum Beispiel auch so n Gateway, das sich genau auch mit diesen 861 00:41:51,720 --> 00:41:55,720 industriellen Protokollen integriert, sag Open Source 862 00:41:55,720 --> 00:41:58,880 tatsächlich, und dann ist in Amcurity übersetzt und der 863 00:41:58,880 --> 00:42:02,040 Broker würde dann was, was Bridging genannt wird, würde 864 00:42:02,040 --> 00:42:04,640 dann praktisch die Brücke schlagen und dann Subset der 865 00:42:04,640 --> 00:42:07,680 Daten in den meisten Fällen, die in der Cloud relevant sind, eben 866 00:42:07,680 --> 00:42:10,320 dann in die Cloud schieben, aber auch von der Cloud der Daten 867 00:42:10,320 --> 00:42:11,680 empfangen, die dann zurückgehen sollen. 868 00:42:12,160 --> 00:42:14,920 Und man muss sich so vorstellen, der Incuity Broker, der dann 869 00:42:14,920 --> 00:42:16,880 lokal ist, agiert wie ein Client. 870 00:42:17,600 --> 00:42:20,480 Das heißt, er kann auch aus der Cloud raus, Publishen und auch 871 00:42:20,480 --> 00:42:24,880 Subsriben und das dann weiterverteilen in ja zu dem End 872 00:42:24,880 --> 00:42:27,600 Client würde ich es mal sagen, also n ja dreischichtiges. 873 00:42:27,600 --> 00:42:29,680 Modell, wenn man so will, genau, genau man. 874 00:42:29,680 --> 00:42:31,760 Kann da auch also sehr weit gehen. 875 00:42:31,760 --> 00:42:33,760 Also wenn du zum Beispiel Security Anforderungen hast, 876 00:42:33,760 --> 00:42:36,960 also viele unserer Kunden haben sogenannte demilitarisierte 877 00:42:36,960 --> 00:42:40,480 Zonen, das bedeutet du hast auch zum Beispiel. 878 00:42:40,800 --> 00:42:43,760 Du hast die die IT in der Fabrik möchtest du normalerweise 879 00:42:43,760 --> 00:42:47,600 abschirmen von von den wirklichen Produktionscomputern, 880 00:42:48,320 --> 00:42:51,240 erstmal weil in der in der Praxis diese oft sehr alt sind 881 00:42:51,240 --> 00:42:53,320 und oft nicht mehr gepflegt sind, wenn es um Sicherheits 882 00:42:53,320 --> 00:42:58,040 Updates geht, also auch so Windows 9802 1000 ist es nicht 883 00:42:58,040 --> 00:43:01,080 anhört oft, dass dass man das noch sieht und man möchte diese 884 00:43:01,080 --> 00:43:04,520 natürlich möglichst weit weg vom Internet auch halten, weil eben 885 00:43:04,520 --> 00:43:06,320 natürlich wenn da irgendwas kaputt geht dann. 886 00:43:07,040 --> 00:43:09,400 Oder Ransomware. Oder wie auch immer du möchtest 887 00:43:09,400 --> 00:43:11,920 ja nicht, dass dass es hier zu Problemen kommt und da kannst du 888 00:43:11,920 --> 00:43:16,480 eben auch dann wirklich Cloud Broker IT Broker in der Fabrik, 889 00:43:16,480 --> 00:43:19,600 Produktionsbroker in der Fabrik und dann eben auch sehr selektiv 890 00:43:19,600 --> 00:43:22,320 das eben auch dann trennen. Und weil wir gerade bei 891 00:43:22,320 --> 00:43:24,080 Sicherheit. Sind will ich auch einfach noch 892 00:43:24,080 --> 00:43:27,840 mal aus aus meinem eigenen Ansporn was reinpacken. 893 00:43:28,160 --> 00:43:31,160 Es ist nämlich so, dass das MQTT, obwohl es n anderes 894 00:43:31,160 --> 00:43:34,600 Protokoll ist als das HTTP, aber genauso sicher ist wie unser 895 00:43:34,600 --> 00:43:38,080 HTTPS, weil. Der Sicherheitslayer und Dominik 896 00:43:38,160 --> 00:43:40,560 widerspricht mir, wenn ich Quatsch erzähle, aber der das 897 00:43:40,560 --> 00:43:45,280 MQTT basiert genauso wie das HTTP unten auf unserem TCP Stack 898 00:43:45,680 --> 00:43:49,600 und SSL Zertifikate SSL ist ja das alte Wort, aber TLS, 899 00:43:49,680 --> 00:43:52,400 Verschlüsselung und so weiter funktioniert auf diesem Level, 900 00:43:52,400 --> 00:43:55,480 nämlich auf dem TCP Stack. Ja und beide Protokolle 901 00:43:55,480 --> 00:43:59,960 überliegen diesem, das heißt modernes MQTT was jetzt die 902 00:43:59,960 --> 00:44:02,960 Brücke schlägt zwischen zum Beispiel OT und IT, also dem. 903 00:44:03,400 --> 00:44:06,080 Operations Netzwerk, also den wichtigen Shopfrover. 904 00:44:06,080 --> 00:44:09,760 Was nicht gestört werden soll, kann auch TLS 12 moderne 905 00:44:09,760 --> 00:44:13,600 Verschlüsselung etablieren und die Daten genauso sicher 906 00:44:14,000 --> 00:44:16,960 zwischen dem Internet hin und herspielen, wie es ein HTTPS 907 00:44:16,960 --> 00:44:19,280 beim online banking kann. Ja, das heißt, da ist nichts neu 908 00:44:19,280 --> 00:44:22,480 erfunden, das basiert alles auf exakt der gleichen Technologie, 909 00:44:22,480 --> 00:44:25,040 also die genau die gleichen Implementierungen und Concodes 910 00:44:25,040 --> 00:44:27,360 und und und. Bibliotheken können da genommen 911 00:44:27,360 --> 00:44:30,160 werden, exakt, und das ist auch. Total wichtig, weil. 912 00:44:30,760 --> 00:44:33,200 Es ist so, wenn ich jetzt mir die typischen SSL 913 00:44:33,200 --> 00:44:36,400 beziehungsweise TLS Bibliotheken angucke, ob es das Open SSLS 914 00:44:36,400 --> 00:44:41,600 oder was auch immer das wird, von jedem werden wir eingesetzt. 915 00:44:41,600 --> 00:44:43,440 Wir haben wahrscheinlich Milliarden von diesen 916 00:44:43,440 --> 00:44:46,320 Installationen, das heißt, man kann davon ausgehen, es ist 917 00:44:46,320 --> 00:44:49,040 hinreichend sicher genug und selbst vor n paar Jahren hatten 918 00:44:49,040 --> 00:44:52,480 wir hier in der an Hardbeef oder auch an andere Sicherheitslücken 919 00:44:53,040 --> 00:44:55,720 in Rekordzeit wurden die jetzt auch gepatcht weil die gesamte 920 00:44:55,720 --> 00:44:58,800 globale Infrastruktur für alle IT davon abhängig war. 921 00:44:59,440 --> 00:45:02,520 Und das ist sehr gut. Auch, dass tatsächlich das MQT 922 00:45:02,520 --> 00:45:06,160 nicht das Rad neu erfindet, einfach nur, weil bei speziell 923 00:45:06,160 --> 00:45:09,160 bei Sicherheit möchte man ja auf das Altbewährte setzen, dass sie 924 00:45:09,160 --> 00:45:11,840 jeder benutzt und nicht irgendwie was Neues erfinden, 925 00:45:11,840 --> 00:45:14,080 weil man irgendwie denkt, man ist gerade smarter als alle 926 00:45:14,080 --> 00:45:17,040 Menschheit zuvor und, und das ist auch so n bisschen das 927 00:45:17,040 --> 00:45:20,120 Thema, das ich ehrlich gesagt n bisschen bemängele, auch bei 928 00:45:20,120 --> 00:45:23,520 manchen offenen Protokollen oder auch bei die, die dann eben auch 929 00:45:23,520 --> 00:45:25,760 sagen, ja, Moment, ich, ich entwickle mein eigenes Security 930 00:45:25,760 --> 00:45:28,560 Modell oder auch meine eigenen Bibliotheken, jetzt hast du zum 931 00:45:28,560 --> 00:45:31,400 Beispiel. Sag ich mal ab und zu. 932 00:45:31,400 --> 00:45:34,560 Ich mein das geht auch anders, aber zum Beispiel ich, ich 933 00:45:34,560 --> 00:45:37,320 erinnere teilweise an manche Features von OPCUA, die ja sagen 934 00:45:37,320 --> 00:45:40,560 ja im Moment, es ist ja sehr gut, weil wir uns eigenes 935 00:45:40,560 --> 00:45:43,200 Sicherheitsmodell haben, das ist ist ein Thema natürlich, man 936 00:45:43,200 --> 00:45:46,080 kann ja auch TLS machen, aber es gibt ja auch andere Features, 937 00:45:46,800 --> 00:45:50,240 oder wenn ich jetzt Richtung gehe Quick als Beispiel, das ist 938 00:45:50,240 --> 00:45:54,080 ja auch weitestgehend auf UDP passiert und das Problem bei 939 00:45:54,080 --> 00:45:56,480 UUDP Kommunikation, also wenn ich jetzt tief in das Stack gehe 940 00:45:56,480 --> 00:45:59,120 ist ja, dass ich hier genau kein TLS nutzen kann. 941 00:45:59,320 --> 00:46:03,040 Man muss sich eben eigene, sag ich mal, Wege finden, das zu 942 00:46:03,040 --> 00:46:04,640 machen. Das heißt nicht, dass es weniger 943 00:46:04,640 --> 00:46:05,840 sicher ist. Es ist aber einfach nur das 944 00:46:05,840 --> 00:46:08,480 Risiko, dass etwas gefunden als ein Fehler gefunden wird, der 945 00:46:08,480 --> 00:46:11,120 vorher noch nicht bekannt war, ist einfach höher, weil einfach 946 00:46:11,360 --> 00:46:15,760 die Wahrscheinlichkeit, dass es aktuell SSL Fehler gibt, wo alle 947 00:46:15,760 --> 00:46:17,920 Computersysteme betroffen sind, die noch unentdeckt ist, ist 948 00:46:17,920 --> 00:46:20,840 viel viel geringer, wie wenn ich jetzt so ein Nischenprodukt 949 00:46:20,840 --> 00:46:23,040 habe. Deswegen ne eigene Security 950 00:46:23,040 --> 00:46:24,880 mitbringt. Deshalb bin ich n großer Fan 951 00:46:24,880 --> 00:46:27,440 davon das zu nutzen, was jeder benutzt, ich auch und 952 00:46:27,440 --> 00:46:30,160 protokollebene nur das zu machen was da jetzt immer der Valual 953 00:46:30,160 --> 00:46:31,520 ist. Ja und total. 954 00:46:31,520 --> 00:46:33,000 Wichtig, dass wir den Punkt noch mal gemacht haben. 955 00:46:33,000 --> 00:46:35,640 Beide, das ist manchmal n bisschen Überzeugungsarbeit, die 956 00:46:35,640 --> 00:46:39,040 man noch liefern muss, wenn man an Kunden, die, sag ich mal, mit 957 00:46:39,040 --> 00:46:40,640 der Digitalisierung gerade noch anfangen. 958 00:46:41,280 --> 00:46:43,800 Ja so was Neumodisches verkaufen will, was ist da los und so 959 00:46:43,800 --> 00:46:46,240 weiter ja, man kann einfach aus technischer Sicht nur sagen, ja, 960 00:46:46,240 --> 00:46:49,680 das ist genau das, was das ganze Internet ist, und das ist der 961 00:46:49,680 --> 00:46:51,120 Standard, der Sicherheitsstandard, der auch 962 00:46:51,120 --> 00:46:53,440 überall. Angewendet wird und wenn der 963 00:46:53,440 --> 00:46:55,360 nicht sicher ist, dann hast du auch bei deinem Online Banking 964 00:46:55,360 --> 00:46:57,280 Problem ne. Also dann haben wir alle ein 965 00:46:57,280 --> 00:46:58,760 Problem, ne das ist noch mal sehr wichtig und die 966 00:46:58,760 --> 00:47:00,720 Wahrscheinlichkeit, dass. Jemand erstmal die Banden 967 00:47:00,720 --> 00:47:03,840 angreift wie die Firma, ist deutlich höher. 968 00:47:03,840 --> 00:47:07,760 Genau die Sicherheit, nicht die erste Firma dieser dieser 969 00:47:07,760 --> 00:47:09,600 angegriffen wird das nach das andere. 970 00:47:09,840 --> 00:47:12,080 Jetzt gehe ich aber noch mal. In in die Wunde tiefer, weil wir 971 00:47:12,080 --> 00:47:14,240 gerade über Sicherheit sprechen. Noch einen, vielleicht noch 972 00:47:14,240 --> 00:47:17,040 einen kleinen weiteren Ding, denn wir haben ja jetzt, wer 973 00:47:17,040 --> 00:47:19,680 jetzt ganz genau zugehört hat, der weiß, dass wir 2 974 00:47:19,680 --> 00:47:22,440 Verbindungen haben. Weil wir nämlich die die dritte 975 00:47:22,440 --> 00:47:24,880 Komponente haben, die wir nicht bei Client Server haben, ne, 976 00:47:24,880 --> 00:47:28,240 also ich nehme auseinander was ich sagen will, wir haben im im 977 00:47:28,240 --> 00:47:32,440 HTTPHTTPS jetzt sagen wir mal direkt einen Client der direkt 978 00:47:32,440 --> 00:47:34,080 mit einem Server spricht, da ist in der Mitte nichts mehr 979 00:47:34,080 --> 00:47:38,640 dazwischen, während wir wenn wir mit MQTT sprechen, dann haben 980 00:47:38,640 --> 00:47:40,880 wir den Client der mit dem Broker spricht, der 981 00:47:40,880 --> 00:47:44,160 Weiterverbindet zu dem nächsten Client, also einen Mann in der 982 00:47:44,160 --> 00:47:47,120 Mitte, sagen wir mal jetzt kann ich natürlich. 983 00:47:47,960 --> 00:47:50,560 Zweimal verschlüsseln. Ja, ich hab nämlich 2 TCP 984 00:47:50,560 --> 00:47:51,960 Verbindungen, da muss man jetzt aufpassen. 985 00:47:51,960 --> 00:47:54,960 Ja, also der der Publisher, der Client zu dem Server published, 986 00:47:55,040 --> 00:47:57,680 der kann natürlich ne TLS Verbindung aufbauen und der 987 00:47:57,680 --> 00:48:00,240 Subscriber der eventuell interessiert ist an diesem Event 988 00:48:00,240 --> 00:48:04,440 kann das ja auch ja aber der Broker in der Mitte was da jetzt 989 00:48:04,440 --> 00:48:08,360 passiert, das weiß ich quasi als Nutzer jetzt sag ich mal nicht 990 00:48:08,360 --> 00:48:10,600 da muss ich jetzt auf einmal volles Vertrauen schenken in die 991 00:48:10,600 --> 00:48:14,560 Firma, den Broker in der Mitte zurechtstellt weil zwar wird es 992 00:48:14,560 --> 00:48:17,200 dahin verschlüsselt und der Weg davon auch wieder weg. 993 00:48:17,600 --> 00:48:20,360 Aber auf dem Broker selber, wenn ich jetzt die Daten nicht, und 994 00:48:20,360 --> 00:48:22,120 das müssen wir auch kurz auseinandernehmen, wir sprechen 995 00:48:22,120 --> 00:48:24,720 ja bei TLS von Kanalverschlüsselung, das heißt, 996 00:48:24,960 --> 00:48:27,760 ich kann es, ist quasi wie n panzerkabel, da fließen die 997 00:48:27,760 --> 00:48:31,040 Bytes durch, keiner kann in dieses Kabel sich anhängen und 998 00:48:31,040 --> 00:48:34,400 reingucken, aber die die Daten die da durchfließen, die sind 999 00:48:34,400 --> 00:48:37,200 wenn ich wenn ich jetzt nichts Besonderes mache, schon im so 1000 00:48:37,200 --> 00:48:40,960 wie sie sind im Play Format drinne, ja quasi als Bytes, aber 1001 00:48:40,960 --> 00:48:42,640 können quasi wieder zusammengebaut werden. 1002 00:48:43,040 --> 00:48:46,480 Ja das heißt wenn ich jetzt. Ich jetzt wirklich kriminelle 1003 00:48:46,480 --> 00:48:49,360 Energie aufbringen wollte, als als auch Softwareanbieter. 1004 00:48:49,360 --> 00:48:52,080 Also jetzt mal nicht voraussetzen so, aber ich könnte 1005 00:48:52,080 --> 00:48:55,440 quasi die Daten sehen, weil die kommen an auf den Broker und 1006 00:48:55,440 --> 00:48:57,640 werden da weiter geschickt und ich könnte sie manipulieren, ich 1007 00:48:57,640 --> 00:49:00,720 könnte abzweigen, könnte was weiß ich ja und soweit ich das 1008 00:49:00,720 --> 00:49:04,680 weiß Dominik von Hause aus bringt die Spezifikation jetzt 1009 00:49:04,680 --> 00:49:07,880 nichts irgendwie mit mit Ende zu Ende Verschlüsselung oder und so 1010 00:49:07,880 --> 00:49:12,760 weiter ja vielleicht magst du da ein 2 Sätze noch zu sagen ob das 1011 00:49:12,760 --> 00:49:16,360 n Problem ist bei euren Kunden. Nämlich genau diese, dieses 1012 00:49:16,360 --> 00:49:18,640 Vertrauen, dass ich in diesem Broker haben muss, an der Stelle 1013 00:49:18,880 --> 00:49:21,720 und ob es sogar welche gibt, die dann quasi mit einer 1014 00:49:21,720 --> 00:49:24,600 angestückten Lösung, und das geht ja mit tivi Hellmann zum 1015 00:49:24,600 --> 00:49:27,240 Beispiel, relativ einfach damit so da quasi so ne Art 1016 00:49:27,240 --> 00:49:29,520 Datenverschlüsselung noch hinzufügen zu der 1017 00:49:29,520 --> 00:49:33,440 Kanalverschlüsselung um so ne Ende zu Ende Verschlüsselung zu 1018 00:49:33,440 --> 00:49:35,120 erreichen, oder ist das kein Thema? 1019 00:49:35,360 --> 00:49:37,640 Es ist n wichtiges Thema. Security an sich ist ja auf 1020 00:49:37,640 --> 00:49:41,400 verschiedenen Layern, also du ja, das heißt von von von, von 1021 00:49:41,400 --> 00:49:43,840 Netzwerk als Orkans tief unten bis auf Applikationsebene. 1022 00:49:44,720 --> 00:49:46,800 Es ist n großes Thema. Ich hab tatsächlich vor vor 1023 00:49:46,800 --> 00:49:50,080 Jahren also eine zehnteilige Blogpostserie genau geschrieben 1024 00:49:50,080 --> 00:49:51,840 über die verschiedenen Ansätze die man machen kann. 1025 00:49:52,200 --> 00:49:54,040 Es ist ja nicht nur die Verschlüsselung, sondern es ist 1026 00:49:54,040 --> 00:49:56,400 auch Trust. Also selbst wenn jemand OK lass 1027 00:49:56,400 --> 00:49:58,800 mal aufdröseln, also erstmal mit Trust. 1028 00:49:58,800 --> 00:50:02,560 Also die Komponente an sich, da ist es tatsächlich auch wichtig, 1029 00:50:03,360 --> 00:50:08,360 dass die ich sag mal die Komponente trusted ist und ich 1030 00:50:08,360 --> 00:50:11,840 sag es jetzt deshalb auch, weil es gibt wahnsinnig jetzt, wenn 1031 00:50:11,840 --> 00:50:14,120 jemand jetzt sagt OK Hey Infinity, Ich geh jetzt irgendwo 1032 00:50:14,120 --> 00:50:16,640 hin. Es gibt viele Open Source und es 1033 00:50:16,640 --> 00:50:18,840 ist auch sehr gut, weil Open Source kann man weitestgehend 1034 00:50:18,840 --> 00:50:21,600 inspizieren, speziell wenn es so Sachen wie Moskito, der 1035 00:50:21,600 --> 00:50:24,080 Quellcode der hier ist, landet auch in deinen Linux 1036 00:50:24,560 --> 00:50:27,040 Repostories, das heißt das ist schon mal gut, weil das heißt 1037 00:50:27,200 --> 00:50:29,440 also auch das, dass es gibt eine eine kleine Firma in 1038 00:50:29,440 --> 00:50:32,800 Deutschland, die Support eben anbietet, dafür aber im Großen 1039 00:50:32,800 --> 00:50:35,080 und ganzen ist es halt so. Ich bin auf mich alleine 1040 00:50:35,080 --> 00:50:36,720 gestellt, auch sicherheitstechnisch, das heißt 1041 00:50:36,720 --> 00:50:39,280 es ist gut wenn ich den Quellcode inspizieren kann, das 1042 00:50:39,280 --> 00:50:40,920 ist auch der eine der Benefits von Open Source. 1043 00:50:41,600 --> 00:50:44,320 Und das wär eine Möglichkeit. Es gibt aber auch andere Dinge 1044 00:50:44,320 --> 00:50:47,160 wie es gibt zum Beispiel ein Produkt aus China, das ist auch 1045 00:50:47,160 --> 00:50:49,640 ein sehr, sehr populärer MQT Broker, der wieder aus China 1046 00:50:49,640 --> 00:50:53,240 eben entwickelt, und der ist auch ein Großteil davon ist Open 1047 00:50:53,240 --> 00:50:55,920 Source, der hat aber dann auch deutlich mehr Features wie 1048 00:50:55,920 --> 00:50:58,520 Moskito und hier ist es oft so, ist genau trust. 1049 00:50:58,520 --> 00:51:02,240 Also als Beispiel möchte man jetzt wie wie stark vertraut man 1050 00:51:02,240 --> 00:51:04,400 dem also es ist. Ich rede konkret vom Produkt, 1051 00:51:04,400 --> 00:51:06,520 ist es in Erlangen geschrieben. Erlang ist eine 1052 00:51:06,520 --> 00:51:08,800 Programmiersprache. Es war Open Source, ist aber hat 1053 00:51:08,800 --> 00:51:11,360 eine sehr kleine Community, das heißt, es gibt sehr wenig Leute, 1054 00:51:11,360 --> 00:51:14,880 die auch tatsächlich erlang Quellcode verstehen können und 1055 00:51:14,880 --> 00:51:18,480 erlang kann auch zur Laufzeit eben Quellcode austauschen, das 1056 00:51:18,480 --> 00:51:20,680 heißt wenn ich jetzt dann mir ein Paket runterladen und es 1057 00:51:20,680 --> 00:51:23,440 installiere, kann es zur Laufzeit modifiziert werden, was 1058 00:51:23,440 --> 00:51:26,440 eben zur Laufzeit passiert. Als Beispiel so, und da muss man 1059 00:51:26,440 --> 00:51:28,600 eben gucken, welches Risiko gehe ich ein, möchte ich jetzt zum 1060 00:51:28,600 --> 00:51:30,240 Beispiel meine Produktionsprozesse davon 1061 00:51:30,240 --> 00:51:31,760 abhängig machen. Da ist dann der Trust beim 1062 00:51:31,760 --> 00:51:35,200 Vendor und bei uns ist es so. Ich mein, Wir sind im Bereich 1063 00:51:35,200 --> 00:51:38,240 MPDT Broker, Wir sind eben da der Marktführer weltweit, auch 1064 00:51:38,960 --> 00:51:41,600 ist es buchstäblich, damit verdienen wir unser Geld, seit 1065 00:51:41,640 --> 00:51:46,240 im Endeffekt 2012 und wir haben die größten Firmen der Welt, da 1066 00:51:46,240 --> 00:51:48,000 ist die die Komponente Trust. Ist aber erstmal keine 1067 00:51:48,000 --> 00:51:51,360 Sicherheit, das ist erstmal nur wie weit vertraue ich dir so 1068 00:51:51,520 --> 00:51:54,160 grundsätzlich würde ich jedem empfehlen niemandem vertrauen. 1069 00:51:54,320 --> 00:51:56,800 Keine Software vertrauen unter keinen Umständen so. 1070 00:51:57,200 --> 00:51:59,400 Deshalb machen wir auch genau erstmal kanalverschlüsselung, 1071 00:51:59,400 --> 00:52:01,760 das ist schon mal gut, wenn wir das haben und dann kommen aber 1072 00:52:01,760 --> 00:52:04,240 noch andere Punkte dazu bei Sicherheit, das heißt 1073 00:52:04,480 --> 00:52:07,040 normalerweise zur zur Kanalverschlüsselung, habe ich 1074 00:52:07,040 --> 00:52:08,800 oft noch das Thema Authentifizierung und 1075 00:52:08,800 --> 00:52:11,760 Autorisierung, weil bloß weil ich mich jetzt sicher mit dem 1076 00:52:11,760 --> 00:52:15,600 Server verbinden kann, heißt es ja nicht, dass dass ich mich 1077 00:52:15,600 --> 00:52:18,520 verbinden darf, weil das Beispiel, angenommen, ich habe 1078 00:52:18,520 --> 00:52:21,080 hier einen hier einen Broker und ich habe der der Publisher als 1079 00:52:21,080 --> 00:52:23,920 sendet einfach Daten. Wenn jetzt jeder auf der Welt 1080 00:52:23,920 --> 00:52:26,480 einfach sich sicher über Kanalverschlüsselung einfach zum 1081 00:52:26,480 --> 00:52:29,360 Server verbinden könnte und alle Daten abzweigt, dann zweigt er 1082 00:52:29,360 --> 00:52:32,600 die Daten sicher ab. Das klingt ja, weil hier im 1083 00:52:32,600 --> 00:52:35,840 Endeffekt, dann sind die Daten trotzdem weg, das heißt, hier 1084 00:52:35,840 --> 00:52:38,080 gehe ich dann rein und hier möchte ich Authentifizierung, 1085 00:52:38,080 --> 00:52:41,120 Autorisierung haben, hier komme ich dann in Gefilde rein wie 1086 00:52:41,120 --> 00:52:44,640 Zertifikatsbasiert basierte Authentifizierung, die eben dann 1087 00:52:44,640 --> 00:52:47,120 auf der TLS Ebene ist. Kennt man HTTP vielleicht auch, 1088 00:52:47,760 --> 00:52:50,000 da komme ich in Gefilde rein wie wie? 1089 00:52:50,240 --> 00:52:53,240 Chase and Web Tokens basiert also o auf in dem konkreten Fall 1090 00:52:53,240 --> 00:52:56,440 würde man da auch in dem oder Open ID connect teilweise, also 1091 00:52:56,440 --> 00:52:58,680 das heißt ich, ich komme in all diese anderen 1092 00:52:58,680 --> 00:53:01,040 Sicherheitsstandards rein, die ich im Web auch habe, und das 1093 00:53:01,040 --> 00:53:03,200 kann ich mit Endcuity auch benutzen, das ist ganz wichtig, 1094 00:53:03,680 --> 00:53:05,840 das heißt, dann bin ich schon mal authentifiziert, also darf 1095 00:53:05,840 --> 00:53:09,480 ich mich verbinden und also das Thema Autorisierung, ich darf 1096 00:53:09,480 --> 00:53:11,800 mich zwar verbinden, aber darf ich diese Art von Daten 1097 00:53:11,800 --> 00:53:14,640 bekommen, das heißt, das ist dann, sag ich mal Enterprise 1098 00:53:14,720 --> 00:53:17,520 Security, die man, die man normalerweise implementiert in 1099 00:53:17,520 --> 00:53:21,280 echten Projekten, und dann? Um jetzt auf deine Frage 1100 00:53:21,280 --> 00:53:23,680 zurückzukommen, was tu ich dann mit den Daten selber? 1101 00:53:23,920 --> 00:53:27,320 Ende zu Ende Verschlüsselung und da gibt es da auch verschiedene 1102 00:53:27,320 --> 00:53:31,200 Wege, aber ich sag mal der einfachste Fall wäre bevor der 1103 00:53:31,200 --> 00:53:34,720 Publisher seinen Daten absendert bevor es in den Umschlag packt 1104 00:53:34,960 --> 00:53:38,160 gehe ich her und Verschlüssel das zum Beispiel mit dem ich 1105 00:53:38,160 --> 00:53:40,960 einfach sagen Passwort, das heißt mit einer Phrase die nur 1106 00:53:40,960 --> 00:53:44,240 ich kenne und verschicke die und wenn jetzt jemand trotzdem die 1107 00:53:44,240 --> 00:53:47,480 Daten abzweigen würde, wie auch immer dann dann würde ich im 1108 00:53:47,480 --> 00:53:50,440 Endeffekt einfach nur hier. Hier was sehen, was mir nichts 1109 00:53:50,440 --> 00:53:51,440 bringt, weil es ist verschlüsselt. 1110 00:53:51,440 --> 00:53:53,800 Das sind dann einfach nur irgendwelche random Bytes und 1111 00:53:53,800 --> 00:53:56,280 wenn ich nicht diese pass Phrase kenne, dann kann ich es nicht 1112 00:53:56,280 --> 00:53:58,640 nicht entschlüsseln, das wäre dann, das wäre dann eben wieder 1113 00:53:58,640 --> 00:54:00,960 symmetrische Verschlüsselung symmetrisch, ja genau. 1114 00:54:00,960 --> 00:54:02,720 Und. Wenn ich natürlich ganz weit 1115 00:54:02,720 --> 00:54:06,680 gehe, und es ist natürlich Best practice, wäre asymmetrisch, das 1116 00:54:06,680 --> 00:54:08,840 heißt, dass ich auch im Endeffekt, vereinfacht gesagt, 1117 00:54:08,840 --> 00:54:11,960 Zertifikats passiert, das mache ich, das heißt, das heißt, ich 1118 00:54:11,960 --> 00:54:14,000 kann, wenn ich es verschlüssele, kann ich es nicht damit wieder 1119 00:54:14,000 --> 00:54:16,400 entschlüsseln, und wenn ich es entschlüsseln kann, kann ich es 1120 00:54:16,400 --> 00:54:18,560 nicht verschlüsseln. Es wäre natürlich ideal. 1121 00:54:19,280 --> 00:54:22,600 In der Praxis ist es aber so, dass ich damit die Kopplung, 1122 00:54:22,600 --> 00:54:25,920 also dass ich damit die die Endpunkte wieder kopple, genau 1123 00:54:26,240 --> 00:54:27,760 das ist. Eigentlich Paradoxon zu dem, was 1124 00:54:27,760 --> 00:54:30,640 wir eigentlich haben wollen. Lusely Coupled Components, die 1125 00:54:30,640 --> 00:54:31,720 sich eigentlich so gut kennen sollen. 1126 00:54:31,720 --> 00:54:34,640 Und wenn ich jetzt asymmetrische Verschlüsselung reinbringe habe 1127 00:54:34,640 --> 00:54:37,040 ich wieder, musste ich wieder ziemlich viel wissen von den 1128 00:54:37,200 --> 00:54:39,840 genau schon in den Kleinen das große Problem speziell. 1129 00:54:39,840 --> 00:54:41,040 Sagen wir mal bei Internet der Dinge. 1130 00:54:41,040 --> 00:54:44,640 Wenn ich jetzt das bei mir in meinem Netzwerk mache, das ich 1131 00:54:44,640 --> 00:54:47,680 unter Kontrolle hab, alles gut, weil da weiß ich das ja auch. 1132 00:54:48,120 --> 00:54:49,920 Aber stellen wir uns das mal vor als Beispiel, ich bin 1133 00:54:49,920 --> 00:54:52,880 Autohersteller, es ist ein relativ schwieriges Problem, 1134 00:54:53,120 --> 00:54:56,960 dass ich sicher eine Verschlüsselung auf die auf das 1135 00:54:56,960 --> 00:54:59,280 Gerät bringe, dass ich auch meine Endkunden ausliefere, weil 1136 00:54:59,280 --> 00:55:02,880 ich möchte ja auch verhindern, dass dass dieses Geheimnis, sage 1137 00:55:02,880 --> 00:55:06,240 ich mal, genommen wird, um sich dann auszugeben, als jemand das 1138 00:55:06,240 --> 00:55:08,280 heißt, wenn ich dann hier, da gehe ich dann in ein Produkt, 1139 00:55:08,280 --> 00:55:11,040 Sicherheit rein bei physischen Geräten, also es ist ein 1140 00:55:11,120 --> 00:55:13,280 schwieriges Problem, es gibt viele Lösungen dafür. 1141 00:55:14,000 --> 00:55:16,640 Aber tatsächlich, das das sind so Sachen da wo wir auch das 1142 00:55:16,640 --> 00:55:18,440 Beratung anbieten in dem Bereich, und da gibt es auch 1143 00:55:18,440 --> 00:55:20,000 andere Beratungsweise, die sehr gut sind. 1144 00:55:20,360 --> 00:55:22,480 Also man kann das sehr tief gehen und sollte man auch. 1145 00:55:23,360 --> 00:55:26,400 Ich glaube, wichtig ist nur für, vielleicht für die Zuhörer, das 1146 00:55:26,400 --> 00:55:29,280 ist, wieso eine so eine Zwiebel, also es gibt auf allen Layern, 1147 00:55:29,280 --> 00:55:32,320 muss man eben sich das angucken und es reicht nicht nur SSL zu 1148 00:55:32,320 --> 00:55:34,320 machen, im Web übrigens auch nicht aus meiner Sicht. 1149 00:55:35,200 --> 00:55:37,440 Und dann zu gucken, OK wo brauch ich denn welche 1150 00:55:37,440 --> 00:55:39,680 Sicherheitsmechanismen und die wie gesagt, dazu hab ich auch 1151 00:55:39,680 --> 00:55:42,040 vor einiger Zeit vor einigen Jahren auch ne zehnteilige 1152 00:55:42,040 --> 00:55:46,160 Blogpost Serie geschrieben, die genau diesen Zwiebel in 10 in 10 1153 00:55:46,160 --> 00:55:48,280 Teile eben zerlegt. Cool, danke für die. 1154 00:55:48,280 --> 00:55:50,440 Antwort, Tipp Top können wir ja verlinken, ja. 1155 00:55:50,440 --> 00:55:51,440 Können wir verlinken? Genau. 1156 00:55:51,760 --> 00:55:53,760 Wollt ihr noch was technisches? Besprechen, ich, ich. 1157 00:55:53,760 --> 00:55:55,560 Ich kann auf dem Niveau logischerweise nicht 1158 00:55:55,560 --> 00:55:58,440 mitquatschen, aber ich find es ziemlich cool und wenn ihr 1159 00:55:58,440 --> 00:56:00,000 nichts technisches mehr quatschen wollt, hätte ich noch 1160 00:56:00,000 --> 00:56:03,040 so n bisschen organisatorische Fragen zu MGTT der Community. 1161 00:56:03,280 --> 00:56:06,000 Ich hab eine Pseudotechnische. Pseudotechnische natürlich auch 1162 00:56:06,560 --> 00:56:08,920 geht ganz schnell, ich glaub sie antwortet auch schnell, es gibt 1163 00:56:08,920 --> 00:56:12,840 ja das MQTT Protokoll, ja es es gibt im Prinzip 2 Versionen, 1164 00:56:12,840 --> 00:56:17,520 will ich mal so sagen von MQTT in meinem Gehirn ne das 3 Elfer 1165 00:56:17,760 --> 00:56:21,840 soweit ich weiß also quasi das letzte Protokoll von Version 3 1166 00:56:21,840 --> 00:56:24,960 und dann gibt es das Fünferprotokoll und immer ganz 1167 00:56:24,960 --> 00:56:27,600 platt gesprochen was der Unterschied in meinem also ich 1168 00:56:27,600 --> 00:56:30,000 benutze noch das 3 Elfer erstmal muss ich mich outen. 1169 00:56:30,880 --> 00:56:33,200 Reicht mir erstmal und das Fünferprotokoll führt 1170 00:56:33,440 --> 00:56:36,720 requestresponse Pattern noch oben drüber noch dazu. 1171 00:56:37,040 --> 00:56:39,320 Aber jetzt kommt meine Frage ist ich will gar nicht auf das 1172 00:56:39,320 --> 00:56:41,520 Fünfer eingehen auf das 3 Elfer aber ich frag aber was wo ist 1173 00:56:41,520 --> 00:56:45,760 eigentlich Version 4 geblieben? Sehr, sehr gute Frage. 1174 00:56:45,760 --> 00:56:50,440 Also Version 3 ist tatsächlich 311 es ist tatsächlich die, die 1175 00:56:50,560 --> 00:56:53,040 die 11 genau also. Ist die offizielle Version. 1176 00:56:53,360 --> 00:56:57,360 Das ist die erste offiziell spezifizierte Version, die auch 1177 00:56:57,360 --> 00:56:59,800 ein Standard ist bei Oasis und bei bei ISO. 1178 00:57:00,480 --> 00:57:02,960 Und MQTT gab es davor, war aber im Endeffekt einfach nur 1179 00:57:02,960 --> 00:57:05,040 proprietär. Gab es Implementierungen? 1180 00:57:05,320 --> 00:57:07,360 IBM hat dann irgendwann mal gesagt, wir versprechen noch 1181 00:57:07,360 --> 00:57:09,720 nicht zu verklagen, wenn ihr es implementiert, aber es hat nicht 1182 00:57:09,720 --> 00:57:12,760 gut genug für einen offenen Standard so und als als wir 1183 00:57:12,760 --> 00:57:16,400 einen offenen Standard entwickelt haben mit 311, gab es 1184 00:57:16,400 --> 00:57:20,720 davor schon NQT, Version 3 ist nur 31 eigentlich um es um es 1185 00:57:20,720 --> 00:57:24,320 genau zu sagen, und das ist dieser Classic Version, die wird 1186 00:57:24,320 --> 00:57:26,240 aber dies im Endeffekt ging es im Einsatz. 1187 00:57:26,920 --> 00:57:28,240 Glaube ich. IBM hat bestimmt noch 1188 00:57:28,240 --> 00:57:29,920 Kompatibilität. Wir haben auch tatsächlich 1189 00:57:29,920 --> 00:57:34,840 Kompatibilität, aber nutzt schon sehr lange keiner mehr und und 1190 00:57:34,840 --> 00:57:38,320 wenn ich jetzt mir es angucke, wenn ich jetzt wirklich den den 1191 00:57:38,320 --> 00:57:42,240 den Traffic Entschlüsse, also praktisch mir angucke, auf was 1192 00:57:42,240 --> 00:57:44,160 wird denn überhaupt übertragen auf der Ebene? 1193 00:57:44,720 --> 00:57:47,840 Normalerweise funktionieren Protokolle so, dass wenn ich 1194 00:57:47,840 --> 00:57:50,720 jetzt so eine Art handshake wird da gemacht, das heißt. 1195 00:57:51,280 --> 00:57:54,480 Wenn der Client zum Server geht, dann injiziert das der Client 1196 00:57:54,480 --> 00:57:56,240 erstmal. Hey, ich möchte mit dir lieber 1197 00:57:56,240 --> 00:58:01,960 Server bitte in Version 331 reden, das ist Classic 311 oder 1198 00:58:01,960 --> 00:58:03,880 in Version 5. Das heißt der Client kann sich 1199 00:58:03,880 --> 00:58:07,720 das aussuchen in welcher Version er reden möchte und endgültig 1200 00:58:07,720 --> 00:58:12,720 ist so kompakt, dass die Versionsnummer 3 wurde verwendet 1201 00:58:12,720 --> 00:58:16,960 für 31, also für die Classic Version und leider geht es nur 1202 00:58:16,960 --> 00:58:19,600 mal nur nur ganz. Das heißt ich hab 345 und 1203 00:58:19,600 --> 00:58:23,440 hochzellen so. Und dann wurde eben amcurity 1204 00:58:23,440 --> 00:58:28,480 Version 311 hat nämlich tatsächlich nur die Nummer 4. 1205 00:58:28,480 --> 00:58:30,240 Das heißt, wenn ich jetzt wirklich das Entschlüssel und 1206 00:58:30,240 --> 00:58:32,480 den Weiterschlag machen kann, sehe ich die Version Nummer 4. 1207 00:58:32,720 --> 00:58:36,560 Das ist eigentlich 4 so und da mal die Diskussion natürlich, 1208 00:58:36,800 --> 00:58:38,560 was machen wir denn jetzt eigentlich, weil eigentlich 1209 00:58:38,560 --> 00:58:42,880 müssten wir amcurity Version 40 ja veröffentlichen und da war 1210 00:58:42,880 --> 00:58:45,440 so, das ist aber komisch, wenn Version 4 einfach mal die Nummer 1211 00:58:45,440 --> 00:58:49,480 5 hat ja so. Aber man kann eben dieses Feld 1212 00:58:49,480 --> 00:58:51,520 auch nicht mehr ändern, weil ich ja damit genau diese 1213 00:58:51,520 --> 00:58:53,560 Kompatibilität, die Rückwärtskompatibilität, nicht 1214 00:58:53,560 --> 00:58:56,280 mehr habe. Das heißt, was ist passiert, OK, 1215 00:58:56,280 --> 00:58:58,560 wurde auf verso 5 genommen und da haben wir gesagt, OK, 1216 00:58:58,560 --> 00:59:01,360 eigentlich ist es kommet doof, wir machen jetzt verso 5, 1217 00:59:01,600 --> 00:59:04,480 nächste Version wird dann 67 und so weiter und allein das was ich 1218 00:59:04,480 --> 00:59:07,520 sehe, weil sonst ist das Macht der Entwickler kaputt wenn du 1219 00:59:07,640 --> 00:59:10,960 wenn du hier denkst so du du Kommunizierst mit verso 5 mit 1220 00:59:10,960 --> 00:59:15,040 verso 4 siehst du auch in der 5 als Beispiel also für den für 1221 00:59:15,040 --> 00:59:18,480 den Zweck des dünnen Umschlags. Ist die ist die Version, die 1222 00:59:18,480 --> 00:59:21,200 kommuniziert wird zwischen Client und Server auf einen 1223 00:59:21,200 --> 00:59:24,640 einzelnen Client integer begrenzt und 311 hätte keinen 1224 00:59:24,640 --> 00:59:27,040 Platz gefunden. Deswegen muss es intern 4 sein, 1225 00:59:27,040 --> 00:59:30,160 was im Protokoll steht für 311, weswegen wir nicht die 1226 00:59:30,160 --> 00:59:33,040 Viererversion nach außen haben und nur die Firma dann also gut 1227 00:59:33,280 --> 00:59:35,200 es. Sein sollte. 1228 00:59:35,200 --> 00:59:37,760 Marketing folgt der Technik und nicht anderen. 1229 00:59:38,080 --> 00:59:39,200 Genau. Sehr cool. 1230 00:59:39,760 --> 00:59:42,240 Ich bin fast durch, ich lass dich gleich noch dazu ich nur 1231 00:59:42,240 --> 00:59:44,240 noch kurz ne Frage, ist das bashed du mich wenn ich jetzt 1232 00:59:44,240 --> 00:59:48,600 sage ich benutz noch 311? Und nicht 5 kannst du da ganz 1233 00:59:48,600 --> 00:59:50,160 kurz sagen. Muss man eigentlich jetzt 5 1234 00:59:50,160 --> 00:59:51,920 nehmen oder ist es völlig in Ordnung, wenn ich jetzt die 1235 00:59:51,920 --> 00:59:54,360 Features von 5 nicht brauche, dass ich bei 311 noch bin und ne 1236 00:59:54,360 --> 00:59:55,200 ich würd euch nicht, ich würd euch. 1237 00:59:55,200 --> 00:59:57,400 Nicht bashen, ich mein, es gibt ja auch noch Leute, die Windows 1238 00:59:57,400 --> 01:00:00,440 2000 benutzen. Nee, aber du bitte, willst du 1239 01:00:00,440 --> 01:00:02,680 jetzt aber. Nicht einfach Spaß für Seite. 1240 01:00:02,680 --> 01:00:05,080 Nee, Spaß für Seite, nee, nee, gar nicht. 1241 01:00:05,080 --> 01:00:07,680 Tatsächlich ist es so, es ist kompatibel, es ist Feature 1242 01:00:07,680 --> 01:00:09,760 Complete, es ist Rock, solid wird eingesetzt. 1243 01:00:10,240 --> 01:00:13,200 Für neue Applikationen würde ich tatsächlich empfehlen, Miversum 1244 01:00:13,200 --> 01:00:17,440 5 anzugucken ist auch weil es ist im Endeffekt dasselbe, nur 1245 01:00:17,440 --> 01:00:20,400 mehr das heißt ich hab mehr Funktionalität die ich die ich 1246 01:00:20,400 --> 01:00:22,560 habe übrigens ist voll rückwärtskompatibel auf Miversum 1247 01:00:22,560 --> 01:00:23,760 3. Das bedeutet, wenn ich jetzt 1248 01:00:23,760 --> 01:00:26,680 schon eine Installation habe wo alle 3 sprechen, kann ich 1249 01:00:26,680 --> 01:00:30,480 trotzdem versum 5 dazu tun, denn es funktioniert immer noch und 1250 01:00:30,480 --> 01:00:33,800 für neue Applikationen, weil ich hab hier echt viele neue 1251 01:00:33,800 --> 01:00:36,960 Funktionalität drin, die. Die gebraucht werden. 1252 01:00:36,960 --> 01:00:39,520 Also da haben wir auch gesehen, also auch wir noch andere 1253 01:00:39,840 --> 01:00:45,000 Hersteller, dass wenn du also Funktionalität, die abgeht in 1254 01:00:45,000 --> 01:00:47,360 der Version, die du aber kommerziell nutzen möchtest, in 1255 01:00:47,360 --> 01:00:49,920 vielen Fällen, ich geb dir nur ein Beispiel, es gibt einfach 1256 01:00:50,000 --> 01:00:53,120 das nennt sich Share Subsruptions, das bedeutet, ich 1257 01:00:53,120 --> 01:00:56,400 kann sag ich mal, es ist eigentlich wie wie wie, wie 1258 01:00:56,400 --> 01:00:59,040 Kafka das zum Beispiel macht mit mit Topics, das heißt, ich kann, 1259 01:00:59,040 --> 01:01:01,360 kann es aufsplitten, man kann es auch teilen, also mit Kafka 1260 01:01:01,360 --> 01:01:04,360 nennen, des Consumer Groups. Bei MQD Shares uscriptions, das 1261 01:01:04,360 --> 01:01:06,440 heißt, wenn ich so einen ganz dicken Kanal habe, wo ganz 1262 01:01:06,440 --> 01:01:09,440 Hochfrequenz Daten rausgepumpt werden und ich habe zum Beispiel 1263 01:01:09,440 --> 01:01:12,400 ein Backend und möchte eskalieren, dann brauche ich 1264 01:01:12,400 --> 01:01:16,320 einen Weg, dass ich sage mal diesen Datenstrom aufteile und 1265 01:01:16,320 --> 01:01:17,760 MQDD 3. Kann das nicht. 1266 01:01:18,480 --> 01:01:20,880 Also wenn du ein Produkt hast wie hifin Q wir supporten ist 1267 01:01:20,880 --> 01:01:23,560 auch für Version 3, also kannst du es trotzdem nutzen, aber das 1268 01:01:23,560 --> 01:01:26,160 ist nicht im Standard, das heißt das ist am Ende ein populäres 1269 01:01:26,160 --> 01:01:29,520 Feature von uns. Und mit Version 5 jeder 1270 01:01:29,520 --> 01:01:31,920 endgültige 5. Broker Open Source, kommerziell 1271 01:01:31,920 --> 01:01:34,840 wie auch immer, musst es unterstützen und dementsprechend 1272 01:01:34,840 --> 01:01:36,480 kriegst du genau diese Features umsonst. 1273 01:01:36,480 --> 01:01:39,440 Also es gibt eigentlich keinen Nachteil auf 5 zu gehen, weil du 1274 01:01:39,440 --> 01:01:41,240 du musst diese Features ja nicht nutzen, aber du hast die 1275 01:01:41,240 --> 01:01:45,200 Optionalität, deshalb würde ich empfehlen für neue Sachen auf 5 1276 01:01:45,200 --> 01:01:46,680 gehen. Ich würde aber nicht 1277 01:01:47,280 --> 01:01:49,600 Produktionssysteme anfassen und wenn du jetzt keins diese 1278 01:01:49,600 --> 01:01:53,520 Funktionalität benötigst, danke. Alles klar, so Gerrit jetzt. 1279 01:01:53,880 --> 01:01:56,240 Hab ich alle meine meine mir auf dem Herzen brennenden Fragen 1280 01:01:56,240 --> 01:01:58,560 rausgeschossen? Ja, jederzeit. 1281 01:01:58,560 --> 01:02:01,040 Noch kommt noch was nachher rein, ne. 1282 01:02:01,040 --> 01:02:02,600 Genau es. Es passt ja ganz. 1283 01:02:02,600 --> 01:02:05,760 Gut ins Thema genau, ich wollte dich mal Fragen, Dominik wie 1284 01:02:05,840 --> 01:02:10,400 MQTT organisiert ist ne und du hast 1999 glaub ich als 1285 01:02:11,200 --> 01:02:14,200 Grundsteinlegung nenn ich es jetzt mal oder Erfindungsjahr 1286 01:02:14,200 --> 01:02:18,240 für MQTT genannt und du hast gesagt du bist auch aktiv im 1287 01:02:18,240 --> 01:02:22,240 Standardisierungskomitee wie ist das organisiert? 1288 01:02:22,800 --> 01:02:25,760 Wer beteiligt sich da und und wie werden vielleicht auch 1289 01:02:25,760 --> 01:02:27,360 Entscheidungen getroffen? Ja, genau. 1290 01:02:27,520 --> 01:02:30,480 Organisiert ist es als offener Standard, also ähnlich. 1291 01:02:30,480 --> 01:02:33,320 Wie ist es bei wie man es erwarten würde, ist ähnlich, wie 1292 01:02:33,320 --> 01:02:37,480 es zum Beispiel HTP ist, es bei W 3 C organisiert endgültig, die 1293 01:02:37,480 --> 01:02:41,320 ist bei bei Oasis organisiert. BPMN glaube ich ist hier zum 1294 01:02:41,320 --> 01:02:43,760 Beispiel auch standardisiert, du hast ganz viele andere 1295 01:02:43,760 --> 01:02:46,920 Kommunikationsprotokolle, die sind bei bei Oasis, das nennt 1296 01:02:46,920 --> 01:02:49,360 sich Governing Buddy. Und die kümmern sich eben auch 1297 01:02:49,360 --> 01:02:52,000 darum, dass eben auch alle Hersteller, dass es zum Beispiel 1298 01:02:52,000 --> 01:02:54,640 so Sachen wie Patentrecht zum Beispiel auch passt. 1299 01:02:54,880 --> 01:02:57,160 Das bedeutet, dass jetzt niemand hergeht und zum Beispiel Sachen 1300 01:02:57,160 --> 01:03:00,800 über MQTD patentiert und dann an alle User hingeht und sagt, ja, 1301 01:03:00,800 --> 01:03:03,480 Moment hier, wir wollen jetzt aber Entschädigung oder 1302 01:03:03,480 --> 01:03:06,400 Lizenzgebühren haben und so, und deshalb ist es auch wichtig, 1303 01:03:06,400 --> 01:03:08,560 weil ein Standard aus meiner Sicht ist kein Standard, wenn du 1304 01:03:08,560 --> 01:03:11,440 genau diesen governing Boarding nicht hast, weil bloß als Open 1305 01:03:11,440 --> 01:03:13,560 Source ist. Heißt es ja nicht, dass das 1306 01:03:13,560 --> 01:03:15,120 nicht passieren kann. Das ist zum Beispiel auch der 1307 01:03:15,120 --> 01:03:17,680 Unterschied zu so Open Source Software wie Kafka, Kafka als 1308 01:03:17,680 --> 01:03:20,400 Beispiel ist ja immer, als Open wird es immer genannt, hat aber 1309 01:03:20,400 --> 01:03:23,840 keinen governing Body, das heißt es könnten jederzeit, könnte, 1310 01:03:23,840 --> 01:03:26,480 könnte die Firma die eben sag ich mal hauptkontribute ist 1311 01:03:26,640 --> 01:03:29,600 könnte sag ich mal Änderung auch vornehmen, Kafka ist das echt 1312 01:03:29,600 --> 01:03:32,240 bei Apache, das ist ähnlich, aber aber zum Beispiel nicht so 1313 01:03:32,240 --> 01:03:35,240 stark wie Oasis, weil ja Apache ist zum Beispiel deutlich mehr 1314 01:03:35,240 --> 01:03:39,200 auf Code Ebene währenddessen. Oasis ist wirklich komplett für 1315 01:03:39,200 --> 01:03:41,520 Spezifikationen gedacht, das heißt, es sind auch die 1316 01:03:41,520 --> 01:03:44,960 Maßnahmen und auch im Endeffekt die ganzen Lidl Strukturen 1317 01:03:44,960 --> 01:03:48,960 drumherum sind dafür gebaut. Im Endeffekt Leute die die noch 1318 01:03:48,960 --> 01:03:51,880 nie in in Gremien gearbeitet haben, es ist langweilig und 1319 01:03:51,880 --> 01:03:56,640 träge uns uns so zu nennen jetzt tatsächlich ist es so du du hast 1320 01:03:56,640 --> 01:04:01,040 hier Vertreter von vielen Firmen Masse wir waren die einzige 1321 01:04:01,040 --> 01:04:05,080 deutsche Firma 2014 die eben damit gearbeitet hat, da war 1322 01:04:05,080 --> 01:04:06,720 noch so viel mit Cisco war dabei. 1323 01:04:07,040 --> 01:04:11,240 IBM war dabei und IBM war damals der Haupttreiber für MQTV, also 1324 01:04:11,240 --> 01:04:13,320 5. In 2018 hat es ne andere Firma 1325 01:04:13,320 --> 01:04:16,320 wie Microsoft noch dazu bekommen, nachdem die sich dann 1326 01:04:16,320 --> 01:04:19,440 weitestgehend von IMQP verabschieden, verabschieden 1327 01:04:19,440 --> 01:04:22,160 wollten und in Richtung MQT auch dann gegangen sind. 1328 01:04:22,160 --> 01:04:25,520 Das heißt du hast dann da mehr Leute am Tisch und genau dann 1329 01:04:25,520 --> 01:04:29,840 ist es so wie man es ganz langweilige Meetings Leute 1330 01:04:29,840 --> 01:04:32,800 machen, Vorschläge wird bearbeitet, wird ne 1331 01:04:32,800 --> 01:04:35,120 Spezialisierung geschrieben wird, review wird diskutiert. 1332 01:04:35,360 --> 01:04:37,560 Und irgendwann bist du n Punkt, wo es dann einfach final ist. 1333 01:04:37,560 --> 01:04:41,960 Und es dauert normalerweise Jahre und dann das Schöne ist 1334 01:04:41,960 --> 01:04:45,680 aber dann, wenn du also MQTT ist nicht nur n Oasis Standard, die 1335 01:04:45,680 --> 01:04:47,280 meisten werden davon wahrscheinlich noch nie gehört 1336 01:04:47,280 --> 01:04:51,120 haben von Oasis, es ist aber auch n ISO Standard und das ist 1337 01:04:51,120 --> 01:04:53,200 das ist tatsächlich sehr wichtig, weil konkret in 1338 01:04:53,200 --> 01:04:58,240 Deutschland ist es ja so, dass ISO wird sehr, also es ist sehr 1339 01:04:58,240 --> 01:05:01,840 wichtig für viele, dass eben das auch hier unter unterm 1340 01:05:01,840 --> 01:05:04,240 Bekanntenkomitee auch ist und von daher. 1341 01:05:04,720 --> 01:05:08,080 Wenn du Oasis n neuen Standard Rausbringt für MQT ist es auch 1342 01:05:08,080 --> 01:05:11,920 automatisch n ISO zertifizierter Standard und Kontributionen. 1343 01:05:11,920 --> 01:05:13,760 Jetzt zum zur wirklichen Technik. 1344 01:05:13,760 --> 01:05:15,880 Du hast ja gerade gesagt, zum Beispiel bei bei der Version 5 1345 01:05:15,880 --> 01:05:19,680 gibt es neue Features, die kann theoretisch jeder machen oder 1346 01:05:19,760 --> 01:05:22,640 auch nur n begrenzter Kreis wie läuft das also? 1347 01:05:22,640 --> 01:05:25,680 Ja, also im Großen und Ganzen. Jeder kann die Vorschläge 1348 01:05:25,680 --> 01:05:27,960 machen, es war auch offen, also es war auch wirklich n Community 1349 01:05:27,960 --> 01:05:31,760 afford und da wurde ganz ganz viel gesammelt von Herstellern, 1350 01:05:31,760 --> 01:05:33,520 von Endnutzern, ganz vielen auch die. 1351 01:05:34,240 --> 01:05:35,880 Und dann so ein bisschen zu gucken, OK, was sind denn so 1352 01:05:35,880 --> 01:05:38,880 auch die die Patterns und das Problem, dass eben viele 1353 01:05:38,880 --> 01:05:42,960 Standards haben ist, dass dass die immer aufgeblähter werden 1354 01:05:43,360 --> 01:05:46,320 und immer komplexer werden und und das ist auch so tatsächlich, 1355 01:05:46,320 --> 01:05:49,440 das ist, auch wenn ich jetzt mir aktuelle HTTP version angucke, 1356 01:05:50,000 --> 01:05:54,800 es ist wahnsinnig flexibel, ich kann total viel machen, aber es 1357 01:05:54,800 --> 01:05:58,280 bringt dir ja nichts, wenn die Bibliotheken nicht alle Features 1358 01:05:58,280 --> 01:06:00,960 supporten, weil am besten ist es, du hast einen Standard, der 1359 01:06:00,960 --> 01:06:03,520 einfach ist, aber dafür ist es komplett introperabel. 1360 01:06:03,920 --> 01:06:06,240 Weil die Idee hinter Standards ist ja, dass du 100% 1361 01:06:06,240 --> 01:06:09,040 Interoperabel bist von der Programmiersprache, von der 1362 01:06:09,040 --> 01:06:11,680 Plattform und halt auch von den Herstellern. 1363 01:06:11,680 --> 01:06:14,520 Das heißt, dass du als Nutzer, als Programmierer oder Software 1364 01:06:14,520 --> 01:06:17,440 Developer, dass du in hier in kein Risiko reingehst, dass du 1365 01:06:17,440 --> 01:06:19,640 in irgendein Login reingehst entweder Plattform oder wenn du 1366 01:06:19,640 --> 01:06:22,480 Login oder oder oder auch selbst bei den Programmiersprachen, es 1367 01:06:22,480 --> 01:06:23,760 wäre zum Beispiel ziemlich fatal. 1368 01:06:23,800 --> 01:06:26,080 Es ist das Problem, dass zum Beispiel Java Messaging Service 1369 01:06:26,080 --> 01:06:29,720 hat, na ja, es ist halt für Java, ist es doof, moderne 1370 01:06:29,720 --> 01:06:32,000 Standards. Sind normalerweise Agnostisch 1371 01:06:32,000 --> 01:06:34,440 gegenüber Programmiersprachen. Ob es Linux, Windows, irgendwas 1372 01:06:34,440 --> 01:06:36,560 anderes ist. Also Plattform ist aber auch 1373 01:06:36,560 --> 01:06:39,920 Agnostisch gegenüber den Herstellern und von daher ist es 1374 01:06:39,920 --> 01:06:44,120 schon so, dass bei NQET konkret wird drauf geachtet, hey, wir 1375 01:06:44,120 --> 01:06:48,680 wollen unter keinen Umständen zu viel aufgebläht haben, es war 1376 01:06:48,680 --> 01:06:52,080 wirklich das Minimum Set und und dann haben wir es so flexibel 1377 01:06:52,080 --> 01:06:55,200 gestaltet, dass sag ich mal diese Special Interest Features. 1378 01:06:55,760 --> 01:06:58,320 Sehr einfach und top gebaut werden können dann kommerziell, 1379 01:06:58,320 --> 01:06:59,840 damit es dann später wieder zurückgehen kann. 1380 01:06:59,840 --> 01:07:01,960 Also das ist die Philosophie, es ist im Endeffekt ist eine Unix 1381 01:07:01,960 --> 01:07:04,720 Philosophie, Mach ein Ding und mach es richtig gut, ähnlich wie 1382 01:07:04,720 --> 01:07:07,240 TCP und deshalb bau ich es auch darauf auf die anderen Bausteine 1383 01:07:07,520 --> 01:07:09,200 und ich glaube wir waren sehr erfolgreich damit. 1384 01:07:09,440 --> 01:07:14,080 WSN 5 hat deutlich mehr Funktionalität währenddessen WSN 1385 01:07:14,080 --> 01:07:17,520 3 ist definitiv das absolute Minimum Set also es wäre sehr 1386 01:07:17,520 --> 01:07:19,560 schwierig irgendeine Funktionalität wegzunehmen, also 1387 01:07:19,560 --> 01:07:21,760 da ist aus meiner Sicht nichts drauf was aufgebläht ist. 1388 01:07:22,480 --> 01:07:24,080 OK dann würde. Ich sagen, kommen wir so langsam 1389 01:07:24,080 --> 01:07:27,240 Richtung Ende. In Anbetracht der Zeit, ich würd 1390 01:07:27,240 --> 01:07:30,640 aber noch dir die Gelegenheit geben, Dominik noch ja sag noch 1391 01:07:30,640 --> 01:07:32,720 mal, haben wir was vergessen heute, was du Dominik noch 1392 01:07:32,720 --> 01:07:36,560 loswerden möchtest? Zum Thema MQTTHIMQ the Community 1393 01:07:36,560 --> 01:07:38,760 oder irgendwie n Aufruf? Glaube nicht, also ich find es. 1394 01:07:38,760 --> 01:07:40,560 Find es sehr gut. Also wir sind tatsächlich auch 1395 01:07:40,560 --> 01:07:43,800 sehr tief in ne Technik rein reingegangen und ich glaube wenn 1396 01:07:43,800 --> 01:07:47,360 es da Zuhörerinnen und Zuhörer das spannend finden und sagen, 1397 01:07:47,360 --> 01:07:50,120 Hey ich möchte noch tiefer reingehen oder ich möchte 1398 01:07:50,120 --> 01:07:52,160 vielleicht auch Bilder sehen, was ich jetzt hier die Bilder, 1399 01:07:52,160 --> 01:07:54,520 die jetzt verbal gemalt wurden, ich möchte die auch sehen und so 1400 01:07:54,520 --> 01:07:57,120 weiter. Es gibt auch viele Ressourcen, 1401 01:07:57,120 --> 01:08:00,400 die, die wir auch gemacht haben, die ich auch persönlich gemacht 1402 01:08:00,400 --> 01:08:01,840 hab. Die hab ich in erster Linie für 1403 01:08:01,840 --> 01:08:04,320 mich selber aufgemacht, weil ich vergesse es ja häufig Sachen so, 1404 01:08:04,320 --> 01:08:07,600 dass ich die auch griffbereit habe für Leute, die gerne lesen, 1405 01:08:08,400 --> 01:08:11,920 gibt es, ich sag mal NPDF, aber auch als Blogpostser, das nennen 1406 01:08:11,920 --> 01:08:16,359 sich MQDC Essentials, das ist auf hivingcube.com zu finden und 1407 01:08:16,359 --> 01:08:19,359 ist auch immer noch unsere beliebteste Blogserie 1408 01:08:19,359 --> 01:08:22,520 tatsächlich, also die wird wahnsinnig viel gelesen, wird 1409 01:08:22,520 --> 01:08:24,080 auch in Universitäten eingesetzt. 1410 01:08:24,319 --> 01:08:26,319 Um eben das Thema MQDT auch näher zu bringen. 1411 01:08:27,040 --> 01:08:29,200 Mittlerweile gibt es auch seit einigen Jahren dazu Video 1412 01:08:29,200 --> 01:08:31,680 Content, das heißt auf Youtube findet man eben auch einfach 1413 01:08:31,680 --> 01:08:35,040 nach MQDT Essentials suchen, da gibt es dann ne zehnteilige 1414 01:08:35,040 --> 01:08:38,080 Videoserie, die dann wirklich auf alle Details, alle Features 1415 01:08:38,080 --> 01:08:39,800 alles abbildet und dann auch erklärt, warum sollten wir es 1416 01:08:39,800 --> 01:08:41,600 eigentlich einsetzen, also was ist denn der Vorteil? 1417 01:08:41,760 --> 01:08:44,800 Als Entwickler kann ich. Sehr empfehlen hab ich auch 1418 01:08:45,279 --> 01:08:47,160 gelesen. Ich weiß nicht ob ich jedes 1419 01:08:47,160 --> 01:08:50,240 Video gesehen hab, aber und auch selbst für Leute die MQDT schon 1420 01:08:50,240 --> 01:08:53,040 n bisschen benutzt haben kann man ruhig noch mal lesen. 1421 01:08:53,279 --> 01:08:55,640 Da stecken, da stecken alle Details drin, die man wissen 1422 01:08:55,640 --> 01:08:56,800 muss. Ja, manchmal hat man ja noch 1423 01:08:56,800 --> 01:08:58,800 noch ne Erkenntnis. Genau und ansonsten? 1424 01:08:58,800 --> 01:09:01,359 Wenn wenn Leute spannend finden, was wir besprochen haben. 1425 01:09:01,359 --> 01:09:04,439 Ich bin auch auf linkedin zu finden, mein Name ist Dominik 1426 01:09:04,439 --> 01:09:07,120 Obermeier, also es sollte relativ einfach zu finden sein 1427 01:09:07,520 --> 01:09:09,920 und ich freu mich über jede Verbindung und auch über alle 1428 01:09:09,920 --> 01:09:14,240 Gespräche zum Thema, auch ja endgültige und und auch IT 1429 01:09:14,240 --> 01:09:17,800 Architektur cool. Perfekte letzte Worte muss ich 1430 01:09:17,800 --> 01:09:20,800 gar nichts mehr sagen. Vielen herzlichen Dank, dass du 1431 01:09:20,800 --> 01:09:23,920 hier warst, uns diese Einblicke gegeben hast und euch weiterhin 1432 01:09:23,920 --> 01:09:27,200 alles gute und viel Erfolg auch mit mit Hifem Q, danke dir cool, 1433 01:09:27,279 --> 01:09:29,279 danke euch wünsche ich dir. Auch. 1434 01:09:29,279 --> 01:09:31,319 Dominik, vielen Dank war richtig spannend. 1435 01:09:31,319 --> 01:09:33,920 Die Folge, danke Tschüss. Tschüss aus Hamburg. 1436 01:09:35,040 --> 01:09:37,120 Einfach komplex wird. Präsentiert und produziert von 1437 01:09:37,120 --> 01:09:39,040 Heiseware. Wir freuen uns auf deine Fragen 1438 01:09:39,040 --> 01:09:41,680 und deinfeedbackanpodcast@heiseware.com 1439 01:09:41,840 --> 01:09:44,399 vielen Dank fürs Hören dieser Folge bis Dienstag in 2 Wochen 1440 01:09:44,399 --> 01:09:45,520 und Tschüss aus Hamburg.