DDC hakt nach: Wie .NET Aspire und Dapr den Service-Discovery-Albtraum beenden
Cloud-native Anwendungen bieten viele Vorteile, zum Beispiel die Chance auf einen Nervenzusammenbruch, wenn die Service-Discovery mal wieder versagt. Experte Florian Lenz erklärt in seiner Session „Next-Gen Cloud Native .NET Apps: Aspire and Dapr Unleashed“ auf der .NET Developer Conference 2025 wie .NET Aspire und Dapr diese Nebenwirkungen verhindern können. Wir haben ihn vorab befragt, welche Tricks er vorstellen wird.
Wie oft warst Du schon kurz davor, deinen Laptop aus dem Fenster zu werfen, weil wieder mal die Service-Discovery nicht wollte, wie sie sollte?
Florian: Ehrlich gesagt: viel zu oft. Ports ändern sich, URLs werden umbenannt, ein Health-Check fehlt und schon findet Service A Service B nicht mehr. Fairerweise, Docker Compose hat eine ordentliche Service-Discovery, die vieles abfängt. Aspire geht für mich trotzdem einen Schritt weiter. Ich beschreibe die komplette App zentral im AppHost, erhalte konsistente Endpunkte, Health-Probes und Observability out of the box. Änderungen trage ich einmal nach, alles andere folgt automatisch. Dapr ergänzt das, indem ich Services über die Sidecar-Architektur aufrufen kann. Dadurch wird meine Anwendung sehr flexibel. Der Anwendungscode und der Infrastruktur-Code sind klar getrennt. Ein weiterer Vorteil ist, dass dank .NET Aspire, sich Azure-Services wie Key Vault oder Service Bus direkt einbinden lassen über den AppHost. Unterm Strich bedeutet das: weniger Drift, weniger Gefrickel, mehr Zeit für Features und der Laptop bleibt drin.
Dapr mit seiner Sidecar-Architektur: Irgendwas muss doch schiefgehen können, oder bist du wirklich der erste Entwickler, der ein perfektes Tool gefunden hat?
Florian: Klar kann es zu Problemen kommen, perfekt ist nichts. Mit Sidecars steigt die Betriebskomplexität: Es gibt mehr Prozesse, neue Ports, zusätzliche Policies und Zertifikate (mTLS) und man muss verstehen, wie der Traffic tatsächlich fließt. Typische Stolpersteine sind falsche Component-Configs (Pub/Sub, State, Secrets), eine unterschiedliche Versionsnummer zwischen CLI und Runtime oder blockierte Sidecar-Ports. Der Gegenwert ist jedoch groß: Retries, Timeouts, Circuit Breaker und sauberes Tracing sind deklarativ möglich, Fehler bleiben im Sidecar isoliert und sind schneller einzugrenzen. Fazit: Ja, Sidecars machen die Architektur nicht simpler, aber die gewonnene Resilienz und Portabilität zahlen sich in der Praxis aus.
Wenn du einem Entwickler in 30 Sekunden erklären müsstest, warum er sich Aspire und Dapr anschauen sollte, statt weiter mit Docker-Compose und YAML-Files zu kämpfen - was wäre dein Elevator Pitch?
Florian: .NET Aspire beschleunigt den Inner Loop: Ein Start für die gesamte App, konsistente Service-Discovery, Health-Checks und ein Dashboard. Mit den Azure-Integrationen kann ich Ressourcen wie Key Vault, Service Bus oder Cosmos deklarativ anhängen und das Wiring erledigen lassen. Dapr liefert die Cloud-Bausteine als austauschbare Sidecar-APIs (Service-Invocation, State, Pub/Sub, Bindings, Secrets), sodass ich meinen Code nicht an einen konkreten Broker kette. Das heißt konkret: Heute lokal produktiv, morgen auf Azure. Die Kombination beider Tools ist wirklich mächtig.
Die .NET Developer Conference 2025 findet vom 24. bis 27. November 2025 in Köln statt. Hier erfährst Du alles rund um Microsoft .NET. Florians Session findet am Mittwoch, dem 26. November 2025, um 11.40 Uhr im Track Cloud Development statt. Noch kein Ticket? Dann gleich eines holen.
- Wie oft warst Du schon kurz davor, deinen Laptop aus dem Fenster zu werfen, weil wieder mal die Service-Discovery nicht wollte, wie sie sollte?
- Dapr mit seiner Sidecar-Architektur: Irgendwas muss doch schiefgehen können, oder bist du wirklich der erste Entwickler, der ein perfektes Tool gefunden hat?
- Wenn du einem Entwickler in 30 Sekunden erklären müsstest, warum er sich Aspire und Dapr anschauen sollte, statt weiter mit Docker-Compose und YAML-Files zu kämpfen - was wäre dein Elevator Pitch?
