IoT-Daten übertragen mit EMQ: MQTT Broker im Einsatz erklärt

Ihr habt eine eigene IoT-Plattform im Einsatz, bereits mehrere Geräte angebunden und erste Use Cases umgesetzt? Dann kennt ihr vermutlich auch die Herausforderungen:
Es entstehen enorme Datenmengen, die im Kostenrahmen bleiben müssen. Der Bedarf an Performance und Rechenleistung wächst – und das Thema Skalierbarkeit muss gelöst werden, ohne dass eure Teams überlastet werden.
Eine zentrale Komponente solcher Plattformen ist oft unsichtbar, aber entscheidend: der sogenannte MQTT-Broker. Viele von euch haben davon schon gehört – er steuert, welche Daten von welchen Geräten wohin fließen. Man kann ihn sich vorstellen wie eine Datendrehscheibe im Zentrum der IoT-Kommunikation.
Viele starten mit einer Open-Source-Variante – doch wenn es ernst wird, geht es plötzlich um mehr als nur Technik.
Woran erkennt ihr, dass euer Broker mehr kostet, als er bringt?
Was sind typische Fallstricke bei der Umsetzung?
Und wie könnt ihr Hardware- und Datenübertragungskosten mit einem professionellen MQTT-Broker senken?
Welche Architektur braucht es, um genau diese Konflikte zu vermeiden?
Darüber spreche ich heute mit Stefano Marmonti, EMEA Head of Sales bei EMQ Technologies – einem der weltweit führenden Anbieter für MQTT-Brokerlösungen. EMQ wird unter anderem von HPE, AWS, SoftServe, VMware und zahlreichen mittelständischen Industrie- und Infrastrukturbetreibern genutzt.
Praxisnahe Einblicke direkt aus realen Projekten – alle Infos wie immer unter www.iotusecase.com. oder in den Show Notes.
Let’s go!

Und damit hallo und herzlich willkommen im IoT Use Case Podcast – hi Stefano!
Wie geht’s dir heute?

Stefano

Servus! Mir geht’s gut. Ich bin gerade aus dem Urlaub zurück und deshalb voll motiviert.

Fantastisch! Und wo bist du gerade, also örtlich gesehen? Wo sitzt eure Firma nochmal genau?

Stefano

Ich sitze in München. Wir haben zwei Büros – eines in Erfurt und eines in Frankfurt, genauer gesagt in Eschborn. Ich bin im Homeoffice, aber eben in München.

Dann liebe Grüße und Shout-out schon mal an die Kolleginnen und Kollegen vor Ort – aber natürlich auch an die anderen Standorte.
Vielleicht starten wir mal ganz basic. Warum braucht eine IoT-Plattform überhaupt einen MQTT-Broker? Und was passiert aktuell in diesem Markt, dass es sowohl Open-Source- als auch kommerzielle Lösungen gibt?

Stefano

Einen MQTT-Broker braucht man für eine effiziente Kommunikation zwischen Endgeräten, Sensoren und Maschinen mit dem Backend. Das Backend ist heutzutage meistens die Cloud – muss es aber nicht sein. Es kann auch eine Datenbank oder ein Streaming-Service wie Kafka sein. Um Daten, die irgendwo generiert werden, nutzbar zu machen, ist MQTT ein sehr gutes Protokoll – sicher, zuverlässig und geeignet, um Daten geschützt zu transportieren.

Sehr schön. Jetzt ist es ja so, dass dieser MQTT-Broker – wie du schon gesagt hast – fast schon ein zentrales Kommunikationssystem ist. Er dient als Vermittler, um Nachrichten auszutauschen.
Wie ist das eigentlich bei den ganzen Herstellern, die eigene IoT-Plattformen betreiben?
Wo sitzt der MQTT-Broker überall, und mit welchen Systemen ist er verbunden? Verbindet er sich zum Beispiel direkt mit einem Sensor? Lass uns das Bild dieser Architektur mal gemeinsam vor Augen malen.

Stefano

