.NET Aspire — orquestração de microserviços sem Kubernetes

Se você trabalha com microserviços .NET, provavelmente conhece a dor: abrir 5 terminais, executar 5 comandos diferentes, configurar connection strings em cada serviço, torcer para que tudo suba na ordem certa, e debugar problemas abrindo logs em janelas separadas. A alternativa tradicional — Kubernetes — resolve parte disso, mas traz uma complexidade operacional brutal para times pequenos e médios.

O .NET Aspire chegou como uma terceira via: orquestração code-first, observabilidade integrada, service discovery automático, e deploy para qualquer target — tudo definido em C# (ou TypeScript), sem YAML, sem Helm charts, sem cluster. Um único aspire run e seu sistema distribuído inteiro está rodando localmente com logs centralizados, health checks, e telemetria.

Neste artigo, vamos entender o que o Aspire é (e o que não é), como funciona na prática, e por que ele explodiu em adoção em 2026 como a solução ideal para times que não precisam da complexidade do Kubernetes.

O que é o .NET Aspire

Aspire é uma camada de orquestração e observabilidade code-first para aplicações distribuídas. Você define seus serviços, bancos de dados, caches, filas e dependências cloud em código — o AppHost — e o Aspire cuida de:

• Startup automático: todos os serviços sobem com um comando
• Service discovery: sem hardcode de URLs — funciona local e em produção
• Dashboard unificado: logs, traces e métricas de todos os serviços em um lugar
• Health checks: monitoramento de dependências integrado
• Deploy consistente: o mesmo modelo que roda local vai para produção

O que Aspire NÃO é

• Não é um framework de aplicação (não substitui ASP.NET Core, Entity Framework, etc.)
• Não é um runtime de produção (não é um Kubernetes)
• Não é exclusivo para .NET — orquestra workloads em C#, Python, Node.js, Go, Java, Rust
• Não é um cloud provider

Pense no Aspire como o docker-compose.yml feito direito: tipado, com IntelliSense, refatorável, versionável no git, e que escala do dev local ao deploy em produção sem mudar de ferramenta.

A dor que o Aspire resolve

Vamos ser concretos. Sem Aspire, o workflow típico de um time com 4-5 microserviços é:

# Terminal 1 - banco
docker run -d -p 5432:5432 -e POSTGRES_PASSWORD=secret postgres:15

# Terminal 2 - API principal
cd api && dotnet run

# Terminal 3 - worker de processamento
cd worker && dotnet run

# Terminal 4 - serviço de notificações
cd notifications && dotnet run

# Terminal 5 - frontend
cd frontend && npm run dev

# Agora reze para todos se conectarem...

Problemas óbvios:

• Cada dev tem portas diferentes configuradas localmente
• Connection strings hardcoded em appsettings.Development.json
• "Funciona na minha máquina" — config diverge entre membros do time
• Debugar = attach manual do debugger em cada processo
• Logs espalhados em 5 terminais — correlação de requests é impossível
• Adicionar um Redis ou RabbitMQ = mais um container manual + config

Com Docker Compose melhora um pouco, mas você ainda tem YAML não-tipado, sem IntelliSense, sem refactoring, e uma distância enorme entre o compose local e o deploy de produção.

Como funciona na prática

Instalação

O Aspire agora tem sua própria CLI standalone (não depende mais de templates dotnet new):

# macOS / Linux
curl -sSL https://aspire.dev/install.sh | bash

# Windows
irm https://aspire.dev/install.ps1 | iex

O AppHost — seu sistema inteiro em um arquivo

O coração do Aspire é o AppHost — um projeto C# (ou TypeScript) que descreve toda a topologia da sua aplicação:

// AppHost.cs
#:sdk Aspire.AppHost.Sdk
#:package Aspire.Hosting.PostgreSQL
#:package Aspire.Hosting.Redis
#:package Aspire.Hosting.RabbitMQ

var builder = DistributedApplication.CreateBuilder(args);

// Infraestrutura
var postgres = builder.AddPostgres("db")
    .AddDatabase("app-db");

var redis = builder.AddRedis("cache");

var rabbit = builder.AddRabbitMQ("messaging");

// Serviços
var api = builder.AddProject<Projects.Api>("api")
    .WithReference(postgres)
    .WithReference(redis)
    .WithReference(rabbit);

var worker = builder.AddProject<Projects.Worker>("worker")
    .WithReference(postgres)
    .WithReference(rabbit);

var notifications = builder.AddProject<Projects.Notifications>("notifications")
    .WithReference(rabbit)
    .WithReference(redis);

// Frontend
builder.AddNpmApp("frontend", "../frontend")
    .WithReference(api);

builder.Build().Run();

E para subir tudo:

aspire run

Um comando. Postgres, Redis, RabbitMQ em containers, três serviços .NET, um frontend Node — todos conectados com service discovery automático, logs centralizados no dashboard, health checks monitorados.

Service Discovery automático

Quando você faz .WithReference(postgres), o Aspire injeta automaticamente a connection string no serviço. Não precisa de appsettings.json com URLs hardcoded:

