Letztes Quartal saß ich beim Geschäftsführer eines Maschinenbauers, 140 Mitarbeitende, Standort Oberfranken. Die haben eine Bestellstrecke: Auftrag rein, Verfügbarkeit prüfen, Zahlung anfordern, Bestand reservieren, Lieferschein erzeugen, Kunde informieren. Klingt nach fünf Minuten Arbeit. In Wirklichkeit läuft das über drei Systeme, zwei externe APIs und einen internen Dienst, der freitagnachmittags gern hängt. Wenn irgendetwas schiefgeht, weiß niemand genau, wo der Prozess abgebrochen ist — und ob der Kunde jetzt eine Rechnung bekommt oder nicht.
Das ist kein Einzelfall. Das ist der Normalzustand im deutschen Mittelstand. Und genau für dieses Problem schreibt Milan Jovanović seinen neuesten Beitrag.
Was der Artikel sagt
Jovanović erklärt Dapr Workflows — ein Baustein des CNCF-Projekts Dapr — als Lösung für lang laufende, mehrstufige Geschäftsprozesse in .NET. Die Idee: Du schreibst deinen Prozess als normalen C#-Code, und Dapr sorgt dafür, dass jeder Schritt persistent gespeichert wird. Bricht der Prozess mittendrin ab, wird er von der letzten abgeschlossenen Aktivität aus weitergespielt — kein doppelter Zahlungseinzug, kein verlorener Bestellstatus. Die Integration mit .NET Aspire macht das lokale Setup vergleichsweise reibungslos: ein CLI-Befehl, ein Scaffold, und du siehst den Workflow-State im Diagrid Dev Dashboard. Technisch ist das sauber erklärt, der Beispielcode ist lesbar, und die Determinismus-Anforderung — keine DateTime.Now im Workflow-Code, kein direktes Logging — wird nicht unter den Tisch gekehrt.
Der Artikel ist gut. Ich empfehle ihn jedem .NET-Entwickler, der komplexe Prozesse baut.
Wie das im KMU wirklich landet
Hier fängt meine Perspektive an.
Das technische Argument ist wasserdicht. Das operative ist es nicht.
Dapr bringt einen Sidecar mit. Das heißt: Jeder Service, der Dapr nutzt, bekommt einen eigenen Prozess nebengestellt. Du brauchst eine State-Store-Infrastruktur, die Actors unterstützt — Redis reicht, aber Redis muss erst mal betrieben werden. Du brauchst ein Deployment-Konzept, das Sidecar-Injection versteht, also de facto Kubernetes oder zumindest Docker Compose mit klarer Struktur. Und du brauchst jemanden im Team, der weiß, was passiert, wenn eine Workflow-Instanz hängt und du in den Diagrid Dev Dashboard schaust.
Beim Maschinenbauer aus Oberfranken gibt es zwei .NET-Entwickler. Beide gut, beide solide. Beide haben keine Kubernetes-Erfahrung. Einer kommt von klassischen Windows-Services, der andere von ASP.NET-MVC-Monolithen. Dapr Workflows in diese Umgebung einzuführen bedeutet nicht, einen Artikel zu lesen und ein NuGet-Paket zu installieren. Es bedeutet: drei bis sechs Monate Lernkurve, neue Betriebskonzepte, und ein System, das in der Produktion komplexer ist als das Problem, das es löst.
Das sage ich nicht, um Dapr schlecht zu reden. Ich sage es, weil Jovanović — wie die meisten Autoren in der Enterprise-.NET-Welt — aus einem Kontext schreibt, in dem du ein DevOps-Team, einen Platform-Engineer und Entwickler hast, die CNCF-Projekte schon kennen. Das ist nicht böse gemeint, das ist einfach sein Publikum.
Was sich lohnt — und ab wann
Dapr Workflows lohnen sich im KMU, wenn drei Bedingungen gleichzeitig erfüllt sind:
Erstens: Der Prozess ist tatsächlich kritisch und lang laufend. "Lang laufend" heißt nicht "fünf Sekunden" — sondern Prozesse, die über Minuten oder Stunden gehen, externe Systeme mit echten Timeouts ansprechen, und wo ein Abbruch mittendrin echten Schaden verursacht: doppelte Buchungen, verlorene Aufträge, falsche Lagerbestände. Wenn du das hast, ist Durability kein Luxus.
Zweitens: Du hast bereits Kubernetes oder bist gerade dabei, es einzuführen — nicht wegen Dapr, sondern aus anderen Gründen. Dann ist der Marginalaufwand für Dapr gering, und du zahlst die Infrastrukturkosten nicht extra.
Drittens: Du hast mindestens einen Entwickler, der bereit ist, sich zwei bis drei Wochen ernsthaft einzuarbeiten — und der danach noch da ist. Fluktuation ist im Mittelstand ein reales Problem. Ein System, das nur einer versteht, ist ein Risiko.
Sind diese drei Bedingungen nicht erfüllt, gibt es einfachere Alternativen.
Was stattdessen funktioniert
Für den Maschinenbauer habe ich etwas anderes gebaut: Eine Prozess-State-Tabelle in der bestehenden SQL-Datenbank, einen einfachen Background-Service in .NET, und eine klare Statusmaschine mit fünf Zuständen. Jeder Schritt schreibt seinen Zustand in die Tabelle, bevor er weitergeht. Retry-Logik über Polly. Fehlerhafte Prozesse landen in einer Admin-Ansicht, die der kaufmännische Leiter selbst auflösen kann — mit einem Klick.
Das ist nicht elegant. Es ist nicht "durable execution" im technischen Sinne. Aber es löst das Problem, und in sechs Monaten kann ich jemandem, der das System noch nie gesehen hat, die Logik in einer Stunde erklären. Das hat Wert.
Der Punkt ist nicht, dass Dapr schlecht ist. Der Punkt ist: Die Komplexitätskosten eines Systems zahlt nicht der Architekt, der es gebaut hat — sondern das Team, das es betreibt.
Konkrete Empfehlung
Wenn du ein KMU-CTO oder IT-Leiter bist und dich fragst, ob Dapr Workflows etwas für euch sind: Schau zuerst, ob dein aktuelles Problem wirklich Durability auf Infrastrukturebene braucht — oder ob eine saubere State-Maschine mit einer vernünftigen Datenbank das schon löst.
Wenn du ein Greenfield-Projekt hast, Kubernetes sowieso kommt, und dein Team stark genug ist: Lies Milans Artikel. Er erklärt die Mechanik besser als ich es hier könnte, und Dapr Workflows sind echte Produktionstechnologie, kein Spielzeug. Die Determinismus-Regel allein ist eine der wichtigsten Disziplinen, die du einem Team beibringen kannst, das lang laufende Prozesse baut.
Wenn du aber gerade mit zwei oder drei Entwicklern ein bestehendes System stabilisieren willst, dann ist Dapr nicht die erste Antwort. Dann ist die erste Antwort: Was ist der einfachste Mechanismus, der diesen Prozess wiederherstellbar macht?
Manchmal ist das eine Zeile SQL mehr.
Der vollständige Original-Beitrag von Milan Jovanović: Building Dapr Workflows in .NET With Aspire
Du willst wissen, ob Dapr — oder eine einfachere Alternative — in eurer konkreten Situation der richtige Schritt ist? Dreißig Minuten, kein Pitch, keine Powerpoint.
— Bernhard