Genau, das kommt natürlich auf den Use Case an.
Bleiben wir beim Beispiel Sensoren: Es gibt Sensoren, die MQTT sprechen – also MQTT-fähig sind. Die können sich direkt mit einem Broker verbinden und Nachrichten an ihn senden.
Der Broker selbst sitzt zentral – meist in einem Rechenzentrum oder in der Cloud – und leitet die Daten weiter oder speichert sie, zum Beispiel in einer Zeitseriendatenbank, um Messwerte zu archivieren.
Ebenso kann der MQTT-Broker die Sensordaten an Streaming-Services wie Kafka, an Analysesysteme oder an ERP-Systeme weitergeben, die diese Daten dann weiterverarbeiten.
Es geht also um den Transport von Daten vom Endgerät ins Backend – und natürlich auch umgekehrt. Das Ganze ist bidirektional: Ein System im Backend kann ebenfalls einen MQTT-Datenstrom an die Maschine oder den Sensor zurücksenden.

Genau. Bevor wir zu sehr in technische Details abdriften, hätte ich noch eine Frage – nennen wir es mal das „Problem-Statement“ vieler eurer Kunden.
Ihr arbeitet ja mit ganz unterschiedlichen Unternehmen – ich weiß nicht, ob wir heute einige nennen dürfen.
Was ist denn eigentlich deren Pain Point? Die Anzahl vernetzter Geräte nimmt ja ständig zu – was ist die konkrete Herausforderung, vor der eure Kunden aktuell stehen?

Stefano

Es gibt natürlich einen technischen Pain Point – nämlich: Wie kann ich Daten zuverlässig transportieren? Und es gibt ein geschäftliches Problem.
Die Gerätehersteller oder Maschinenbauer versuchen, Mehrwerte zu generieren – in der Regel über ihre IoT-Plattformen.
Damit verwalten sie ihre Geräte für ihre Kunden und bieten besseren Service – etwa durch Funktionen wie Predictive Maintenance, also die frühzeitige Erkennung möglicher Probleme. So lassen sich Sensoren und Maschinen optimieren.
Diese zusätzlichen Services spielen eine zentrale Rolle in Verbindung mit einer IoT-Plattform. Darüber können Anbieter neue oder verbesserte Dienste anbieten und so echten Mehrwert schaffen.
Das hängt natürlich immer vom Use Case ab.
Wenn man zum Beispiel in die Automobilbranche schaut – Stichwort Connected Car –, lassen sich viele neue Services generieren, wenn man auf Fahrzeugdaten zugreifen kann.

Okay. Wenn wir bei diesem Business-Problem bleiben – also erstmal bei den geschäftlichen Aspekten –, dann geht es doch auch darum, die IoT-Plattform skalierbar zu nutzen.
Du hast gerade das Thema Datennutzung erwähnt – aber wo stößt die Skalierbarkeit deiner Erfahrung nach an ihre Grenzen?
Wo fangen IT-Teams an, nach Alternativen zu suchen? Hast du ein paar typische Business-Probleme, die du hier nennen kannst?

Stefano

Auch das ist wieder Use-Case-abhängig.
Fangen wir mal mit einem einfachen Beispiel an: Smart Meter – ein typischer Use Case für MQTT. Moderne Smart Meter senden ihre Datenpakete per MQTT an den Broker.
In Europa ist das vielleicht noch nicht so verbreitet, aber wir haben Kunden in Indien, bei denen über 50 Millionen Smart Meter ausgerollt werden.
Das sind natürlich enorme Mengen an Geräten, die verwaltet werden müssen. Und da spielen Sicherheit und Skalierbarkeit eine große Rolle – denn bei 50 Millionen Geräten bleibt es nicht. Die planen mit 200 oder sogar 600 Millionen.
Die Skalierung passiert also sehr schnell, allein durch die Stückzahlen.
Bei Smart Metern sind es zwar keine großen Datenmengen, aber man kann das weiterdenken: Fahrzeugdaten, Daten von E-Bikes – diese intelligenten Fahrzeuge sind inzwischen in der Lage, mehrere Verbindungen aufzubauen und Daten zu senden, nicht nur eine.
Das erzeugt enorme Datenmengen – und dafür braucht man eine performante, stabile Backend-Infrastruktur, um das überhaupt betreiben zu können.

