MQTT-Broker-Ausschreibung: Checkliste zur Bewertung von Anbietern

Eine Checkliste für die MQTT-Broker-Ausschreibung hält die Anbieterbewertung auf das fokussiert, was in der Produktion zählt, statt darauf, wer die längste Feature-Seite hat. Dieser Artikel liefert Ihnen eine sofort einsetzbare, nach Bereichen gruppierte Fragenliste, erklärt, warum jede Frage wichtig ist und wie eine starke Antwort aussieht, und zeigt als durchgespieltes Beispiel, wie ConnectMQ sie beantwortet, einschließlich der Funktionen, die es nicht bietet.

So nutzen Sie diese Checkliste für die MQTT-Broker-Ausschreibung

Übernehmen Sie die Fragen in Ihre Ausschreibung (RFP) oder Ihre Bewertungstabelle und bitten Sie jeden Anbieter um eine schriftliche Antwort. Die Spalte „Beispielantwort" zeigt die Antwort von ConnectMQ, damit Sie sehen, wie eine konkrete, überprüfbare Antwort aussieht. Drei Gewohnheiten machen die Antworten vergleichbar:

1. Fragen Sie nach Fakten, nicht nach Adjektiven. „Hochskalierbar" ist keine Antwort; „bis zu N Verbindungen pro Plan, Quotenfehler werden als MQTT-5-Reason-Codes zurückgegeben" schon.
2. Fragen Sie, was nicht unterstützt wird. Ehrliche Anbieter sagen es Ihnen. Schweigen oder vage Formulierungen bei einer Frage bedeuten meist Nein.
3. Prüfen Sie wichtige Aussagen selbst. Die meisten verwalteten MQTT-Broker bieten eine kostenlose Stufe oder einen Testzeitraum. Verbinden Sie ein echtes Gerät, provozieren Sie Fehler und sehen Sie sich an, wie die Fehlermeldungen aussehen.

Bevor Sie Anforderungen formulieren, hilft es zu wissen, wie man grundsätzlich einen IoT-MQTT-Broker auswählt und welches Deployment-Modell Sie möchten. Der Leitfaden zum Cloud-MQTT-Broker erklärt die Optionen Serverless, Dedicated und Bring-Your-Own-Cloud.

1. Protokollunterstützung

2. Sicherheit und Zugriffskontrolle

Werten Sie ein „Nein" nicht automatisch als Ausschlusskriterium. ACLs pro Topic sind für eine Plattform mit mehreren Parteien sehr wichtig, für die Flotte eines einzelnen Teams hingegen kaum. Unsere MQTT-Sicherheit: Best Practices helfen Ihnen zu entscheiden, welche Kontrollen Sie wirklich brauchen.

In Ausschreibungen im DACH-Raum tauchen außerdem regelmäßig Anforderungen aus IEC 62443, der NIS2-Richtlinie, dem EU Cyber Resilience Act und der DSGVO auf, etwa die Frage nach einem Auftragsverarbeitungsvertrag. Formulieren Sie diese Punkte als konkrete Nachweise, die der Anbieter vorlegen soll, und prüfen Sie die Antworten so nüchtern wie jede andere Zeile.

3. Isolation und Mandantenfähigkeit

Stellen Sie jedem Anbieter dieselben vier Fragen. Die Antworten unterscheiden sich am Markt stark, und die richtige hängt von Ihren regulatorischen und netzwerkseitigen Rahmenbedingungen ab, nicht von einer einzigen besten Option. Geteilte Cluster sind kosteneffizient; dedizierte tauschen Kosten gegen Vorhersehbarkeit.

4. Zuverlässigkeit und Betrieb

Antworten zur Zuverlässigkeit verdienen die genaueste Prüfung. Gestalten Sie unabhängig vom Anbieter Clients, die einen Broker-Neustart tolerieren; unser Leitfaden zum Überstehen eines MQTT-Broker-Ausfalls zeigt, wie, und MQTT Broker SLA erklärt, wie Sie SLA-Bedingungen lesen.

5. Tools und Observability

6. Industrielle Integration und Datenanbindung

Bei den Integrationszeilen unterscheiden sich Anbieter am stärksten. Ein Broker mit integrierter Rule Engine spart Code, bindet Ihre Datenpipeline aber an diesen Anbieter. Ein schlichter Broker plus externe Tools hält die Pipeline portabel. Keines von beiden ist grundsätzlich besser; entscheiden Sie vor der Bewertung, was Sie bevorzugen. Wenn Ihr Werk Sparkplug B nutzt, testen Sie die Dekodierung während des Proof of Concept mit Ihren echten Payloads.

