.NET Aspire erklärt: Lokale Cloud-native Entwicklung ohne Kubernetes-Schmerzen

Moderne Anwendungen bestehen selten aus einem einzigen Prozess. Selbst ein bescheidener Dienst schleppt eine Datenbank, einen Cache, einen Message Broker, vielleicht ein paar APIs und ein Frontend mit. All das für die lokale Entwicklung zu verdrahten: Verbindungszeichenfolgen, Ports, Startreihenfolge, Umgebungsvariablen: ist eine Steuer, die jeder Entwickler täglich zahlt, und sie wird nur höher, je mehr das System wächst. .NET Aspire ist Microsofts Antwort: ein meinungsstarker Weg, eine verteilte Anwendung lokal zusammenzustellen, auszuführen und zu beobachten, mit einem sauberen Pfad zur Bereitstellung, ohne Kubernetes auf den Laptop zu zwingen. Dieser Leitfaden erklärt, was es ist, was es bietet und wann sich der Einsatz lohnt.

Das Problem: Verteilte Apps sind lokal mühsam

Stellen Sie sich den Alltag vor: Um Ihre App auszuführen, starten Sie einen Datenbank-Container, einen Redis-Container, zwei Backend-Dienste und ein Frontend: jeder benötigt die richtigen Verbindungszeichenfolgen und Ports, muss in der richtigen Reihenfolge gestartet werden und mit Health-Checks signalisieren, dass er bereit ist. Teams basteln das mit Skripten, READMEs und Stammeswissen zusammen. Neue Mitarbeiter verlieren damit einen Tag. Aspire ersetzt diesen Ad-hoc-Kleber durch ein strukturiertes, in Code definiertes Modell Ihrer Anwendung.

Der App-Host: Ihre App in Code beschrieben

Im Zentrum von Aspire steht der App-Host: ein Projekt, in dem Sie die Bausteine Ihres Systems und ihre Verbindungen in einfachem C# deklarieren. Sie sagen: „Diese API hängt von dieser Datenbank und diesem Cache ab“, und Aspire kümmert sich um die Bereitstellung der Abhängigkeiten, das Injizieren der Verbindungsdetails und das Starten in der richtigen Reihenfolge. Die Topologie Ihrer App wird zu versioniertem, überprüfbarem Code statt zu Folklore.

// AppHost: the whole system, described in C#.
var builder = DistributedApplication.CreateBuilder(args);

var cache = builder.AddRedis("cache");
var db    = builder.AddPostgres("pg").AddDatabase("appdb");

var api = builder.AddProject<Projects.Api>("api")
                 .WithReference(cache)
                 .WithReference(db);          // connection strings injected for you

builder.AddProject<Projects.Web>("web")
       .WithReference(api);                   // service discovery wires this up

builder.Build().Run();                        // one command starts everything

Service Discovery: Keine hartcodierten URLs mehr

Weil der App-Host jeden Dienst und seine Adresse kennt, bietet Aspire Service Discovery: Ein Dienst spricht einen anderen über seinen Namen an, und Aspire löst diesen zur Laufzeit in die richtige Adresse auf. Das eliminiert eine ganze Kategorie von „Auf meinem Rechner läuft’s“-Fehlern, die durch hartcodierte Localhost-Ports und umgebungsspezifische URLs entstehen, und es funktioniert konsistent von lokal bis zur bereitgestellten Umgebung. In einem konsumierenden Dienst verweisen Sie auf die Abhängigkeit über ihren logischen Namen: Aspire löst die echte Adresse auf:

// Web service's Program.cs
var builder = WebApplication.CreateBuilder(args);

builder.AddServiceDefaults();          // telemetry, health checks, resilience — one call
builder.AddRedisClient("cache");       // connection injected by the app host; no conn string here

// Call the "api" service by NAME — service discovery resolves the real URL.
builder.Services.AddHttpClient<OrdersClient>(c => c.BaseAddress = new("https+http://api"));

var app = builder.Build();
app.MapDefaultEndpoints();              // exposes /health and /alive for the dashboard
app.Run();

Das Dashboard: Alles auf einen Blick