Okay, das heißt, ihr arbeitet vor allem mit großen Kunden – oder zumindest mit Kunden, die viele Geräte im Feld haben und anbinden möchten.
Wenn wir bei den IoT-Plattformen bleiben: Ein Beispiel war Smart Meter, aber ich könnte mir vorstellen, dass es auch viele große Automatisierer gibt, die seit Jahren eigene IoT-Plattformen betreiben – sei es, um Sensoren, Motoren oder Aktoren anzubinden.
Da sind ja teils Tausende Geräte im Einsatz.
Das ist doch euer Zielmarkt, oder habe ich das richtig verstanden?

Stefano

Genau, wir arbeiten mit vielen deutschen Maschinenbauern zusammen, die genau das tun – vor allem im Bereich Sensorik und kleineren Maschinen. Sensorik ist ein großes Thema, und diese Unternehmen wollen ihre Daten in eine leistungsfähige Backend-Infrastruktur bringen. Das ist genau das, was wir machen.

Gilt das dann eher für Maschinenbauer mit größeren Flotten?
Ist ein MQTT-Broker – und das, was ihr macht – für kleinere Unternehmen mit wenigen Geräten eher weniger relevant? Oder würdest du sagen, es gibt eine Schwelle, ab der sich das lohnt?

Stefano

Da sind wir wieder beim Thema Marktsegmentierung.
Es gibt natürlich den Open-Source-Markt – viele starten mit einer Open-Source-Broker-Lösung, bauen eine Plattform darauf auf und merken dann: Wenn sie das Ganze kommerzialisieren wollen, braucht es doch mehr – etwa in Sachen Skalierbarkeit oder Support.
Vielleicht planen sie, die Plattform global auszurollen – in verschiedenen Ländern oder Regionen – und dann wird Support ein wichtiges Thema.
Da gibt es viele Facetten.
Man kann also nicht pauschal sagen: Wer nur ein paar Geräte hat, braucht keinen Broker.
Wichtig ist, eine effiziente und sichere Kommunikation zu gewährleisten.

Viele Unternehmen haben heute eigene Teams, die sich um solche Themen kümmern – um Monitoring, Entwicklung und Rollouts.
Je nach Organisation sind das fünf bis 40 Personen oder mehr.
Würdest du sagen, es gibt da einen gewissen Kipppunkt, ab dem ein Open-Source-MQTT-Broker an seine Grenzen stößt?
Also der Moment, wo man sagt: Jetzt macht es Sinn, über eine kommerzielle MQTT-Broker-Lösung – wie die von euch – nachzudenken?

Stefano

Der Schritt von Open Source zu kommerziellen Lösungen hat in der Regel technische Gründe.
Unser Enterprise-Produkt bietet beispielsweise den Vorteil der höheren Skalierbarkeit – es basiert auf einer leicht anderen Architektur und kann mehrere hundert Millionen Geräte verwalten.
Auch das Thema Support spielt eine große Rolle.
Zusätzlich bieten wir eine umfassende Backend-Integration: Über 50 sogenannte „Out-of-the-Box“-Integrationen in bestehende Systeme – darunter Kafka, ganz neu Snowflake, SAP, SQL- und NoSQL-Datenbanken, analytische Systeme und viele mehr.
Das ist ein klarer Unterschied – denn viele Kunden entwickeln sich diese Anbindungen selbst. Sie basteln sich also eigene Konnektoren.
Das funktioniert grundsätzlich, ist aber mit erheblichem Aufwand verbunden – und genau den kann man sich mit einer kommerziellen Lösung sparen.

Was ist da der typische Fallstrick in Projekten? Gibt es Best Practices, wo du sagst: „Da macht es keinen Sinn, das selbst zu entwickeln“?
Was passiert da genau?
Kannst du erklären, was es bedeutet, sich einen eigenen Konnektor zu bauen?

Stefano

Wie gesagt: Ein Konnektor ist bei uns eine Schnittstelle vom Broker zu einem anderen System.

Also zum Beispiel: Der Smart-Meter-Sensor sendet über MQTT an einen Broker – das kann ich mir selbst bauen?

Stefano