Für Industrie-4.0-Projekte gehört eine weitere Frage in diesen Abschnitt: Wie fügt sich der Broker in Ihren geplanten UNS ein? Bitten Sie die Anbieter, einen Ausschnitt Ihrer realen ISA-95-Hierarchie abzubilden, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur, und zeigen Sie dabei, wie Daten aus SPS, OPC UA, MES und ERP dort zusammenlaufen. Hintergründe liefert der Beitrag zu Sparkplug B und Unified Namespace.

7. Kommerzielles und Support

Fragen Sie jeden Anbieter:

1. Wie wird der Service bepreist: nach Verbindungen, Nachrichten, Datenverkehr, Sitzungsdauer oder dedizierter Kapazität? (Siehe unsere Erläuterung zu MQTT-Broker-Preisen.)
2. Was passiert bei Überschreitung einer Quote: Drosselung, Ablehnung oder Abrechnung der Mehrnutzung?
3. Kann ich zwischen Plänen wechseln, ohne Endpunkte oder Client-Code zu ändern?
4. Welche Support-Kanäle und Reaktionszeiten gelten für jede Stufe?
5. Wie exportiere ich meine Konfiguration und steige aus? Standard-MQTT-Clients sind der beste Schutz vor Lock-in.

Die Antworten bewerten

Gewichten Sie jeden Bereich nach seiner Bedeutung für Ihr Projekt, bewerten Sie Antworten von 0 bis 3 und multiplizieren Sie. Eine einfache Tabelle macht die Entscheidung nachvollziehbar:

Area                    Weight  Vendor A  Vendor B  Vendor C
Protocol support          3        .         .         .
Security and access       3        .         .         .
Isolation and tenancy     2        .         .         .
Reliability and ops       3        .         .         .
Tooling                   1        .         .         .
Industrial integration    2        .         .         .
Commercial and support    2        .         .         .
Weighted total

Schließen Sie mit einem praktischen Proof of Concept für die beiden besten Anbieter ab, mit Ihren echten Geräten, Payloads und Ihrer Topic-Struktur.

ConnectMQ praktisch evaluieren

Der schnellste Weg, die ConnectMQ-Spalte zu überprüfen, ist, es auszuprobieren. Legen Sie unter app.connectmq.com einen kostenlosen Broker im Serverless-Plan an, ganz ohne Kreditkarte, und testen Sie Protokollunterstützung, Fehlercodes und Tools mit Ihren eigenen Clients. Sie können auch zuerst ein Gerät auf den öffentlichen MQTT-Broker richten, der für Tests gedacht ist und keine Produktionsdaten transportieren sollte. Erfahren Sie mehr über ConnectMQ als verwalteten MQTT-Broker.

Häufig gestellte Fragen

Was ist der wichtigste Abschnitt einer MQTT-Broker-Ausschreibung?

Meist Zuverlässigkeit und Sicherheit, weil sie sich nach dem Launch am schwersten beheben lassen. Protokollunterstützung ist oft ein schnelles Ja oder Nein, während Tools und Integration die tägliche Produktivität beeinflussen.

Sollte ich eine Rule Engine in meinem MQTT-Broker voraussetzen?

Nur, wenn Sie Routing und Transformation innerhalb des Brokers wünschen. Viele Teams bevorzugen einen schlichten Broker mit externen Tools wie Node-RED oder einem Subscriber-Service, was die Datenpipeline zwischen Anbietern portabel hält.

Wie lange sollte ein Proof of Concept für einen Broker dauern?

Ein fokussierter Proof of Concept mit echten Geräten dauert typischerweise Tage statt Wochen. Testen Sie Verbindungslimits, Reconnect-Verhalten, Fehlercodes und die Tools, die Ihr Team täglich nutzen wird.

Warum enthält die Checkliste Dinge, die ConnectMQ nicht unterstützt?

Weil eine ehrliche Ausschreibung jede Anforderung abdecken muss, die Ihnen wichtig ist. Wenn die Lücken aufgeführt sind, können Sie beurteilen, ob sie für Ihr Projekt relevant sind und wie Sie sie mit externen Tools schließen würden.