Ein MQTT-Broker as a Service gibt Ihnen einen funktionierenden, abgesicherten Broker-Endpunkt, ohne dass Sie selbst einen Server installieren, patchen oder überwachen müssen. Dieser Artikel erklärt genau, welche Verantwortlichkeiten auf den Anbieter übergehen, welche bei Ihnen bleiben und wie Sie die Bausteine ergänzen, die ein Broker nicht enthält, damit Sie vor der Registrierung die richtigen Erwartungen haben.
Was „MQTT-Broker as a Service“ bedeutet
As a Service bedeutet, dass Sie den Broker als Endpunkt nutzen, nicht als Software, die Sie selbst betreiben. Sie erhalten einen Hostnamen, Ports, Zugangsdaten und ein Verwaltungsportal. Der Anbieter betreibt die Maschinen, die Broker-Software, die TLS-Zertifikate und die Betriebsprozesse dahinter. Sie verbinden Geräte und Anwendungen per Standard-MQTT, genau wie mit einem Broker, den Sie selbst hosten.
Dieser letzte Punkt ist wichtig. Da MQTT ein offener Standard ist, funktionieren dieselben Client-Bibliotheken, Firmwares und Werkzeuge, ob der Broker nun auf einem Raspberry Pi in Ihrem Büro oder in der Cloud eines Anbieters läuft. Wenn Sie neu im Protokoll sind, beginnen Sie mit was ein MQTT-Broker macht.
Die Aufteilung der Verantwortung
Die folgende Tabelle zeigt eine typische Aufteilung. Die rechte Spalte nutzt ConnectMQ als konkrete Referenz.
| Bereich | Anbieter | Sie | Wie ConnectMQ die Anbieterseite abdeckt |
|---|---|---|---|
| Server und Betriebssystem | Ja | Betreibt die Infrastruktur für Serverless und Dedicated; verwaltet sie bei BYOC in Ihrem Konto | |
| Broker-Software und Patches | Ja | Verwalteter MQTT-Broker mit MQTT 3.1.1 und 5.0 | |
| TLS-Zertifikate | Ja | Let's-Encrypt-Zertifikat auf TLS 8883 und Secure WebSocket 8084 | |
| Endpunkte und Ports | Ja | TCP 1883, TLS 8883, WebSocket 8083, Secure WebSocket 8084 (Pfad /mqtt) | |
| Ausgabe von Zugangsdaten | Ja | Sicher aufbewahren | Generierter Benutzername, Passwort und Client ID pro Broker |
| Missbrauchsschutz | Ja | Kontingente pro Plan, Flood-Schutz, IP-Sperre nach wiederholt fehlgeschlagenen Anmeldungen | |
| Mandantenisolation | Ja | Mandantenisolation in geteilten Plänen, isolierte Cluster bei Dedicated | |
| Transparenzwerkzeuge | Ja | Nutzen | Client im Browser, Live-Topic-Explorer, Dashboard, Geräteansicht, Schwellwert-Alarme |
| Geräte-Firmware und Bibliotheken | Ja | ||
| Topic-Design und Benennung | Ja | Das Portal erkennt Topics eines Unified Namespace (UNS) mit ISA-95-Struktur, wenn Sie sie verwenden | |
| Payload-Format und Validierung | Ja | Dekodiert Sparkplug B zur Ansicht und republiziert es in UNS-Topics nach ISA-95 | |
| Datenspeicherung und Historie | Ja | Nicht enthalten; Sie betreiben Ihren eigenen Subscriber und Ihre Datenbank | |
| Integrationen mit anderen Systemen | Ja | Nicht enthalten; binden Sie Werkzeuge wie Node-RED oder Telegraf als MQTT-Clients an | |
| Clientseitige Zuverlässigkeit | Ja | Reconnects, Pufferung, QoS-Wahl |
Was Sie bekommen
Keine Server zu betreiben
Sie installieren nie Mosquitto, konfigurieren keine systemd-Units, erhöhen keine Limits für Dateideskriptoren und planen keine Betriebssystem-Patches. In den Serverless-Plänen müssen Sie sich auch nie um die Dimensionierung von Maschinen kümmern; Sie wählen einen Plan mit den Limits, die Sie brauchen.
Sicherheitsvorgaben, die man kaum falsch machen kann
TLS ist ab dem ersten Tag mit einem öffentlich vertrauenswürdigen Zertifikat bereit, Zugangsdaten werden generiert statt von Hand gewählt, und Client IDs sind an die für sie ausgegebenen Zugangsdaten gebunden. Brute-Force-Anmeldeversuche führen zur IP-Sperre. Selbst betriebene Broker gehen oft ohne einige dieser Schutzmechanismen an den Start und ergänzen sie später. Unser Artikel zu Best Practices für MQTT-Sicherheit behandelt die Client-Seite derselben Geschichte.
Vorhersehbare Limits
Pläne kommen mit veröffentlichten Limits. Bei ConnectMQ erlaubt der Plan Serverless (Free) bis zu 25 Verbindungen, QoS bis 1 und Nachrichten bis 256 KB; der kostenpflichtige Serverless-Plan erlaubt bis zu 1.000 Verbindungen, QoS 2, Nachrichten bis 1 MB und Shared Subscriptions. Dedicated, BYOC und Self Managed Enterprise decken isolierte und kundenkontrollierte Bereitstellungen ab.
Werkzeuge, um zu sehen, was passiert
Ein Broker, in den Sie nicht hineinsehen können, ist schwer zu debuggen. Ein guter Dienst bietet Ihnen eine Möglichkeit, Testnachrichten zu publizieren, Live-Topics zu beobachten, zu sehen, welche Geräte verbunden sind, und benachrichtigt zu werden, wenn Werte eine Schwelle überschreiten, alles im Browser.
Was Sie nicht bekommen
Klarheit an dieser Stelle vermeidet spätere Enttäuschungen.
Ein Broker ist keine Datenbank. Er leitet Nachrichten weiter; er bewahrt keine Historie auf. Retained Messages speichern nur den letzten Wert pro Topic. Wenn Sie Diagramme über die Zeit brauchen, benötigen Sie eine Zeitreihendatenbank oder einen Historian.
Ein Broker ist keine Integrationsplattform. Manche IoT-Plattformen bündeln Regel-Engines, Webhooks und Konnektoren zu Datenbanken oder anderen Clouds. Ein reiner Broker as a Service, ConnectMQ eingeschlossen, tut das nicht. Sie bauen Integrationen, indem Sie einen Client betreiben, der abonniert und weiterleitet.
Ein Broker macht Clients nicht zuverlässig. Reconnect-Logik, lokale Pufferung, idempotente Befehle und eine sinnvolle QoS-Wahl liegen in Ihrem Code. Client-Muster finden Sie unter Hochverfügbarkeit von MQTT-Brokern.
Ein Broker entwirft nicht Ihre Topics. Ein klarer Namespace ist Ihre Aufgabe, und er entscheidet, wie einfach alles andere wird. In der Industrie hat sich dafür der UNS bewährt: Die ISA-95-Ebenen Enterprise → Site → Area → Line → Cell bilden die ersten fünf Topic-Ebenen, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/telemetry. Genau auf diese Struktur zielt der Filter acme/+/+/+/+/telemetry im folgenden Beispiel. Hintergründe liefert der Beitrag zu Sparkplug B und Unified Namespace.
Das Integrationsmuster: abonnieren und weiterleiten
Der ehrliche, portable Weg, einen Broker as a Service mit dem Rest Ihres Stacks zu verbinden, ist ein kleiner Subscriber-Prozess. Er funktioniert mit jedem Broker und lässt Ihnen die Freiheit, Datenbanken oder Anbieter später zu wechseln. Hier ist ein vollständiges Python-Beispiel, das jede Telemetrienachricht in SQLite speichert. Ersetzen Sie SQLite bei Bedarf durch PostgreSQL, InfluxDB oder eine Datei.
# store_telemetry.py - Telemetrie abonnieren und in SQLite speichern
import json
import sqlite3
import time
import paho.mqtt.client as mqtt
DB = sqlite3.connect("telemetry.db", check_same_thread=False)
DB.execute("""CREATE TABLE IF NOT EXISTS telemetry (
ts REAL, topic TEXT, payload TEXT)""")
DB.commit()
def on_connect(client, userdata, flags, reason_code, properties):
print("connected:", reason_code)
client.subscribe("acme/+/+/+/+/telemetry", qos=1)
def on_message(client, userdata, msg):
try:
payload = json.dumps(json.loads(msg.payload)) # JSON validieren
except ValueError:
print("skipping non-JSON message on", msg.topic)
return
DB.execute("INSERT INTO telemetry VALUES (?, ?, ?)",
(time.time(), msg.topic, payload))
DB.commit()
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
client_id="YOUR_CLIENT_ID", protocol=mqtt.MQTTv5)
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set()
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 8883, keepalive=60)
client.loop_forever()
Dasselbe Muster gilt für Low-Code-Werkzeuge. Node-RED verbindet sich über einen mqtt-broker-Konfigurationsknoten, Telegraf nutzt seinen MQTT-Consumer-Input, und Home Assistant nutzt seine MQTT-Integration. Jedes davon ist einfach ein weiterer MQTT-Client des Brokers.
Das richtige Service-Level wählen
| Wenn Sie Folgendes brauchen | Erwägen Sie |
|---|---|
| Lernen, Demos und schnelle Tests | Den kostenlosen öffentlichen MQTT-Broker unter broker.connectmq.com |
| Einen privaten Broker für einen Prototyp oder ein kleines Pilotprojekt | Serverless (Free) |
| Eine wachsende Flotte, QoS 2, größere Nachrichten, Shared Subscriptions | Serverless (Paid) |
| Isolation von anderen Mandanten | Dedicated |
| Den Broker in Ihrem eigenen Cloud-Konto | BYOC |
| Den Broker selbst mit Herstellersoftware zu betreiben | Self Managed Enterprise |
Wenn Sie zwischen einem Dienst und dem Eigenbetrieb abwägen, lesen Sie MQTT-Broker selbst betrieben vs. verwaltet und Hosting-Optionen für MQTT-Broker im Vergleich. Der Leitfaden zum Cloud-MQTT-Broker bietet den Überblick über das gesamte Thema.
Fragen vor der Wahl eines Anbieters
- Welche MQTT-Versionen und Transportwege werden unterstützt?
- Wie lauten die genauen Limits für Verbindungen, Nachrichtengröße und QoS in jedem Plan?
- Wie werden Zugangsdaten ausgegeben, rotiert und widerrufen?
- Wie signalisiert der Dienst Clients Kontingentüberschreitungen?
- Welche Transparenzwerkzeuge sind enthalten?
- Was ist nicht enthalten, etwa Speicherung, Regel-Engines oder Konnektoren?
- Welche Isolationsoptionen gibt es über geteilte Pläne hinaus?
- Wie lauten die SLA-Bedingungen, schriftlich?
- Wie einfach ist ein Wechsel, wenn Geräte nur einen Hostnamen und Zugangsdaten kennen?
- Wo werden die Daten verarbeitet, und wie unterstützt der Anbieter Ihre Pflichten nach DSGVO, etwa mit einem Auftragsverarbeitungsvertrag?
Testen Sie MQTT as a Service mit ConnectMQ
ConnectMQ betreibt den Broker, TLS und die Kontingente, damit Sie sich auf Geräte und Daten konzentrieren können. Registrieren Sie sich unter app.connectmq.com, erstellen Sie ohne Kreditkarte einen Broker im kostenlosen Serverless-Plan und verbinden Sie Ihren ersten Client in wenigen Minuten.
Häufig gestellte Fragen
Was umfasst ein MQTT-Broker as a Service?
Typischerweise die Broker-Software, Server, Patches, TLS-Zertifikate, Endpunkte, Zugangsdaten, Kontingente und ein Verwaltungsportal. Die Verantwortung für Geräte, Topics, Payloads und Datenspeicherung bleibt bei Ihnen.
Speichert ein verwalteter MQTT-Broker meine Daten?
Ein Broker leitet Nachrichten weiter und bewahrt nur die letzten Retained-Werte pro Topic auf. Für eine Historie betreiben Sie einen Subscriber, der Nachrichten in eine Datenbank unter Ihrer Kontrolle schreibt.
Kann ich Node-RED oder Telegraf mit einem Broker as a Service verbinden?
Ja. Sie verbinden sich als gewöhnliche MQTT-Clients mit Hostname, Port und Zugangsdaten aus dem Portal und leiten die Daten dann dorthin weiter, wo Sie sie brauchen.
Ist es schwer, von einem MQTT-Broker as a Service wegzuwechseln?
Da MQTT ein Standard ist, brauchen Geräte nur einen neuen Hostnamen und neue Zugangsdaten. Wer proprietäre Funktionen meidet, hält die Wechselkosten niedrig.