Starten Sie den App-Host, und Aspire liefert Ihnen ein Entwickler-Dashboard: eine einzige Webansicht aller Dienste: ob sie laufen, ihre Logs, Traces, Metriken und die Anfragen, die zwischen den Diensten fließen. Statt mit einem Dutzend Terminalfenstern zu jonglieren, beobachten Sie das gesamte System von einem Ort aus. Für das Debuggen verteilten Verhaltens lokal rechtfertigt diese Transparenz allein schon einen Blick.

Integrationen: Batterien für gängige Abhängigkeiten

Aspire liefert Integrationen für die Komponenten, auf die Apps angewiesen sind: relationale Datenbanken, Caches, Message Broker, Storage und mehr. Eine Integration verdrahtet die Abhängigkeit, wendet sinnvolle Standardwerte an, stellt ihre Verbindung den Diensten zur Verfügung, die sie benötigen, und bindet sie in Dashboard und Telemetrie ein. Sie fügen eine bekannte Abhängigkeit mit ein oder zwei Zeilen hinzu, statt mit einer Seite Konfiguration.

Der Gewinn in Ihrem Code ist, dass die Abhängigkeit einfach da ist, injiziert und konfiguriert, ohne dass Sie sich um Verbindungszeichenfolgen kümmern müssen:

// The Redis connection the app host provisioned is injected ready-to-use.
app.MapGet("/orders/{id:int}", async (int id, IConnectionMultiplexer redis, OrdersClient api) =>
{
    var db = redis.GetDatabase();
    if (await db.StringGetAsync($"order:{id}") is { HasValue: true } cached)
        return Results.Ok(cached.ToString());          // cache hit

    var order = await api.GetOrderAsync(id);            // cross-service call, discovered by name
    await db.StringSetAsync($"order:{id}", order.ToJson(), TimeSpan.FromMinutes(5));
    return Results.Ok(order);
});

Observability ist eingebaut

Entscheidend ist, dass Aspire Observability über OpenTelemetry von Anfang an einbaut, sodass Traces, Metriken und Logs fließen, ohne dass Sie später einen Stack nachrüsten müssen. Da OpenTelemetry ein herstellerneutraler Standard ist, können Sie dieselbe Instrumentierung, die Sie lokal verwenden, in der Produktion mit jedem beliebigen Observability-Backend weiternutzen. Gute Telemetrie hört auf, eine „Irgendwann“-Aufgabe zu sein, und wird zum Standard. Dieser einzelne AddServiceDefaults() Aufruf, den Sie zuvor gesehen haben, ist die Stelle, an der sie verdrahtet wird: gemeinsam genutzt in einem ServiceDefaults-Projekt:

// ServiceDefaults/Extensions.cs — shared by every service, configured once.
public static TBuilder AddServiceDefaults<TBuilder>(this TBuilder builder)
    where TBuilder : IHostApplicationBuilder
{
    builder.Services.AddOpenTelemetry()
        .WithMetrics(m => m.AddAspNetCoreInstrumentation().AddHttpClientInstrumentation())
        .WithTracing(t => t.AddAspNetCoreInstrumentation().AddHttpClientInstrumentation())
        .UseOtlpExporter();                 // flows to the Aspire dashboard locally,
                                            // and to your OTLP backend in production
    builder.Services.AddServiceDiscovery();
    builder.Services.ConfigureHttpClientDefaults(h =>
    {
        h.AddStandardResilienceHandler();   // retries + timeouts on every HttpClient, free
        h.AddServiceDiscovery();
    });
    return builder;
}

Aspire vs. Compose vs. Kubernetes

Aspire ersetzt nicht Ihren Produktions-Orchestrator, sondern ergänzt ihn. Betrachten Sie die drei als Antworten auf unterschiedliche Fragen.

Wann Sie es einsetzen sollten

Aspire ist am überzeugendsten, wenn Ihr Stack .NET-zentriert ist und Ihre App wirklich aus mehreren Diensten besteht: mehrere Projekte plus eine Datenbank, einen Cache oder einen Broker, die Sie derzeit von Hand verdrahten. Wenn Sie einen einzelnen, in sich geschlossenen Dienst erstellen, ist die Orchestrierungsschicht Overhead, den Sie nicht brauchen. Der Break-even ist erreicht, sobald „die App lokal ausführen“ mehr erfordert als das Starten eines einzigen Prozesses.