MQTT-Vendor-Lock-in: So bleiben Ihre Geräte mit Standard-MQTT portabel

MQTT-Vendor-Lock-in klingt wie ein Widerspruch, denn MQTT ist ein offener OASIS-Standard. Dennoch stellen viele IoT-Teams fest, dass ein Umzug ihrer Geräte zu einem anderen Anbieter das Neuschreiben der Firmware bedeuten würde. Dieser Artikel erklärt, woher Lock-in tatsächlich kommt, welche proprietären Erweiterungen ihn verursachen, und nennt konkrete Designregeln, mit denen Ihre Geräte über jeden Standard-MQTT-3.1.1/5.0-Broker hinweg portabel bleiben.

Das Protokoll ist offen, das Umfeld nicht

MQTT selbst ist durch die OASIS-Spezifikationen MQTT 3.1.1 und 5.0 definiert, veröffentlicht auf mqtt.org. Jeder konforme Client kann mit jedem konformen Broker sprechen: Connect, Publish, Subscribe, QoS, Retained Messages, Will Messages und in MQTT 5 Properties wie Session Expiry, Message Expiry, Topic-Aliase und Response Topics.

Lock-in schleicht sich über alles rund um das Protokoll ein:

• Reservierte, plattformdefinierte Topics, die Geräte verwenden müssen.
• Proprietäre Authentifizierungsabläufe, die nur eine Plattform versteht.
• Geräte-SDKs von Herstellern, die MQTT in plattformspezifische Konzepte verpacken.
• Serverseitige Logik wie Regeln, Routen oder Transformationen in der eigenen Sprache einer Plattform.
• Plattformdienste für den Zustand wie Shadows oder Twins, auf die sich Geräte verlassen.
• Nicht standardisierte Payload-Konventionen, die nur die Tools der Plattform dekodieren können.

Jedes davon kann eine gute Funktion sein. Das Problem entsteht, wenn Ihre Firmware ohne Abstraktion davon abhängt.

Typische Ursachen für MQTT-Vendor-Lock-in

Plattformfunktionen sind nicht schlecht. AWS, Azure und andere Anbieter bieten sie an, weil sie echte Arbeit sparen. Es geht darum, ihre Nutzung zu einer bewussten Entscheidung statt zu einem Zufall zu machen und sie aus der Geräte-Firmware herauszuhalten, wo Änderungen am teuersten sind.

Sieben Regeln für portable MQTT-Systeme

1. Verantworten Sie Ihren Topic-Namespace selbst. Entwerfen Sie eine Hierarchie, die Ihr Geschäft beschreibt, etwa im ISA-95-Stil enterprise/site/area/line/cell/device. Vermeiden Sie Herstellerpräfixe in Geräte-Topics. In Industrie-4.0-Projekten ist das der Unified Namespace (UNS): Die ISA-95-Ebenen werden zur Topic-Struktur, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur, und dieser Namespace gehört Ihnen, nicht dem Anbieter. Ein UNS auf Standard-MQTT lässt sich mit jedem konformen Broker weiterbetreiben; Details zeigt der Leitfaden zu Sparkplug B und Unified Namespace.
2. Verwenden Sie Standard-Client-Bibliotheken. Paho, MQTT.js, PubSubClient, AsyncMqttClient oder ESP-MQTT funktionieren mit jedem Broker.
3. Halten Sie Verbindungseinstellungen in der Konfiguration. Host, Port, TLS-Einstellungen, Zugangsdaten und Client-ID sollten aus einer Konfigurationsdatei, dem NVS-Speicher oder dem Provisioning kommen, niemals aus im Code verstreuten Konstanten.
4. Nutzen Sie Standard-Authentifizierung. Benutzername und Passwort über TLS oder Client-Zertifikate versteht jeder ernstzunehmende Broker.
5. Bilden Sie den Zustand mit Retained Messages ab. Gemeldeter und gewünschter Zustand auf Retained Topics verhält sich überall gleich.
6. Legen Sie Integrationslogik außerhalb des Brokers an. Ein Node-RED-Flow, ein Telegraf-Agent oder ein kleiner Subscriber-Dienst verbindet sich als normaler Client mit dem Broker und kann Ihnen zu jedem Anbieter folgen.
7. Dokumentieren Sie Ihre Payload-Verträge. JSON-Schemas und Sparkplug B sind beide offen; undokumentierte Binärformate sind selbst verschuldeter Lock-in.

