Ein Serverless MQTT Broker liefert Ihnen einen funktionierenden MQTT-Endpunkt, Zugangsdaten und ein Dashboard, ohne dass Sie auch nur einen Server bereitstellen, denn Ihr Broker läuft auf einem gemeinsam genutzten, mandantenfähigen Cluster des Anbieters. In diesem Leitfaden erfahren Sie, wie das Serverless-Modell intern funktioniert, welche Nutzungslimits wirklich zählen, für welche Workloads es sich eignet und wie Sie Schritt für Schritt einen kostenlosen Serverless Broker bei ConnectMQ erstellen und testen.
Was „Serverless“ bei einem MQTT Broker bedeutet
Natürlich sind trotzdem Server im Spiel. „Serverless“ beschreibt, wem sie gehören und wie Sie sie nutzen. Bei einem selbst gehosteten Broker wie Mosquitto auf einer virtuellen Maschine wählen Sie die Maschinengröße, installieren Pakete, öffnen Firewall-Ports, erneuern TLS-Zertifikate und patchen das Betriebssystem. Bei einem Serverless MQTT Broker ist all das Aufgabe des Anbieters. Sie erhalten Hostname, Ports, Benutzernamen, Passwort und Client ID und beginnen mit dem Publizieren.
Die Kernidee ist Mandantenfähigkeit. Ein gut dimensionierter Broker-Cluster bedient viele Kunden gleichzeitig. Jeder Kunde erhält auf diesem Cluster einen logisch isolierten „Broker“: eigene Zugangsdaten, einen eigenen Topic-Raum und eigene Kontingente. Weil die Kapazität gebündelt wird, kann der Anbieter eine kleine Stufe kostenlos oder sehr günstig anbieten, und Sie zahlen nie für eine ungenutzte virtuelle Maschine mit 2 % CPU-Last.
Wenn Sie die Rolle des Brokers selbst auffrischen möchten, lesen Sie zuerst, was ein MQTT Broker macht.
So funktioniert die Mandantenisolation
Ein gemeinsamer Cluster ist nur sicher, wenn Mandanten einander weder sehen noch stören können. Ein gut konzipierter Serverless Broker setzt Isolation auf mehreren Ebenen durch:
- Authentifizierung. Jede Verbindung legt Zugangsdaten vor, die genau einem Mandanten zugeteilt sind. Client IDs sind dabei an die ausgegebenen Zugangsdaten gebunden, sodass kein anderer Mandant sich als Ihre Geräte ausgeben kann.
- Topic-Namensräume. Ihre Topics sind auf Ihren Broker beschränkt, sodass ein Abonnement auf
#immer nur Ihren eigenen Datenverkehr liefert. - Kontingente. Anzahl der Verbindungen, Nachrichtengröße und QoS-Stufe werden pro Plan durchgesetzt, damit kein Mandant gemeinsame Ressourcen erschöpfen kann.
- Missbrauchsschutz. Flood-Schutz und IP-Sperren nach wiederholten fehlgeschlagenen Anmeldungen verhindern, dass ein fehlerhafter Client den Cluster für alle beeinträchtigt.
Wird ein Kontingent erreicht, erhält ein MQTT-5-Client einen aussagekräftigen Reason Code (zum Beispiel 0x97, Quota exceeded) statt eines stillen Verwerfens. So lassen sich Limits nachvollziehbar debuggen, statt rätselhaft zu bleiben.
Serverless vs. Dedicated vs. selbst gehostet
Die Serverless-Stufe ist eine von mehreren Möglichkeiten, einen verwalteten MQTT-Broker zu nutzen. Die Tabelle vergleicht die gängigen Optionen.
| Aspekt | Selbst gehostet | Serverless (gemeinsam) | Dedicated (isoliert) |
|---|---|---|---|
| Wer betreibt die Server | Sie | Anbieter | Anbieter |
| Zeit bis zur ersten Nachricht | Stunden bis Tage | Minuten | Bereitstellungsschritt |
| Kapazität | So, wie Sie dimensionieren | Gebündelt, Plan-Kontingente | Für Sie reserviert |
| Störende Nachbarn | Keine | Durch Kontingente abgefedert | Keine |
| Kosten im Leerlauf | Volle VM-Kosten | Kostenlos oder gering | Reservierte Kapazität |
| Am besten für | Volle Kontrolle, abgeschottete Standorte | Prototypen, kleine Flotten, Lehre, frühe Produkte | Produktive Flotten mit gleichmäßiger Last |
Der ehrliche Kompromiss: Serverless verzichtet auf reservierte Kapazität und etwas Konfigurierbarkeit und bietet dafür null Betriebsaufwand und nahezu keine Kosten im kleinen Maßstab. Wenn Sie garantierte Isolation und planbare Reserven brauchen, ist ein dedizierter MQTT-Broker der nächste Schritt.
Limits, die bei einem Serverless MQTT Broker zählen
Jede gemeinsam genutzte Stufe veröffentlicht Kontingente. Lesen Sie sie als Designvorgaben, nicht als Kleingedrucktes. Die Serverless-Pläne von ConnectMQ sehen so aus:
| Limit | Serverless (Free) | Serverless (Paid) |
|---|---|---|
| Gleichzeitige Verbindungen | Bis zu 25 | Bis zu 1.000 |
| Maximale QoS | 1 | 2 |
| Maximale Nachrichtengröße | 256 KB | 1 MB |
| Shared Subscriptions | Nein | Ja |
| Protokolle | MQTT 3.1.1 und 5.0 | MQTT 3.1.1 und 5.0 |
Was das in der Praxis bedeutet:
- Verbindungen sind die knappe Ressource. Jedes Gerät, jeder Dashboard-Tab und jeder Backend-Worker hält eine Verbindung. Zwanzig Sensoren plus eine Node-RED-Instanz plus zwei Browser-Dashboards ergeben bereits 23 Verbindungen. Zählen Sie nach, bevor Sie ausrollen.
- QoS 1 deckt die meiste Telemetrie ab. At-least-once-Zustellung mit idempotenten Konsumenten bewältigt fast jede Sensorlast. Wenn Sie wirklich Exactly-once-Semantik brauchen, lesen Sie MQTT-QoS-Stufen erklärt und ziehen Sie die kostenpflichtige Stufe in Betracht.
- Die Nachrichtengröße stört Telemetrie selten. Ein JSON-Messwert umfasst einige Hundert Bytes. Bei Bildern und Firmware-Blöcken spielen 256 KB eine Rolle; publizieren Sie eine URL zu einem Objektspeicher statt der Datei selbst.
- Shared Subscriptions ermöglichen horizontal skalierende Konsumenten. Wenn mehrere Backend-Worker sich einen Topic-Stream teilen sollen, brauchen Sie
$share/group/topic, verfügbar in der kostenpflichtigen Serverless-Stufe.
Workloads, die zu Serverless passen
Ein Serverless MQTT Broker eignet sich hervorragend für:
- Prototypen und Proofs of Concept. Sie kommen an einem Nachmittag von der Idee zu einer funktionierenden Kette vom Gerät bis zum Dashboard.
- Kleine produktive Flotten. Ein Gebäude mit einem Dutzend Sensoren, eine Gewächshaussteuerung oder eine kleine Installation im Einzelhandel passt bequem in die Verbindungskontingente.
- Industrie-4.0-Piloten im Mittelstand. Eine einzelne Fertigungslinie mit einem Edge-Gateway, das Maschinendaten von SPS oder OPC-UA-Servern bündelt, belegt nur wenige Verbindungen und eignet sich gut, um Energiemonitoring oder OEE-Kennzahlen zu erproben, bevor das Projekt auf weitere Hallen ausgeweitet wird.
- Unterricht und Hackathons. Jedes Team erhält einen isolierten Broker, ohne dass jemand Infrastruktur betreiben muss.
- Produkte in der Frühphase. Startups können den Markt validieren, bevor sie sich auf reservierte Kapazität festlegen. Unser Leitfaden zur Wahl eines MQTT Brokers für Startups beschreibt den Wachstumspfad.
- Entwicklungs- und Staging-Umgebungen. Selbst Teams mit einem dedizierten Produktiv-Broker halten oft einen Serverless Broker für die Entwicklung vor.
Weniger geeignet ist er, wenn Sie Tausende permanent verbundener Geräte haben, strenge Latenzvorgaben bei dauerhaft hohem Durchsatz einhalten müssen oder eine Richtlinie gemeinsam genutzte Infrastruktur verbietet.
Schritt für Schritt: einen kostenlosen ConnectMQ Serverless Broker erstellen
Schritt 1: Registrieren und Broker erstellen
Gehen Sie zu ConnectMQ, öffnen Sie das Portal, wählen Sie den Plan Serverless (Free) und erstellen Sie einen Broker. Das Portal generiert Benutzernamen, Passwort und Client ID. Bewahren Sie sie sicher auf und behandeln Sie das Passwort wie jedes andere Geheimnis.
Schritt 2: Mit dem Browser-Client testen
Das Portal enthält einen MQTT-Client im Browser und einen Live-Topic-Explorer. Abonnieren Sie test/#, publizieren Sie auf test/hello und prüfen Sie, ob die Nachricht erscheint. So verifizieren Sie die Zugangsdaten, bevor Gerätecode ins Spiel kommt.
Schritt 3: Über die Kommandozeile verbinden
Mit installierten Mosquitto-Clients verbinden Sie sich per TLS auf Port 8883:
mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_CLIENT_ID -t 'sensors/#' -v
Der Broker nutzt ein Let's-Encrypt-Zertifikat, daher genügt das CA-Bundle des Systems; eine eigene CA-Datei ist nicht nötig.
Schritt 4: Aus Python publizieren
Dieses Skript verwendet paho-mqtt 2.x mit der Callback-API Version 2 und publiziert alle fünf Sekunden einen Messwert.
import json
import random
import ssl
import time
import paho.mqtt.client as mqtt
HOST = "broker.connectmq.com"
PORT = 8883
USERNAME = "YOUR_USERNAME"
PASSWORD = "YOUR_PASSWORD"
CLIENT_ID = "YOUR_CLIENT_ID"
def on_connect(client, userdata, flags, reason_code, properties):
print(f"Connected: {reason_code}")
def on_disconnect(client, userdata, flags, reason_code, properties):
print(f"Disconnected: {reason_code}")
client = mqtt.Client(
mqtt.CallbackAPIVersion.VERSION2,
client_id=CLIENT_ID,
protocol=mqtt.MQTTv5,
)
client.username_pw_set(USERNAME, PASSWORD)
client.tls_set(cert_reqs=ssl.CERT_REQUIRED)
client.on_connect = on_connect
client.on_disconnect = on_disconnect
client.connect(HOST, PORT, keepalive=60)
client.loop_start()
try:
while True:
reading = {"temp_c": round(random.uniform(20, 25), 2), "ts": int(time.time())}
info = client.publish("sensors/room1/temperature", json.dumps(reading), qos=1)
info.wait_for_publish()
print("Published", reading)
time.sleep(5)
except KeyboardInterrupt:
pass
finally:
client.loop_stop()
client.disconnect()
Wenn Sie ohne Registrierung experimentieren möchten, nutzen Sie stattdessen den öffentlichen MQTT-Broker auf Port 1883, lassen die Zugangsdaten weg und verwenden eine beliebige, nicht leere, eindeutige Client ID sowie ein eindeutiges Topic-Präfix wie connectmq/demo/a7f3k2/.... Denken Sie daran, dass der öffentliche MQTT-Broker für alle lesbar und nur für Tests und Prototypen gedacht ist; senden Sie dort niemals echte Produktionsdaten.
Schritt 5: Nutzung im Dashboard beobachten
Das Portal-Dashboard zeigt die Aktivität Ihres Brokers, und die Geräteansicht gruppiert Clients nach ISA-95-Ebenen, wenn Ihre Topics dieser Struktur folgen. Das ist der Kern eines Unified Namespace (UNS): Die ISA-95-Hierarchie (Enterprise → Site → Area → Line → Cell) wird zur Topic-Struktur auf dem Broker, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur statt sensors/room1/temperature. Wer von Anfang an so benennt, kann später ohne Umbenennung von der Serverless-Stufe auf einen größeren Plan wachsen. Mehr dazu im Beitrag Sparkplug B und Unified Namespace. Sie können außerdem Schwellenwert-Alarmregeln definieren (zum Beispiel Temperatur über 30) und ausgelöste Alarme im Alarmprotokoll einsehen.
Designtipps, um innerhalb der Kontingente zu bleiben
- Verbindungen wiederverwenden. Ein Gateway, das zehn BLE-Sensoren zu einer MQTT-Verbindung bündelt, belegt einen Platz, nicht zehn.
- Ungenutzte Dashboards schließen. Browser-Tabs über WebSocket zählen als Verbindungen, solange sie geöffnet sind.
- Retained Messages für Zustände nutzen. Wird der letzte bekannte Wert als retained publiziert, lesen neue Subscriber den aktuellen Zustand sofort, ohne Polling.
- Ein sinnvolles Keep Alive setzen. Üblich sind 30 bis 60 Sekunden. Sehr kurze Intervalle verschwenden Datenverkehr, sehr lange verzögern die Erkennung von Verbindungsabbrüchen.
- Reason Codes auswerten. Protokollieren Sie die Reason Codes von CONNACK und DISCONNECT, damit eine Ablehnung wegen Kontingentüberschreitung klar in Ihren Logs erscheint.
- Eindeutige Client IDs verwenden. Zwei Geräte mit derselben ID werfen sich gegenseitig ständig hinaus; das ist die häufigste Ursache für „mein Client verbindet sich ständig neu“.
Über Serverless hinauswachsen
Der kostenlosen Stufe zu entwachsen, ist ein gutes Problem. Der Weg führt meist über Serverless (Free) für die Entwicklung und Serverless (Paid) für ein frühes Produkt mit bis zu 1.000 Verbindungen und Shared Subscriptions hin zu Dedicated, wenn Sie einen isolierten Cluster möchten. Da alles Standard-MQTT 3.1.1 und 5.0 spricht, bedeutet ein Stufenwechsel, Hostname und Zugangsdaten zu aktualisieren, nicht die Firmware-Logik neu zu schreiben. Für das Gesamtbild der Hosting-Optionen lesen Sie unseren Leitfaden zum Cloud-MQTT-Broker, und unter wie Sie einen IoT MQTT Broker auswählen finden Sie eine Checkliste zur Bewertung.
Starten Sie Ihren Serverless Broker bei ConnectMQ
Unter app.connectmq.com können Sie ohne Kreditkarte einen kostenlosen Serverless Broker erstellen. Wählen Sie den Plan Serverless (Free), legen Sie einen Broker an, kopieren Sie die generierten Zugangsdaten und führen Sie das Python-Skript oben aus. Innerhalb weniger Minuten publizieren Ihre Geräte über TLS, und Topic-Explorer, Dashboard und Alarmregeln helfen Ihnen beim Beobachten, während der Anbieter sich um den Cluster kümmert.
Häufig gestellte Fragen
Ist ein Serverless MQTT Broker sicher genug für den Produktivbetrieb?
Ja, für viele Workloads. Der Datenverkehr ist per TLS verschlüsselt, die Zugangsdaten gelten pro Mandant und Client IDs sind daran gebunden; wählen Sie eine Dedicated- oder BYOC-Bereitstellung, wenn Richtlinien gemeinsam genutzte Infrastruktur verbieten.
Was passiert, wenn ich das Verbindungslimit überschreite?
Der Broker lehnt die zusätzliche Verbindung ab. MQTT-5-Clients erhalten einen Reason Code wie Quota exceeded, sodass Sie ihn protokollieren und reagieren können, statt zu raten.
Kann ich MQTT-5-Funktionen in der kostenlosen Stufe nutzen?
Ja. MQTT 3.1.1 und 5.0 werden beide unterstützt, einschließlich Retained Messages, Session Expiry, Message Expiry und Topic Aliases; QoS ist auf 1 begrenzt, und Shared Subscriptions erfordern den kostenpflichtigen Serverless-Plan.
Muss ich meinen Gerätecode für ein Plan-Upgrade ändern?
In der Regel nicht. Ein Upgrade ändert die Kontingente, und ein Wechsel zu einem dedizierten Broker bedeutet typischerweise, Hostname und Zugangsdaten zu aktualisieren, während die MQTT-Logik gleich bleibt.
Ist der öffentliche MQTT-Broker dasselbe wie ein Serverless Broker?
Nein. Der öffentliche MQTT-Broker unter broker.connectmq.com akzeptiert anonyme Verbindungen, ist für Tests gedacht, und alles ist für jeden lesbar, während ein Serverless Broker Ihnen private, authentifizierte Zugangsdaten und eigene Kontingente bietet.