Nein, es geht nicht nur ums Endgerät. Es geht um die Verbindung vom zentralen Broker – also von der Plattform – zu einem Fremdsystem.
Ein Fremdsystem kann zum Beispiel ein MES-System, ein Steuerungssystem oder ein ERP-System wie SAP sein.
Typischerweise sieht das so aus: Eine Maschine sendet Daten über den Broker an das ERP- oder MES-System, dort passiert etwas – und das System schickt wiederum Datenpakete zurück an die Maschine.
Diese Schnittstelle vom zentralen Broker zum Backend-System ist genau das, was wir „out of the box“ mitliefern – und was sich häufig direkt aus dem Use Case ergibt.
Viele Firmen starten mit dem Aufbau einer IoT-Plattform, die einen Broker enthält. Dann merken sie schnell, dass es viele Use Cases gibt – zum Beispiel Predictive Maintenance. Und dafür braucht man etwa eine Anbindung an ein MES-System.

Ja, genau. Nehmen wir an, ich habe einen Motor oder eine andere Komponente im Feld, die eine Verschleißgrenze erreicht.
Über meine IoT-Plattform würde das Gerät dann zum Beispiel einen Fehlerlog oder einen Alarm senden.
Im besten Fall – wenn man schon so weit ist – könnte im ERP-System automatisch ein Ticket erstellt werden, sodass der Service direkt reagieren kann.
Das meinst du mit dieser Art von Integration, oder?

Stefano

Genau.

Jetzt hattest du auch das Thema Konnektor auf der OT-Seite angesprochen. Viele Automatisierer und Hersteller kommen ja eher aus der Hardware-Ecke.
Ist es mit viel Engineering-Aufwand verbunden, OT-Geräte vernünftig anzubinden?
Ich könnte mir vorstellen, einige Geräte sprechen nativ MQTT oder lassen sich über OPC UA anbinden. Aber bei älteren Maschinen braucht man vermutlich Retrofit-Lösungen.
Wie aufwendig ist das? Und ist es auch ein Thema, sich für die OT eigene Konnektoren zu bauen, um an die Daten zu kommen?

Stefano

Genau, das ist natürlich das klassische OT-Thema.
Es gibt keine grüne Wiese – vielmehr gibt es viele bestehende Anlagen, die einfach da sind.
Wir bei EMQ bieten ein softwarebasiertes Gateway zur Konvertierung von Industrieprotokollen in MQTT-Topics an.
Das heißt: Viele Bestandsmaschinen sprechen kein MQTT – neuere Modelle schon, aber eben nicht alle.
Über unser Gateway lassen sich Protokolle wie OPC UA, PROFIBUS, PROFINET, Siemens, SIMATIC und viele weitere Industrieprotokolle in MQTT-Topics umwandeln und direkt an einen Broker senden.
Wir unterstützen damit über 80 Industrieprotokolle.
Natürlich decken wir damit nicht 100 % aller Maschinen ab – aber vermutlich rund 90 % der im Feld eingesetzten Anlagen.
So holen wir die OT-Welt ab und integrieren auch ältere Maschinen in moderne IoT-Infrastrukturen.

Ich glaube, ihr nennt das Neuron Gateway, wenn ich das richtig im Kopf habe, oder?

Stefano

Genau, das heißt NeuronEX.

Ich packe euch das übrigens in die Show Notes, falls ihr Interesse habt, euch das mal anzuschauen.
Das ist der Industrial Edge Data Hub, den EMQ anbietet – wirklich spannend.

[14:52] Herausforderungen, Potenziale und Status quo – So sieht der Use Case in der Praxis aus

Hast du Beispiele aus Projekten, bei denen sich ein echter ROI gezeigt hat oder wo für den Kunden konkret etwas auf dem Spiel stand?

Stefano

Es gibt mehrere Beispiele. Ein gutes ist ein Hersteller von Landwirtschafts-Equipment. Die bauen Regensensoren, die auf dem Feld stehen – spezielle Sensoren für die Landwirtschaft, etwa zur Steuerung von Traktoren und anderen Geräten.
Bleiben wir bei den Regensensoren: Das ist ein Gerät, das man ins Feld stellt. Es misst Regen, Temperatur und weitere Werte und sendet die Daten.
Früher haben sie das über SIM-Karten gemacht – also mit einem SIM-Kartenmodul ins Backend, wo die Daten weiterverarbeitet wurden.
In dem konkreten Fall haben sie das nun komplett umgestellt und eine neue Generation von Geräten entwickelt.
Diese senden die Daten zwar weiterhin über SIM-Karten, nutzen aber MQTT.
MQTT ist extrem effizient, und die Datenmenge so gering, dass sie sich etwa 60 % der bisherigen Telekommunikationskosten sparen – was natürlich viel Geld spart und gleichzeitig deutlich effizienter ist.