Beispiel: Konfigurationsgesteuerte Verbindungen

Die einfachste Technik gegen Lock-in besteht darin, Broker-Details in einer einzigen Konfigurationsdatei zu halten. Hier eine YAML-Datei und ein Python-Loader mit paho-mqtt 2.x:

# broker.yaml - um den Anbieter zu wechseln, ändern Sie diese Datei, nicht Ihren Code
host: broker.connectmq.com
port: 8883
tls: true
username: YOUR_USERNAME
password: YOUR_PASSWORD
client_id: YOUR_CLIENT_ID
topic_root: acme/plant1/packaging/line2

# pip install paho-mqtt pyyaml
import json
import ssl
import time
import yaml
import paho.mqtt.client as mqtt

with open("broker.yaml", encoding="utf-8") as f:
    cfg = yaml.safe_load(f)

root = cfg["topic_root"]


def on_connect(client, userdata, flags, reason_code, properties):
    print("Connected:", reason_code)
    client.subscribe(f"{root}/+/cmd", qos=1)


def on_message(client, userdata, msg):
    print("Command:", msg.topic, msg.payload.decode())


client = mqtt.Client(
    mqtt.CallbackAPIVersion.VERSION2,
    client_id=cfg["client_id"],
    protocol=mqtt.MQTTv5,
)
if cfg.get("username"):
    client.username_pw_set(cfg["username"], cfg.get("password"))
if cfg.get("tls"):
    client.tls_set(cert_reqs=ssl.CERT_REQUIRED)
client.on_connect = on_connect
client.on_message = on_message
client.connect(cfg["host"], cfg["port"], keepalive=60)
client.loop_start()

try:
    while True:
        reading = {"speed": 118.5, "ts": int(time.time())}
        client.publish(f"{root}/filler1/telemetry", json.dumps(reading), qos=1)
        client.publish(f"{root}/filler1/state/reported",
                       json.dumps({"mode": "running"}), qos=1, retain=True)
        time.sleep(10)
except KeyboardInterrupt:
    client.loop_stop()
    client.disconnect()

Nichts in der Anwendungslogik weiß, mit welchem Anbieter es spricht. Ein Broker-Wechsel bedeutet, fünf Zeilen YAML zu bearbeiten.

Lock-in jenseits des Geräts

Die Firmware ist der teuerste Ort für einen Lock-in, denn eine Änderung bedeutet, jedes Gerät im Feld anzufassen. Sie ist aber nicht der einzige Ort.

Backend-Consumer hängen oft vom Auslieferungsmechanismus eines Anbieters ab, etwa einem proprietären Event-Stream, den es nur auf einer Plattform gibt. Abonnieren Ihr Historian, Ihre Dashboards und Ihre Alarmierung den Broker stattdessen per MQTT, ziehen sie mit Ihnen um.

Betriebswissen ist eine leisere Form des Lock-ins. Runbooks, Alarmschwellen und Debugging-Gewohnheiten wachsen rund um eine Konsole. Wenn Sie aufschreiben, welche Signale Sie beobachten, etwa Verbindungszahlen, Nachrichtenraten und bestimmte Topics, lassen sie sich anderswo leicht nachbilden.

Kommerzielle Bedingungen zählen ebenfalls. Lange Vertragsbindungen, Kosten für ausgehenden Datenverkehr und Tarifstrukturen können einen Umzug teuer machen, selbst wenn die Technik portabel ist. Prüfen Sie sie mit derselben Sorgfalt wie das technische Design. Gerade im Mittelstand kommen Fragen der Datenhoheit hinzu: wo Maschinendaten gespeichert werden, wer darauf zugreifen kann und wie sich ein Anbieterwechsel auch unter DSGVO-Gesichtspunkten sauber vollziehen lässt.

Ein verwalteter MQTT-Broker wie ConnectMQ übernimmt die Infrastruktur für Sie, während Geräte, Consumer und Dashboards alle reines MQTT sprechen. Diese Kombination bietet Ihnen den Komfort eines Dienstes, ohne dass sich der Dienst schwer verlassen lässt.

Einen Portabilitätstest durchführen, bevor Sie ihn brauchen

