Letztes Jahr saß ich bei einem Maschinenbauer, 180 Mitarbeitende, modernes .NET-Backend, Produktion läuft durch — und mittendrin ein Blob aus RabbitMQ-Exchanges, die niemand mehr vollständig versteht. Der ursprüngliche Entwickler ist seit zwei Jahren weg. Die Queue hatte vier Dead-Letter-Konfigurationen, von denen zwei widersprüchlich waren. Und wenn eine Nachricht verschwand, fing die Suche in drei verschiedenen Monitoring-Tools an.
Der Wunsch des Teams: "Können wir das nicht einfacher machen?" Genau das ist der Moment, in dem ich anfange, NATS ernsthaft zu empfehlen. Nicht weil es hip ist, sondern weil es in diesem Szenario tatsächlich weniger kaputt geht.
Was Milan Jovanović schreibt — und er hat recht
Milan erklärt in seinem Artikel klar und ohne Marketing-Schicht, warum NATS JetStream eine ernstzunehmende Alternative zu RabbitMQ und Azure Service Bus ist. Das Kern-Argument: ein einziges Go-Binary, keine externen Abhängigkeiten, 18 MB Image, JetStream als persistente Schicht mit At-least-once-Delivery. Der .NET-Client (NATS.Net) ist modern, DI-freundlich, und die API ist deutlich schlanker als das, was du mit RabbitMQ-Clients gewohnt bist. Besonders sauber ist sein Hinweis, dass man nach dem Side Effect ackert, nicht vorher — das ist der Punkt, den Quickstarts meistens verschweigen und der in Produktion zu Datenverlust führt. Wer mit .NET und Hintergrundverarbeitung arbeitet, sollte diesen Artikel gelesen haben.
Wie das in einem KMU wirklich landet
Ich unterscheide in meinen Mandaten drei typische Ausgangssituationen.
Situation 1: Greenfield, internes Team, .NET durch und durch.
Hier ist NATS JetStream die Empfehlung, die ich heute ausspreche. Das Setup aus Milans Artikel funktioniert — ein docker-compose.yml, zwei NuGet-Pakete, fertig. Kein Erlang, kein ZooKeeper, kein separates Management-UI das auf Port 15672 wartet. Das Ops-Team muss nichts Neues lernen außer "Container läuft oder läuft nicht". Für ein Team von 5-10 Entwicklern, die keinen eigenen DevOps-Engineer haben, ist das ein echter Vorteil. Ich habe NATS bei einem Softwarehaus mit 40 Leuten eingeführt — Setup-Zeit: ein halber Tag inklusive Monitoring in Grafana. RabbitMQ hatte damals zwei Wochen gebraucht, bis alle Exchange-Bindings verstanden waren.
Situation 2: RabbitMQ läuft bereits, stabil, das Team kennt es. Hier rate ich von einem Wechsel ab. NATS ist besser als sein Bekanntheitsgrad, aber "besser" rechtfertigt keine Migration, die drei Wochen kostet und kein neues Feature liefert. RabbitMQ ist ausgereift, hat ein hervorragendes Management-UI, und jeder .NET-Entwickler mit zwei Jahren Erfahrung hat es schon einmal angefasst. Das ist ein unterschätztes Asset. Wenn die aktuelle Lösung funktioniert und das Team damit produktiv ist, bleibt dran.
Situation 3: Azure-First-Umgebung. Dann ist Azure Service Bus oft die richtigere Wahl — nicht weil er technisch überlegen ist, sondern weil er in die Abrechnungs- und IAM-Strukturen passt, die ohnehin schon existieren. Ein NATS-Server in Azure zu betreiben macht technisch Sinn, aber du fügst eine weitere Infrastruktur-Komponente ein, die du selbst warten musst. Für ein KMU ohne dediziertes Ops-Team ist das eine echte Kosten-Kalkulation: Azure Service Bus Basic kostet unter einem Euro pro Million Operationen. Selbst gehostetes NATS kostet Entwicklerzeit für Updates, Monitoring und Incident Response.
Was im Artikel fehlt — aus KMU-Sicht
Milan schreibt für ein Entwickler-Publikum, und das merkt man. Drei Punkte, die in meinen Mandaten fast immer auftauchen:
Observability ist die eigentliche Arbeit. Der Code im Artikel ist sauber. Aber wer zeigt mir, welche Nachrichten gerade im Stream liegen, welche Consumer-Lag haben, welche MaxDeliver-Grenze gerissen wird? NATS hat einen eingebauten Monitoring-Endpoint (/varz, /jsz) und funktioniert gut mit Prometheus und Grafana. Das Setup kostet aber Zeit — und für ein KMU ohne Monitoring-Erfahrung ist das nicht trivial. Ich empfehle hier, das von Anfang an mitzuplanen und nicht als "machen wir später" zu behandeln. Später kommt nie, bis ein Fehler in Produktion auftritt.
Was passiert mit dem Poison-Message-Problem in der Praxis? Milan erwähnt MaxDeliver = 5 — nach fünf Versuchen wird die Nachricht verworfen. Aber wohin? Standardmäßig landet sie im Nirgendwo. Für ein Produktivsystem braucht du eine explizite Dead-Letter-Strategie: einen zweiten Stream, der diese Nachrichten auffängt, Alerting, und einen Prozess, wie das Ops-Team damit umgeht. Ohne das ist MaxDeliver = 5 nur die Konfiguration, dass du Fehler schweigend schluckst.
Skalierung ist einfacher als du denkst — aber nicht kostenlos. Milans Beispiel läuft auf einem einzelnen Node. NATS hat Clustering (JetStream Clustering), das auf Basis von Raft-Consensus funktioniert und für die meisten KMU-Workloads ausreicht. Aber: ein Cluster braucht mindestens drei Nodes für Quorum, das sind drei Container, die gewartet werden müssen. Für einen Maschinenbauer mit 500 internen Jobs pro Tag ist das Overkill. Für ein SaaS-Produkt mit wachsender Nutzerbasis ist es notwendig. Diese Abwägung fehlt im Artikel, weil er nicht für KMU-Architekten schreibt — das ist kein Vorwurf, nur ein Hinweis.
Meine konkrete Empfehlung
Wenn du heute eine neue Hintergrundverarbeitung in .NET aufbaust, kein bestehendes Messaging-System hast, und dein Team klein genug ist, dass Ops-Komplexität echte Kosten verursacht: probiere NATS JetStream aus. Milan zeigt dir den richtigen Einstieg. Plane von Anfang an Monitoring ein, definiere eine Dead-Letter-Strategie, und entscheide bewusst, ob du Single-Node oder Cluster brauchst.
Wenn du RabbitMQ hast und es funktioniert: lass es laufen. Technischer Fortschritt rechtfertigt keine Migration ohne konkreten Schmerzpunkt.
Wenn du Azure-first bist: rechne durch, ob der Betrieb eines weiteren selbstverwalteten Systems wirklich günstiger ist als Azure Service Bus — inklusive der Opportunitätskosten deiner Entwicklerzeit.
NATS ist kein Allheilmittel. Es ist ein ernstzunehmendes Werkzeug, das in bestimmten Kontexten erheblich einfacher zu betreiben ist als die Alternativen. Dieser Kontext ist häufiger als sein Bekanntheitsgrad vermuten lässt.
Der vollständige Original-Beitrag von Milan Jovanović: Getting Started With NATS JetStream in .NET
Hast du gerade eine Messaging-Entscheidung vor dir und weißt nicht, ob NATS, RabbitMQ oder Azure Service Bus die richtige Wahl ist? Dann sprich mit mir darüber — konkret, ohne Schönrederei, in 30 Minuten.
— Bernhard