Interessant. Und warum ist die Datenmenge hier geringer?

Stefano

Weil eine Kompression stattfindet, die die Daten effizienter macht – also die Datenmenge reduziert.

Okay, Kompression. Findet die auf dem kommerziellen MQTT-Broker statt, den sie von euch nutzen – oder auf welcher Ebene genau?

Stefano

MQTT als Protokoll ist von Haus aus extrem leichtgewichtig.
Verglichen mit anderen Protokollen ist die Datenmenge, die über die Leitung geht, deutlich geringer.
MQTT ist dafür gebaut, Daten effizient und sicher zu übertragen – gerade in leichten, schlanken Formaten.
Das macht den Unterschied. Und in diesem Fall war das ein klarer Kostenfaktor.

Da wir gerade über Datenmengen sprechen – hast du vielleicht noch ein anderes Beispiel?
Das eben genannte war ja eher ein Fall, bei dem nicht ständig Daten übertragen werden müssen.
Gibt es auch Extremfälle, in denen sehr viele Daten gebraucht werden – zum Beispiel über OPC UA over MQTT?
Habt ihr solche Szenarien auch? Oder handelt es sich meistens um Daten, die in bestimmten Intervallen übertragen werden, also nicht in harter Echtzeit?

Stefano

MQTT ist kein Echtzeitprotokoll, aber es ermöglicht nahezu Echtzeitkommunikation – das ist wichtig zu verstehen.
Ein typisches Beispiel, gerade aus der OT-Welt:
In einer Fabrik werden kontinuierlich Daten gesammelt. Dort läuft ein Broker – zum Beispiel an der Edge –, der wiederum mit einem zentralen Broker kommuniziert.
Das Besondere bei MQTT ist das sogenannte „Store and Forward“-Prinzip:
Wenn die Verbindung zwischen Fabrik und Zentrale unterbrochen wird, sammelt der Edge-Broker die Daten weiterhin lokal. Sobald die Verbindung wieder steht, werden die Daten nachträglich übertragen.
Andere Protokolle können unter Umständen eine Verbindung wiederherstellen – aber MQTT hat durch dieses „Message Queuing“ einen entscheidenden Vorteil:
Daten werden zwischengespeichert und später zuverlässig weitergesendet.
Ein konkretes Beispiel: Ein Produzent hatte einen Ausfall in der Fabrik und dabei gingen sämtliche Daten verloren.
Die Wiederherstellung hat über eine Woche gedauert – und das war natürlich mit erheblichen Kosten verbunden.
Solche Szenarien lassen sich mit MQTT vermeiden.

Ja, klar – das ist nachvollziehbar.
Hast du noch weitere Kennzahlen aus euren Projekten, die das belegen?
Sorry, wenn ich da so tief nachfrage – ist ja nicht immer einfach.
Oder war das Beispiel eben euer aussagekräftigster Case?

Stefano

Das ist wieder ein technisches Thema.
Bei unserem Enterprise-Broker haben wir eine spezielle Architektur gewählt, die besonders skalierbar ist – und dabei im Vergleich zu anderen Brokern mit rund 40 % weniger Hardware betrieben werden kann.
Das ist vor allem aus Betriebssicht interessant.
Natürlich können Kunden das finanziell auch anders lösen, indem sie einfach mehr Hardware bereitstellen und so etwaige Performance-Probleme kompensieren.
Aber wir hatten einen konkreten Fall, bei dem wir ein bestehendes System analysiert und mit unserem verglichen haben. Dabei konnten wir 40 % Hardware einsparen – was natürlich direkte Betriebskosten reduziert und den Return on Investment positiv beeinflusst.

[19:51] Lösungen, Angebote und Services – Ein Blick auf die eingesetzten Technologien

Hast du zum Abschluss noch Best Practices?
Gerade wenn man ein Projekt startet – es muss ja nicht immer ein Migrationsprojekt sein – gibt es bestimmt Punkte, die man beachten sollte.
Welche Learnings oder Empfehlungen hast du über die Jahre gesammelt, die du mit der Hörerschaft teilen möchtest?

Stefano

