Wer eine Messaging-Infrastruktur für industrielle IoT-Projekte wie den Unified Namespace (UNS) plant, stößt schnell auf eine entscheidende Frage: MQTT, Kafka, AMQP oder NATS – welches Protokoll passt? Die vier Kandidaten verfolgen grundlegend unterschiedliche Designziele: von der schlanken Feldkommunikation über hochdurchsatzfähiges Event-Streaming bis hin zu cloud-nativem Clustering. Dieser Artikel vergleicht alle vier systematisch anhand praxisrelevanter Kriterien im IIoT-Kontext und zeigt, welche Kombination im Unified Namespace (UNS) sinnvoll ist.
MQTT, Kafka, AMQP oder NATS – ein Überblick
Bevor der direkte Vergleich beginnt, lohnt ein kurzer Blick auf die ursprünglichen Designziele jedes Protokolls. Denn diese bestimmen maßgeblich, wo es stark ist und wo es an seine Grenzen stößt.
MQTT (Message Queuing Telemetry Transport)
MQTT wurde ursprünglich für ressourcenbeschränkte Geräte auf instabilen Verbindungen entwickelt – Satellitenleitungen, Sensoren, eingebettete Systeme. Das Pub/Sub-Modell über einen zentralen Broker, kombinierte QoS-Stufen (QoS 0, QoS 1, QoS 2), minimaler Protokoll-Overhead und breite Hardwareunterstützung machen MQTT zum de facto Standard für die Feldebene im Industrial IoT (IIoT). Als OASIS-Standard in Version 5.0 ist es in modernen SPSen, Gateways oder Edge-Devices nativ verfügbar.
Apache Kafka
Apache Kafka ist eine verteilte Event-Streaming-Plattform mit log-basierter Persistenz. Nachrichten werden in Topics als unveränderlicher, geordneter Log geschrieben – Consumer lesen diesen Log zu einem beliebigen Zeitpunkt. Das Designziel ist maximaler Durchsatz bei hoher Datenmenge, nicht minimale Latenz. Kafka setzt für Betrieb und Skalierung erhebliche Infrastruktur voraus (Broker-Cluster mit KRaft-Konsensprotokoll), ist aber unübertroffen wenn es darum geht, Millionen von Events pro Sekunde persistent zu verarbeiten.
AMQP (Advanced Message Queuing Protocol)
AMQP (Advanced Message Queuing Protocol) ist ein offenes Enterprise-Messaging-Protokoll, das vor allem durch RabbitMQ bekannt wurde. Sein Stärke liegt in flexiblen Routing-Mechanismen: Exchanges, Queues und Bindings erlauben komplexe Nachrichtenflüsse – Topic-basiertes Routing, Header-basiertes Routing, Fanout. Nachrichten-Bestätigungen (acknowledgements) und Dead-Letter-Queues bieten zuverlässige Zustellung auch bei Verarbeitungsfehlern. AMQP ist für Enterprise-Applikationsintegration ausgelegt, nicht für Massentelemetrie.
NATS
NATS ist ein cloud-natives, hochperformantes Messaging-System, das für einfachen Betrieb und globale Skalierung konzipiert wurde. Der NATS-Server ist ein einzelnes Binary ohne externe Abhängigkeiten. Natives Clustering und Superclusters ermöglichen es, mehrere Cluster über Standort- und Kontinentgrenzen hinweg zu einem einheitlichen Namespace zusammenzufassen. Mit JetStream – der persistenten Erweiterung von NATS – stehen Retention-Policies, Consumer-Gruppen und effectively-once Zustellung zur Verfügung. Latenz und Overhead liegen auf MQTT-Niveau, die Betriebskomplexität deutlich darunter als bei Kafka.
Technischer Vergleich: MQTT, Kafka, AMQP und NATS im IIoT-Kontext
Die folgende Tabelle zeigt die wichtigsten Kriterien im direkten Vergleich:
| Kriterium | MQTT | Apache Kafka | AMQP / RabbitMQ | NATS |
|---|---|---|---|---|
| Latenz | sehr niedrig (<5 ms) | mittel–hoch (10–100 ms) | niedrig–mittel (<10 ms) | sehr niedrig (<1 ms) |
| Durchsatz | mittel | sehr hoch (Mio. Events/s) | mittel | hoch |
| Persistenz | eingeschränkt (Retained Messages) | stark (Log-Retention, konfigurierbar) | mittel (Queues, TTL) | stark (JetStream) |
| Protokoll-Overhead | minimal (2-Byte Fixed Header) | hoch | mittel | minimal |
| Edge-Tauglichkeit | sehr gut | schlecht | mittel | gut |
| OT-Geräte-Support | sehr gut (nativ in PLCs, Gateways) | nicht vorhanden | gering | über Bridge/SDK |
| Clustering / Skalierung | eingeschränkt (Hersteller abhängig, nicht nativ) | stark (Kafka-Cluster) | mittel (RabbitMQ-Cluster) | stark (natives Clustering + Supercluster) |
| Ops-Komplexität | niedrig | hoch | mittel | niedrig |
| Sicherheit / Auth | TLS, Username/Password, optional mTLS – Broker-ACLs für Topic-Rechte | TLS, SASL (SCRAM, Kerberos, OAuth), native ACLs – enterprise-tauglich | TLS, SASL, granulares vHost-/Permission-Modell, LDAP-Integration | TLS, mTLS, NKeys/JWT-basierte dezentrale Auth mit Account-Isolation |
| Primäres Einsatzgebiet | Feldebene, OT-Geräte | Stream-Processing, Analytics | Enterprise-Applikationsintegration | UNS-Backbone, Cloud/Edge-Bridging |
Besonders relevant für IIoT-Architekturen sind drei Zeilen: Edge-Tauglichkeit, OT-Geräte-Support und Ops-Komplexität. Kafka scheidet für die direkte Feldkommunikation aus – ein Kafka-Cluster auf einem Edge-Gateway zu betreiben ist weder ressourcentechnisch sinnvoll noch operativ wartbar. AMQP ist für OT-Geräte kaum nativ verfügbar. MQTT und NATS teilen sich hier die Spitze – mit dem Unterschied, dass MQTT in OT-Hardware bereits eingebaut ist, während NATS seine Stärken auf Infrastrukturebene ausspielt.
Sicherheitsseitig unterscheiden sich die vier Kandidaten vor allem im Auth-Modell: MQTT und AMQP setzen auf klassische Broker-ACLs (Username/Password, optional Client-Zertifikate), während Kafka und NATS mit SASL/nativen ACLs bzw. NKeys/JWT granularere, moderne Mechanismen bieten. In der Praxis ist auf Feldebene jedoch oft das schwächste Glied entscheidend: Viele Legacy-OT-Geräte unterstützen kein TLS, sodass Netzwerksegmentierung (VLANs, Firewalls, DMZ zwischen OT und IT) die eigentliche Sicherheitsgrenze bildet – unabhängig davon, welches Protokoll auf Anwendungsebene läuft.
Zusammenfassung
Weiterführende Artikel
Wenn Sie die Unterschiede zwischen den einzelnen Kommunikationsprotokollen und Broker-Technologien im Detail betrachten möchten, finden Sie in den folgenden Fachartikeln vertiefende Vergleiche:
- Kafka in Industrial IoT vs. MQTT
- NATS vs. MQTT: Which Protocol Fits Best in a Unified Namespace
- NATS vs. Kafka: Comparison for the Unified Namespace (UNS)
Einsatzszenarien im IIoT
MQTT: Shop-Floor-Kommunikation mit MQTT-fähigen Geräten
MQTT ist die richtige Wahl, wenn OT-Geräte MQTT nativ unterstützen – und das ist bei modernen SPSen, Gateways und Sensoren zunehmend der Fall. Der minimale Protokoll-Overhead, die zuverlässige Zustellung über QoS-Stufen und die breite Hardwarekompatibilität machen MQTT zur optimalen Wahl für die direkte Gerätekommunikation auf der Feldebene. Entscheidend: MQTT ist primär ein Gerätekommunikationsprotokoll, kein Infrastrukturprotokoll für den UNS-Backbone. Wo Geräte kein natives MQTT sprechen, übernehmen Protokoll-Gateways (z. B. Modbus-to-MQTT, OPC UA-to-MQTT) die Übersetzung.
NATS: UNS-Backbone und Multi-Site-Infrastruktur
NATS ist für den Unified Namespace (UNS) als zentrale Messaging-Infrastruktur besonders geeignet. Natives Clustering ohne externe Abhängigkeiten, Sub-Millisekunden-Latenz und die Supercluster-Fähigkeit – das Zusammenfassen mehrerer geographisch verteilter Cluster zu einem einheitlichen globalen Namespace – sind Eigenschaften, die kein anderes der vier Protokolle in dieser Kombination bietet. Mit JetStream lassen sich Retention-Policies je Subject konfigurieren, sodass kritische Prozessdaten persistent vorgehalten werden, während Telemetriedaten mit kurzer TTL verworfen werden. NATS eignet sich außerdem für Cloud-Edge-Bridging: Nachrichten können transparent vom Edge-Cluster in den Cloud-Cluster repliziert werden, ohne Änderungen an der Applikationslogik.
Apache Kafka: Stream-Processing und Analytics-Schicht
Apache Kafka ist nicht für die Feldebene geeignet, aber unersetzt wenn es um die nachgelagerte Verarbeitung großer Datenmengen geht. Typische Einsatzszenarien im IIoT: Ingestion in Data Lakes oder Data Warehouses, Stream-Processing mit Kafka Streams oder Apache Flink, historische Analyse von Produktionsdaten, Machine-Learning-Pipelines. Die Integration erfolgt dabei typischerweise über einen Kafka-Connector, der Nachrichten aus dem UNS-Backbone (NATS oder MQTT) abonniert und in Kafka-Topics schreibt. Kafka ist kein Ersatz für den UNS-Backbone, sondern eine spezialisierte Ergänzung für Applikationen mit hohen Persistenz- und Durchsatzanforderungen.
AMQP / RabbitMQ: Enterprise-Applikationsintegration
AMQP bzw. RabbitMQ besetzt eine spezifische Nische: komplexe Routing-Anforderungen in Enterprise-Applikationen. Wenn SAP-Systeme, MES oder ERP-Applikationen Nachrichten auf Basis von Header-Werten, Routing-Keys oder Applikationslogik unterschiedlich verarbeiten müssen, bietet AMQP hierfür ausgereifte Mechanismen. Im IIoT-Kontext tritt AMQP typischerweise als Brücke zwischen dem UNS und IT-seitigen Applikationen auf – nicht als primäres Transportprotokoll für OT-Daten.
Welches Protokoll passt zum Unified Namespace (UNS)?
Der Unified Namespace (UNS) stellt spezifische Anforderungen an die Messaging-Infrastruktur: hierarchische Topics, Pub/Sub-Semantik, niedrige Latenz, Skalierbarkeit über Edge und Cloud hinweg, einfacher Betrieb und die Fähigkeit, einen einheitlichen globalen Namespace über mehrere Standorte zu spannen.
NATS als primäres UNS-Protokoll erfüllt diese Anforderungen als einziges der vier Kandidaten vollständig:
- Hierarchische Subjects: NATS-Subjects folgen einer Punkt-Notation (enterprise.site.area.line.machine.signal) und unterstützen Wildcards (* für eine Ebene, > für alle Unterebenen) – analog zur ISA-95-Hierarchie.
- Natives Clustering: Mehrere NATS-Server bilden einen Cluster ohne externe Koordinationsschicht. Horizontal skalieren bedeutet lediglich, einen weiteren Server hinzuzufügen.
- Supercluster / Leaf Nodes: NATS Supercluster verbinden mehrere Cluster zu einem globalen Namespace. Leaf Nodes erlauben es, Edge-Standorte als autonome Einheiten zu betreiben, die selektiv in den zentralen Cluster replizieren – ideal für verteilte Produktionsstandorte.
- JetStream: Persistente Zustellung, Consumer-Gruppen und Replay-Funktionen direkt im NATS-System, ohne zusätzliche Middleware.
- Ops-Einfachheit: Ein einzelnes Binary, keine externen Abhängigkeiten, deklarative Konfiguration.
MQTT am Feldgerät – Bridge zu NATS: Wo OT-Geräte nativ MQTT sprechen, bleibt MQTT der bevorzugte Kanal für die Feldkommunikation. Ein MQTT-to-NATS-Bridge-Connector (z. B. über i-flow Edge) übersetzt eingehende MQTT-Topics in NATS-Subjects und fügt die Daten nahtlos in den UNS ein. Das ist keine Einschränkung, sondern ein bewährtes Muster: das richtige Protokoll an der richtigen Stelle, verbunden durch eine schlanke Brücke.
Kafka downstream: Wenn Produktionsdaten aus dem UNS in analytische Systeme fließen sollen, ist ein Kafka-Connector die saubere Lösung. Der UNS-Backbone bleibt schlank und latenzoptimiert; Kafka übernimmt die Langzeitpersistenz und Stream-Processing-Aufgaben.
AMQP / RabbitMQ hat im UNS-Kern keinen Platz – die Routing-Komplexität ist für OT-Datenflüsse nicht nötig und die OT-Gerätesupport fehlt. Als Brücke zu Enterprise-IT-Applikationen bleibt AMQP jedoch eine valide Option.
Entscheidungshilfe: Wann MQTT, Kafka, AMQP oder NATS?
Die folgende Übersicht hilft bei der Protokollwahl im konkreten Projektkontext:
- OT-Geräte mit nativem MQTT direkt anbinden: → MQTT für die Feldkommunikation, Bridge zu NATS für den UNS.
- UNS-Backbone für einen oder mehrere Standorte: → NATS mit Clustering. Bei mehreren Standorten: NATS Supercluster oder Leaf Nodes.
- Historische Datenanalyse, Data Lake, ML-Pipelines: → Apache Kafka als nachgelagerte Analytics-Schicht, gespeist aus dem UNS.
- Enterprise-Applikationen mit komplexen Routing-Anforderungen: → AMQP / RabbitMQ als IT-seitige Integration, z. B. für SAP- oder MES-Anbindung.
- Cloud-Edge-Bridging mit autonomen Edge-Standorten: → NATS Leaf Nodes am Edge, zentraler NATS-Cluster in der Cloud.
- Moderne Greenfield-Architektur ohne Legacy-OT-Geräte: → NATS end-to-end als einheitliches Protokoll über alle Ebenen.
Das bewährteste Muster in der Praxis: MQTT am Feldgerät → Bridge → NATS als UNS-Backbone → Kafka für Analytics. Jedes Protokoll übernimmt dabei die Aufgabe, für die es entworfen wurde.
Fazit
Kein einzelnes Protokoll gewinnt den Vergleich universell – die Frage ist nicht MQTT, Kafka, AMQP oder NATS, sondern: Welches Protokoll passt zu welcher Ebene der Architektur? Die Antwort im IIoT-Kontext ist klar strukturiert:
- Feldebene: MQTT bleibt die erste Wahl dort, wo OT-Geräte das Protokoll nativ unterstützen – leichtgewichtig, weit verbreitet, hardware-erprobt.
- UNS-Backbone: NATS ist die überlegene Infrastruktur für den Unified Namespace – natives Clustering, Supercluster für globale Namespaces, JetStream für Persistenz, minimaler Betriebsaufwand.
- Analytics und Persistenz: Apache Kafka als spezialisierte downstream-Schicht für Stream-Processing und Langzeitpersistenz.
- Enterprise-IT-Integration: AMQP / RabbitMQ für applikationsseitige Routing-Anforderungen in IT-Systemen.