// No seu serviço, a connection string já está disponível
builder.AddNpgsqlDbContext<AppDbContext>("app-db");

O service discovery funciona tanto localmente (via environment variables injetadas pelo AppHost) quanto em produção (via configuração do target de deploy). Mesmo código, zero mudança.

Dashboard de observabilidade

Ao executar aspire run, o Aspire abre automaticamente um dashboard web com:

• Logs estruturados de todos os serviços em uma timeline unificada
• Traces distribuídos — siga um request da entrada no frontend até o banco
• Métricas — latência, throughput, erros por serviço
• Health checks — status de cada recurso e dependência
• Console de recursos — restart, stop, logs individuais

Isso elimina a necessidade de configurar Jaeger + Prometheus + Grafana + ELK separadamente para o ambiente de desenvolvimento. Em produção, você conecta ao seu stack de observabilidade existente via OpenTelemetry — o Aspire exporta traces e métricas no formato OTLP por padrão.

AppHost em TypeScript

Uma adição significativa das versões recentes: você pode escrever o AppHost em TypeScript, mantendo toda a orquestração idêntica:

// apphost.mts
import { createBuilder } from './.aspire/modules/aspire.mjs';

const builder = await createBuilder();

const db = await builder.addPostgres("db");

const api = await builder.addNodeApp("api", "./api", "server.js")
    .withReference(db);

const worker = await builder.addPythonApp("worker", "./worker", "main.py")
    .withReference(db);

await builder.addViteApp("frontend", "./frontend")
    .withReference(api);

await builder.build().run();

Isso abre o Aspire para times que não usam .NET como linguagem principal mas querem a orquestração — ex: um backend Node.js + worker Python + frontend React, todos orquestrados pelo Aspire.

Integrações disponíveis

O Aspire vem com integrações NuGet para os serviços mais comuns — cada integração cuida de container, configuração, health check e telemetria:

Categoria	Integrações
Bancos de dados	PostgreSQL, SQL Server, MySQL, MongoDB, Oracle, CosmosDB
Cache	Redis, Valkey, Garnet, Memcached
Mensageria	RabbitMQ, Kafka, Azure Service Bus, AWS SQS
Storage	Azure Blob, AWS S3, MinIO
Busca	Elasticsearch, OpenSearch, Meilisearch
Observabilidade	OpenTelemetry, Seq, Grafana, Prometheus
Cloud	Azure, AWS, GCP (recursos gerenciados)

Adicionar Redis ao seu sistema é literalmente uma linha:

var cache = builder.AddRedis("cache");
var api = builder.AddProject<Projects.Api>("api")
    .WithReference(cache);

O container sobe automaticamente, a connection string é injetada, o health check está configurado, e o dashboard mostra o status. Zero configuração manual.

Integração com AI Coding Agents

Um diferencial que surgiu nas versões mais recentes: o Aspire expõe um MCP server que dá a agentes de IA (GitHub Copilot, Claude, Cursor, Kiro) acesso estruturado ao modelo da sua aplicação:

aspire agent init

Com isso, o agente consegue:

• Entender quais serviços existem e como se conectam
• Acessar logs e traces em tempo real
• Descobrir integrações disponíveis
• Sugerir mudanças na topologia com consciência do sistema completo

Isso resolve o problema clássico de agentes que "veem fragmentos" — com o MCP do Aspire, o agente tem o mapa completo da arquitetura.

Aspire vs Docker Compose vs Kubernetes

A pergunta que todo mundo faz: quando usar cada um?