Der beste Beweis für Portabilität ist, Ihren Stack tatsächlich gegen einen zweiten Broker laufen zu lassen. Ein kostenloser privater Broker oder der öffentliche MQTT-Broker genügt, solange Sie dort nur Testdaten und keine Produktionsdaten senden:

# Einen Subscriber auf den zweiten Broker richten und Ihre Testsuite erneut abspielen
mosquitto_sub -h broker.connectmq.com -p 1883 -i porttest-5d1e \
  -t "connectmq/demo/5d1e/#" -v

Setzen Sie in einer Kopie von broker.yaml den Wert topic_root auf connectmq/demo/5d1e, deaktivieren Sie TLS und Zugangsdaten für den öffentlichen MQTT-Broker und führen Sie dasselbe Programm aus. Funktioniert es unverändert, ist Ihr Gerätecode portabel. Bricht es, zeigen die Fehler genau auf den Lock-in, den Sie beseitigen müssen.

Ehrlich gegenüber jedem Anbieter, auch uns selbst

Kein verwalteter MQTT-Broker ist vollkommen neutral. ConnectMQ ist ein standardbasierter MQTT-3.1.1/5.0-Broker, und Ihre Geräte verbinden sich mit gewöhnlichen Clients und Authentifizierung per Benutzername und Passwort. Einige Komfortfunktionen des Portals, etwa das erneute Veröffentlichen von Sparkplug B in Topics unter dem Präfix connectmq/, Schwellwert-Alarme oder die ISA-95-Geräteansicht, sind spezifisch für diesen Dienst. Nutzen Sie sie gern für Betrieb und Dashboards, lassen Sie die Geräte-Firmware aber in Ihren eigenen Topic-Baum veröffentlichen, damit Sie sie anderswohin umziehen könnten. Derselbe Rat gilt für die Extras jedes anderen Anbieters.

Checkliste für einen Ausstiegsplan

Schreiben Sie dies einmal auf und prüfen Sie es jährlich:

• Wo sind Broker-Host, Port und Zugangsdaten für jeden Gerätetyp gespeichert?
• Können Geräte neue Verbindungseinstellungen aus der Ferne erhalten?
• Welche Funktionen müssten anderswo neu aufgebaut werden (Regeln, Alarme, Dashboards)?
• Welche Topics oder Payload-Formate sind anbieterspezifisch?
• Wie würden Sie alten und neuen Broker während der Migration parallel betreiben, zum Beispiel mit einer Bridge?

Der Vergleich MQTT-Broker selbst betrieben vs. verwaltet und der Artikel IoT-Plattform vs. MQTT-Broker helfen bei der Entscheidung, welche Ebene Sie tatsächlich auslagern möchten.

Auf einem standardbasierten Broker aufbauen

Wenn Ihnen Portabilität wichtig ist, starten Sie mit einem Broker, der Ihrer Firmware nicht im Weg steht. Erstellen Sie einen kostenlosen Serverless-Broker ohne Kreditkarte, führen Sie den obigen YAML-gesteuerten Client aus und behalten Sie die volle Kontrolle über Ihr Topic-Design. Für das Gesamtbild lesen Sie den Leitfaden zum Cloud-MQTT-Broker, erfahren Sie, was ein MQTT-Broker leistet, oder besuchen Sie ConnectMQ.

Häufig gestellte Fragen

Kann man bei einem offenen Protokoll wie MQTT in einen Lock-in geraten?

Ja. Das Protokoll ist portabel, aber reservierte Topics, proprietäre Authentifizierung, Hersteller-SDKs und Logik im Broker können Geräte an einen Anbieter binden.

Ist die Nutzung der Rules Engine einer Plattform immer ein Lock-in?

Sie schafft eine Abhängigkeit, was aber ein akzeptabler Kompromiss sein kann. Halten Sie solche Logik aus der Geräte-Firmware heraus, damit ein späterer Umzug nur das Backend betrifft.

Wie prüfe ich am schnellsten, ob meine Geräte portabel sind?

Richten Sie ein Testgerät allein durch Ändern seiner Konfiguration auf einen zweiten standardbasierten Broker aus. Alles, was dabei bricht, offenbart eine Abhängigkeit.

Verursacht Sparkplug B einen Vendor-Lock-in?

Nein. Sparkplug B ist eine offene Eclipse-Spezifikation, die von vielen Tools und Brokern unterstützt wird, und damit eine portable Wahl für industrielle Payloads.