Ein zentraler Punkt, den ich immer zuerst klären möchte:
Ich frage die Kunden, wie sie den Broker am Ende betreiben wollen.
Wir von EMQ bieten alle gängigen Deployment-Modelle an:
Man kann unseren Broker selbst installieren und auf eigener Hardware betreiben.
Man kann ihn in der eigenen Cloud laufen lassen.
Oder man nutzt unseren vollständig gemanagten Service, den wir auf allen großen Hyperscalern bereitstellen –,den man einfach konsumieren kann.
Aus Projektsicht ist es wichtig, früh zu überlegen, welches Betriebsmodell das effizienteste ist.
Manche Kunden sagen aus Sicherheitsgründen – etwa wegen ihrer internen IT-Security-Vorgaben – dass der Broker im eigenen Rechenzentrum oder in der Private Cloud laufen muss. Dann ist das so.
Es gibt aber viele Use Cases – denn ein MQTT-Broker speichert per se keine Daten.
Das heißt: Wir selbst speichern nichts. Wir leiten die Daten lediglich an ein Zielsystem weiter, wo sie dann gespeichert werden.
Genau deshalb eignet sich ein MQTT-Broker auch sehr gut als gemanagter Service in der Cloud.
Die Daten werden dabei einfach vom Gerät oder Sensor über den gemanagten Service an das gewünschte Zielsystem übertragen.

Okay, das ist sehr spannend. Nur dass ich es nicht vergesse: Das Thema OPC UA over MQTT werde ich übrigens demnächst auch im Rahmen einer Podcastfolge mit der OPC Foundation aufgreifen.
Dabei geht es um kontextualisierte Daten, auf die man über MQTT auch aus der Cloud zugreifen kann.
Das würde jetzt aber zu weit führen – ich wollte es nur kurz erwähnen.
Falls ihr den Podcast noch nicht abonniert habt: In einer kommenden Folge wird das behandelt – also gerne abonnieren!
Was ich auf jeden Fall mitgenommen habe:
MQTT ist extrem schnell und eignet sich hervorragend für alle Near-Real-Time-Use-Cases in der Industrie – aber eben auch für andere Anwendungen wie Smart Meter oder Regensensoren, wie du sie genannt hast.
Eine letzte technische Frage habe ich noch:
Was hat es mit dem Unified Namespace auf sich? Ich weiß nicht, ob du das eben schon erwähnt hast – kannst du noch einmal erklären, wie Unified Namespace mit MQTT und eurem Angebot zusammenhängt?
Das ist ja im Grunde ein zentrales, strukturiertes Datenverzeichnis – wie passt das bei euch rein?

Stefano

Ein Unified Namespace ist im Grunde ein Verzeichnis, in dem Daten bzw. sogenannte Topics strukturiert abgelegt werden.
Man kann es sich vorstellen wie ein Telefonbuch: Wenn ein Unternehmen einen Unified Namespace definiert, hält es sich an bestimmte Regeln und eine klar festgelegte Nomenklatur.
Es ist also eine Art Blueprint – kein Produkt, sondern ein Konzept.
Dabei geht es um die Definition von Topic-Strukturen, an die sich verschiedene Beteiligte – z. B. Hersteller – halten können.
So lässt sich sicherstellen, dass Geräte schnell angebunden und problemlos über MQTT kommunizieren können.
Gerade in der Industrie, insbesondere in der Fertigungsbranche, ist der Unified Namespace sehr praxisnah anwendbar.
Wenn sich Hersteller an diese Strukturen halten, wird Integration deutlich einfacher.
Es gibt dabei eine Zwischenschicht – das kann technisch etwas komplexer werden – zum Beispiel Sparkplug.
Sparkplug kann von Geräteherstellern implementiert werden, damit ihre Geräte MQTT sprechen und Nachrichten in der richtigen Struktur senden – also passend zum Unified Namespace.
Das ermöglicht eine Art Plug-and-Play-Prinzip: Ein neues Gerät, das „Sparkplug Ready“ ist, kann direkt eingebunden werden – die Kommunikation mit dem MQTT-Broker funktioniert sofort, weil die Struktur bereits klar ist.
Wir von EMQ können Sparkplug-Nachrichten übrigens dekodieren – sie haben eine etwas andere Struktur, aber wir können sie interpretieren und weiterverarbeiten.
Wichtig ist noch einmal: Der Unified Namespace ist ein Konzept, keine Software. Aber er ist eine wichtige Grundlage, damit in komplexen IIoT-Umgebungen alles reibungslos funktioniert.