Critério	Docker Compose	Kubernetes	.NET Aspire
Tipagem	YAML não-tipado	YAML não-tipado	C#/TypeScript com IntelliSense
Service discovery	DNS por container name	DNS + Services	Automático, code-first
Observabilidade	Nenhuma built-in	Precisa instalar stack	Dashboard integrado
Curva de aprendizado	Baixa	Alta	Baixa (se sabe C#)
Deploy em produção	Limitado	Completo	Flexível (Azure, K8s, containers)
Auto-scaling	Não	Sim	Via target de deploy
Multi-linguagem	Sim	Sim	Sim (C#, Node, Python, Go, etc.)
Ideal para	Dev local simples	Produção em escala	Dev + produção para times ≤ 20 devs

O sweet spot do Aspire: times de 3-20 desenvolvedores com 3-15 serviços que querem a produtividade do Docker Compose com a consistência do Kubernetes, sem a complexidade operacional de nenhum dos dois.

Migrando do Docker Compose

Se você já usa Docker Compose, o Aspire tem suporte direto para migração. Você pode até referenciar um docker-compose.yml existente dentro do AppHost enquanto migra incrementalmente:

// Importa containers existentes do compose
builder.AddDockerComposeEnvironment("legacy", "../docker-compose.yml");

// Novos serviços já em Aspire nativo
var api = builder.AddProject<Projects.Api>("api")
    .WithReference(postgres);

A documentação oficial tem um guia completo de migração em aspire.dev/app-host/migrate-from-docker-compose.

Deploy para produção

O Aspire não é só dev local. O mesmo AppHost que roda com aspire run pode ser deployado:

# Deploy direto via CLI
aspire deploy

Targets suportados:

• Azure Container Apps — deploy nativo, zero config extra
• Kubernetes — gera manifests a partir do AppHost
• Docker Compose — exporta compose file para ambientes tradicionais
• Custom — extensível para qualquer target via pipelines

O ponto-chave: o modelo é o mesmo. Não existe "isso funciona local mas em prod é diferente". O AppHost é a single source of truth da topologia — muda o target de deploy, não o código.

Testando com Aspire

Um benefício menos óbvio: o Aspire simplifica drasticamente testes de integração. Você pode subir o AppHost inteiro (ou partes dele) em um teste:

public class ApiIntegrationTests
{
    [Fact]
    public async Task GetUsers_ReturnsOk()
    {
        // Sobe o AppHost com todos os recursos
        await using var app = await DistributedApplicationTestingBuilder
            .CreateAsync<Projects.AppHost>();

        await app.StartAsync();

        // Obtém o HTTP client com service discovery
        var client = app.CreateHttpClient("api");

        var response = await client.GetAsync("/users");
        response.EnsureSuccessStatusCode();
    }
}

O Aspire sobe containers reais (Postgres, Redis, etc.) para o teste, configura tudo via service discovery, e derruba ao final. Sem mocks de infraestrutura, sem Testcontainers manual — o próprio AppHost é o test fixture.

Quando NÃO usar Aspire

Aspire não é bala de prata. Cenários onde talvez não seja a melhor escolha:

• Monolito simples: se você tem uma API + um banco, Aspire adiciona uma camada desnecessária
• Time 100% serverless: funções Lambda/Cloud Functions não se beneficiam de orquestração local
• Organização com time dedicado de plataforma K8s: se K8s já está maduro e bem operado, Aspire compete em vez de complementar
• Proibição de containers em dev: Aspire depende de Docker/Podman para recursos de infraestrutura

Exemplo completo: sistema de e-commerce

Para materializar, vamos ver um AppHost realista de um e-commerce com 5 serviços:

#:sdk Aspire.AppHost.Sdk
#:package Aspire.Hosting.PostgreSQL
#:package Aspire.Hosting.Redis
#:package Aspire.Hosting.RabbitMQ
#:package Aspire.Hosting.Elasticsearch

var builder = DistributedApplication.CreateBuilder(args);

// Infraestrutura
var postgres = builder.AddPostgres("db")
    .AddDatabase("orders-db")
    .AddDatabase("catalog-db")
    .AddDatabase("users-db");

var redis = builder.AddRedis("cache");
var rabbit = builder.AddRabbitMQ("events");
var elastic = builder.AddElasticsearch("search");

// Serviços de domínio
var catalog = builder.AddProject<Projects.Catalog>("catalog")
    .WithReference(postgres.GetDatabase("catalog-db"))
    .WithReference(elastic)
    .WithReference(rabbit);

var orders = builder.AddProject<Projects.Orders>("orders")
    .WithReference(postgres.GetDatabase("orders-db"))
    .WithReference(rabbit)
    .WithReference(redis);

var users = builder.AddProject<Projects.Users>("users")
    .WithReference(postgres.GetDatabase("users-db"))
    .WithReference(redis);

var payments = builder.AddProject<Projects.Payments>("payments")
    .WithReference(rabbit)
    .WithReference(redis);

// BFF / Gateway
var gateway = builder.AddProject<Projects.Gateway>("gateway")
    .WithReference(catalog)
    .WithReference(orders)
    .WithReference(users)
    .WithReference(payments);

// Frontend
builder.AddNpmApp("storefront", "../storefront")
    .WithReference(gateway);

builder.Build().Run();

5 serviços .NET + 4 containers de infraestrutura + frontend React, tudo orquestrado, observável, e deployável com um único aspire run. Esse AppHost é auto-documentável — qualquer dev novo no time entende a arquitetura inteira lendo um arquivo.

Conclusão

O .NET Aspire preenche um gap real no ecossistema: a distância entre "Docker Compose para dev" e "Kubernetes para prod" era enorme, e times pequenos ficavam presos no meio — complexidade demais para um, simplicidade demais para o outro.

Com Aspire, você tem:

• Orquestração tipada e refatorável
• Observabilidade built-in sem stack externo
• Service discovery que funciona igual local e em prod
• Testing de integração trivial
• Deploy para múltiplos targets com o mesmo modelo
• Suporte a multi-linguagem e AI agents

Se seu time roda microserviços .NET (ou multi-linguagem) e está cansado de manter Docker Compose + scripts + configuração espalhada, o Aspire é a resposta que você estava esperando. Comece com curl -sSL https://aspire.dev/install.sh | bash e um aspire run — em 5 minutos você vai entender por que ele virou o assunto #1 da comunidade .NET em 2026.