Présentation de .NET Aspire : développement cloud natif en local sans la complexité de Kubernetes

Les applications modernes sont rarement un processus unique. Même un service modeste traîne avec lui une base de données, un cache, un courtier de messages, peut-être deux ou trois API et un frontend. Câbler tout cela pour le développement local: chaînes de connexion, ports, ordre de démarrage, variables d’environnement: est une taxe que chaque développeur paie quotidiennement, et cela ne fait qu’empirer à mesure que le système grandit. .NET Aspire est la réponse de Microsoft : une manière structurée de composer, exécuter et observer une application multiservice en local, avec un chemin clair vers le déploiement, sans imposer Kubernetes sur votre poste. Ce guide explique ce que c’est, ce que cela vous apporte et quand il vaut la peine de l’adopter.

Le problème : les applications distribuées sont fastidieuses en local

Imaginez la réalité quotidienne : pour exécuter votre application, vous démarrez un conteneur de base de données, un conteneur Redis, deux services backend et un frontend, chacun nécessitant les bonnes chaînes de connexion et les bons ports, démarrés dans le bon ordre, avec des vérifications de santé pour savoir qu’ils sont prêts. Les équipes bricolent cela avec des scripts, des README et des connaissances tribales. Les nouveaux arrivants y perdent une journée. Aspire remplace cette glue ad hoc par un modèle structuré de votre application, défini par du code.

L’hôte d’application : votre application décrite en code

Au cœur d’Aspire se trouve l’hôte d’application: un projet où vous déclarez les éléments de votre système et comment ils se connectent, en C# pur. Vous dites « cette API dépend de cette base de données et de ce cache », et Aspire se charge de provisionner les dépendances, d’injecter les détails de connexion et de tout démarrer dans l’ordre. La topologie de votre application devient du code versionné et révisable au lieu de 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

Découverte de services : plus d’URL en dur

Comme l’hôte d’application connaît chaque service et son adresse, Aspire fournit la découverte de services : un service fait référence à un autre par son nom, et Aspire le résout à la bonne adresse à l’exécution. Cela élimine toute une catégorie de bugs « ça marche sur ma machine » causés par des ports localhost en dur et des URL spécifiques à l’environnement, et cela se maintient de manière cohérente du local jusqu’aux environnements déployés. Dans un service consommateur, vous faites référence à la dépendance par son nom logique: Aspire résout l’adresse réelle :

// 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();

Le tableau de bord : tout voir d’un coup

Exécutez l’hôte d’application et Aspire vous donne un tableau de bord développeur: une vue web unique de chaque service : s’il est en cours d’exécution, ses journaux, ses traces, ses métriques et les requêtes qui circulent entre les services. Au lieu de jongler avec une douzaine de fenêtres de terminal, vous observez tout le système depuis un seul endroit. Pour déboguer le comportement distribué en local, cette visibilité justifie à elle seule un coup d’œil.

Intégrations : des batteries pour les dépendances courantes

Aspire fournit des intégrations pour les composants sur lesquels les applications s’appuient: bases de données relationnelles, caches, courtiers de messages, stockage, etc. Une intégration câble la dépendance, applique des valeurs par défaut sensées, expose sa connexion aux services qui en ont besoin et la branche sur le tableau de bord et la télémétrie. Vous ajoutez une dépendance bien connue en une ligne ou deux au lieu d’une page de configuration.

Le bénéfice dans votre code est que la dépendance est simplement là, injectée et configurée, sans que vous ayez à faire le moindre raccordement de chaîne de connexion :

// 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);
});

L’observabilité est intégrée

Point crucial, Aspire intègre l’observabilité via OpenTelemetry dès le départ, de sorte que les traces, les métriques et les journaux circulent sans que vous ayez à ajouter une pile plus tard. Comme OpenTelemetry est un standard neutre vis-à-vis des fournisseurs, la même instrumentation que vous utilisez en local se transporte vers le backend d’observabilité que vous utilisez en production. Une bonne télémétrie cesse d’être une tâche pour plus tard et devient la norme. Ce simple AddServiceDefaults() appel que vous avez vu plus tôt est l’endroit où elle est câblée: partagée entre tous les services dans un projet ServiceDefaults :

// 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 ne remplace pas votre orchestrateur de production, il le complète. Voyez ces trois outils comme répondant à des questions différentes.

Quand l'adopter

Aspire est le plus intéressant lorsque votre stack est centrée sur .NET et que votre application est véritablement multi-services : plusieurs projets, plus une base de données, un cache ou un broker que vous connectez actuellement à la main. Si vous construisez un seul service autonome, la couche d'orchestration est une surcharge dont vous n'avez pas besoin. Le point d'équilibre est atteint dès que « lancer l'application en local » nécessite plus que de démarrer un seul processus.