Ja, verstehe. Ich packe auf jeden Fall auch noch ein paar weiterführende Links zu Sparkplug in die Show Notes.
Im Grunde ist Sparkplug ja eine Art zusätzliche Semantik, mit der man Metainformationen aus den Daten herausholen kann – die sich dann wiederum mit eurer Lösung weiterverarbeiten lassen.

Stefano

Ja.

Okay. Und was kann ich sonst noch bei euch kaufen?
Wenn ich auf eurer Website bin – ich glaube, das ist alles unter dem Punkt „Plattform“ gelistet – dann gibt es doch einerseits die EMQX-Plattform, also euren kommerziellen MQTT-Broker.
Das bedeutet, ich kaufe eine Lizenz – oder wie funktioniert das genau?

Stefano

Das hängt vom gewählten Deployment-Modell ab.
Wenn du das Produkt selbst betreiben möchtest – also als selbstgemanagte Lösung –, dann kaufst du eine klassische Lizenz.
Wenn du unseren gemanagten Service nutzt, läuft das über ein Subscription-Modell – also ein monatlicher oder jährlicher Zahlungsplan, ähnlich wie bei einem Mobilfunkvertrag.

Verstehe. Und dann gibt es bestimmte Features, die ich je nach Bedarf dazubuchen kann, oder?

Stefano

Nein, bei uns ist es so: Es gibt nur ein Produkt – mit vollständigem Funktionsumfang.
Das gilt sowohl für die selbstgemanagte Enterprise-Version als auch für den Managed Service.
Es ist technisch dasselbe Produkt – der Unterschied liegt allein im Betriebs- bzw. Deployment-Modell.
Die Entscheidung ist also: Möchte ich das Produkt selbst betreiben oder als gemanagten Service nutzen?
Aber die Funktionen sind identisch – da gibt es keine Einschränkungen.

Okay, verstehe. Dann packe ich das auch noch mal in die Show Notes.
Ihr könnt da einfach mal reinschauen – ihr findet dort die verschiedenen Betriebsmodelle, und ich glaube, auch die Preisgestaltung ist recht transparent.
Und wenn ein Kunde jetzt ein bestimmtes System integrieren will – sagen wir zum Beispiel Snowflake – wie läuft das dann ab?
Ist diese Anbindung direkt in der Plattform enthalten?

Stefano

Genau. Am Beispiel Snowflake gibt es zwei Wege:
Zum einen bieten wir SDKs – also Software Development Kits – mit denen Kunden, die das technische Know-how haben, eigene Integrationen entwickeln können.
Ein Logistikkunde von uns macht das aktuell – er hat eine spezielle Zielplattform und macht das jetzt selbst.
Zum anderen gibt es unsere Out-of-the-Box-Konnektoren. Aktuell unterstützen wir rund 45 Zielsysteme – darunter Kafka, SAP und mittlerweile auch Snowflake.
Snowflake haben wir aufgenommen, weil einer unserer größten Kunden den Wunsch geäußert hat, Daten direkt aus der Sensorik bzw. der Produktion nach Snowflake zu übertragen.
Unser Entwicklerteam in Stockholm hat diesen Konnektor daraufhin speziell entwickelt – und jetzt ist er Bestandteil unseres Core-Produkts und damit für alle Kunden verfügbar.
Wenn wir sehen, dass es für ein bestimmtes Zielsystem eine breitere Nachfrage gibt, entscheiden wir: Entweder wir entwickeln den Konnektor selbst – oder wenn ein Kunde einen konkreten Bedarf hat, setzen wir es gemeinsam um.
Snowflake ist da ein gutes Beispiel – der Konnektor ist fertiggestellt und steht jetzt allen zur Verfügung.

Spannend!
Hast du ein paar Kennzahlen für mich?
Auf eurer Website stehen ja auch einige – wie viele Nutzer ihr habt, wie viele Devices angebunden sind usw.
Kannst du ein bisschen was dazu sagen – wie groß ist eure Community aktuell?

Stefano

Ja, wir haben inzwischen mehrere hundert Millionen angebundene Geräte.
Unsere Open-Source-Software – ebenso wie die Enterprise-Version – wurde inzwischen fast 25 Millionen Mal heruntergeladen.
Wir können nicht zu allen Kunden öffentlich sprechen – viele große Unternehmen nutzen unsere Open-Source-Version produktiv, wollen aber aus verschiedenen Gründen nicht genannt werden.
Ein Beispiel: Wir haben kürzlich mit einem indischen Social-Media-Anbieter gesprochen – die betreiben ihre Plattform mit rund 45 Millionen Nutzer, die über unsere Software kommunizieren.
Das zeigt, wie vielseitig unser Produkt einsetzbar ist – auch wenn wir nicht immer präzise Zahlen nennen dürfen.
Aber klar ist: Wir haben Millionen von Nutzern – verteilt auf Open Source und kommerzielle Lösungen.

[28:55] Übertragbarkeit, Skalierung und nächste Schritte – So könnt ihr diesen Use Case nutzen

Was kommt denn in Zukunft noch von euch?
Ich weiß, ihr beschäftigt euch auch mit AI-getriebenen Use Cases – Stichwort MCP over MQTT.
Kannst du uns da mal mitnehmen? Was bewegt aktuell die Szene, den Markt?
Und worauf dürfen wir uns in den nächsten Monaten oder Jahren von eurer Seite freuen?

Stefano

Ein großes Thema ist natürlich Künstliche Intelligenz – AI.
Wir arbeiten aktuell daran, unsere Produkte so weiterzuentwickeln, dass sie Zielsysteme unterstützen, bei denen Daten über den Broker direkt an KI-Modelle weitergegeben werden können.
Wir haben bereits erste Funktionen im Produkt, mit denen Entwickler sogar direkt mit einer KI kommunizieren können – etwa beim Entwickeln von Code innerhalb unserer Plattform.
Die KI hilft dann, Code zu generieren – das ist technisch bereits möglich.
In diese Richtung wird noch viel passieren. Nicht alles ist schon da, aber es kommt einiges, was bestehende Abläufe optimieren und verbessern wird.
Das zweite große Thema aus meiner Sicht sind Datenpipelines – also direkte, dauerhafte Verbindungen, über die permanent Daten gesendet werden können.
Man kann sich das wie eine Ölpipeline vorstellen: Feste Datenströme, die kontinuierlich laufen.
Hier sehen wir noch viel Potenzial und haben auch Ideen, wie man das künftig noch effizienter gestalten kann – auch mit MQTT, aber nicht ausschließlich.

Okay, kurze Nachfrage:
Warum denkst du, dass das Thema Datenpipelines so wichtig wird?
Was bewegt den Markt gerade in diesem Bereich?

Stefano

Das geht klar in Richtung Echtzeitkommunikation – oder zumindest in Richtung Near-Real-Time.

Super spannend!
Das schreit fast schon nach einer eigenen Podcastfolge in Zukunft – da könnten wir bestimmt noch mal im Detail drüber sprechen.
Ich fand es auf jeden Fall sehr spannend – vor allem, dass du das alles so praxisnah erklärt hast und den Business Case aus Kundensicht beleuchtet hast.
Ein Aufruf an die Community: Schaut euch das Thema unbedingt mal an – insbesondere MQTT als Managed Service oder auch in anderen Betriebsmodellen.
Ich verlinke euch alles Wichtige in den Show Notes – da könnt ihr euch einen guten Überblick verschaffen, was EMQ genau anbietet.
Und damit würde ich sagen: Danke von meiner Seite – und ich überlasse dir gern das letzte Wort.

Stefano

Ich kann der Community nur empfehlen: Schaut euch an, was wir machen.
Es gibt viele spannende Themen und zahlreiche Use Cases, die sich mit MQTT besser, eleganter und schneller umsetzen lassen.
Heute haben wir nur einen kleinen Ausschnitt davon beleuchtet – das Feld reicht weit darüber hinaus: Transport, Logistik, öffentlicher Sektor – alles extrem spannende Bereiche.
Ich bin überzeugt, das Thema wird uns noch lange begleiten – und ich hoffe, wir können bald nochmal einen Podcast dazu machen.

Sehr gerne! Danke dir, Stefano – und dir noch eine schöne Restwoche.
Mach’s gut, ciao!

Stefano

Danke, tschüss.