Hace un par de años publiqué una introducción a .NET Aspire cuando acababa de ser lanzado. Si vuelves a leer aquel post hoy, vas a ver lo mucho que ha cambiado. Por aquel entonces era un orquestador para levantar dos APIs y un Redis en local, todo súper acoplado a .NET y con un dashboard que era casi un experimento.
Aspire en 2026 no se parece en nada a aquello. Ya no es "una utilidad guay para microservicios .NET en local". Es una plataforma de orquestación que soporta múltiples lenguajes, con un sistema de telemetría serio, integraciones nativas con prácticamente cualquier recurso que uses en producción y, lo más importante para mí, es la herramienta con la que trabajo todos los días en mi día a día laboral. No es un juguete de demo, es lo que arranco cuando trabajo en cualquier proyecto en la empresa.
Tabla de contenidos
Vamos a darle un repaso a dónde está hoy y por qué deberías trabajar con el.
1 - Donde entra Aspire para desarrollo en 2026
Si nunca has tocado Aspire seguramente tu forma de desarrollar aplicaciones sea tener que importar una solución con cinco servicios, una base de datos, un redis, algún sistema de colas como RabbitMQ, y luego cada servicio en un lenguaje de programación para tener un front end en React.
En estas situaciones suele haber dos opciones: o lo tienes todo instalado en tu máquina de forma nativa, o lo tienes todo en contenedores con docker-compose, el cual es relativamente difícil de mantener ya que hay mucho tema de configuraciones y tal, Todo explicado en un readme con 250 millones de pasos.
Aquí es donde entra aspire, combinando todo ese boilerplate en un único proyecto. Aspire es una aplicación normal de C# que al arrancar lanza un proceso de supervision el cual va a gestionar el ciclo de vida de cada recurso que necesita, va a levantar contenedores, arrancar procesos, inyectar variables, tiene service discovery ya integrado y posee un dashboard que te lo junta todo y te lo muestra muy bonico usando OpenTelemetry.
Cuando configuras cada servicio, puedes indicar quién depende de quien, así todo se monta en sincronía y de forma correcta.
1.1 - Configuración y orquestración como código
Absolutamente todo se configura dentro del apphost, y la realidad es que la estructura recuerda a lo que era el docker compose, pero claro, estamos montando infraestructura, así que va a ser parecido seguro. Así es como luce en nuestro ejemplo:
var builder = DistributedApplication.CreateBuilder(args);
var postgres = builder.AddPostgres("postgres")
.WithLifetime(ContainerLifetime.Persistent)
.WithDataVolume()
.WithPgAdmin();
var productsDb = postgres.AddDatabase("productsdb");
var cache = builder.AddRedis("cache")
.WithLifetime(ContainerLifetime.Persistent)
.WithDataVolume()
.WithRedisInsight();
var messaging = builder.AddRabbitMQ("messaging")
.WithLifetime(ContainerLifetime.Persistent)
.WithDataVolume()
.WithManagementPlugin();
var storage = builder.AddAzureStorage("storage")
.RunAsEmulator(e => e.WithLifetime(ContainerLifetime.Persistent).WithDataVolume());
var blobs = storage.AddBlobs("blobs");
var api = builder.AddProject<Projects.AspireApp_Api>("api")
.WithReference(productsDb)
.WaitFor(productsDb)
.WithReference(cache)
.WaitFor(cache)
.WithReference(blobs)
.WaitFor(blobs)
.WithExternalHttpEndpoints();
builder.AddNpmApp("frontend", "../react-app")
.WithReference(api)
.WaitFor(api)
.WithHttpEndpoint(env: "PORT")
.WithExternalHttpEndpoints();
builder.AddExecutable("outbox-worker", "go", "../go-worker", "run", ".")
.WithReference(productsDb)
.WaitFor(productsDb)
.WithReference(messaging)
.WaitFor(messaging);
builder.Build().Run();Tenemos una API en C# y un front End en react , el caso de uso es sencillo, simplemente leer y listar productos, pero también tenemos una caché en Redis, la base de datos para tener toda la información, junto a blobstorage para las imagenes y RabbitMQ para los eventos a otros dominios a través del patrón outbox y un worker escrito en Go que lee cada dos segundos y publica el evento en rabbitMQ.
NOTA: Si quieres saber más sobre sistemas de eventos, consistencia o sistemas distribuidos en general recuerda que tengo mi libro a la venta “Construyendo sistemas distribuidos” donde aprenderás de estos temas y muchos más, todos relevantes al mundo laboral lo puedes encontrar aquí-> https://www.netmentor.es/libros/construyendo-sistemas-distribuidos
Y de la misma forma que puedes correr todo en tu máquina local lo puedes hacer en una pipeline para los test o generar manifests para kubernetes o docker compose para ser utilizado en producción.
1.2 - Aspire ya no es sólo .NET
Te habrás dado cuenta en el punto anterior de que no estamos configurando únicamente aplicaciones C# sino un backgroundworker en go o el front en Javascript, pero esta configuración no se limita a tener aplicaciones configuradas si no que el propio aspire es posible configurarlo en typescript si todo tu stack está en javaScript, pero no solo eso, también hay una confirmación medio oficial de que estará disponible en python, rust, Go y Java!
Lo que son noticias brutales para los desarrolladores en esos ecosistemas porque así no están obligados a aprender o mantener C# por un single fichero de infraestructura.
1.3 - Integración con la infraestructura de Azure
No soy especialmente azurero, lo digo abiertamente (aunque trabajo con el). Pero hay que reconocer que si tu producción vive en Azure, las integraciones nativas son brutales.
En el ejemplo que estamos trabajando en este blog, con BlobStorage.
Vamos a centrarnos en el lado de la API, donde lo tenemos configurado de la siguiente forma:
builder.AddAzureBlobServiceClient("blobs");
Si vas a la librería que implementa el método AddAzureBlobServiceClient está en la librería de Aspire: Aspire.Azure.Storage.Blobs, y con este mismo código nos conectamos a blob storage corriendo en local a través de azurite y en el cloud de azure únicamente cambiando la connection string una vez esté desplegado. Lo cual es brutal, obviamente si no trabajas con azure pues lo ignoras, pero si trabajas con azure es una ventaja evidente.
2 - Telemetría integrada por defecto en Aspire
Este es un punto crucial, quizá uno de los más importantes porque todo lo que arranca del Aspire Apphost emite telemetría con logs, traces y metrics hacia el endpoint de otel del dashboard todo sin configurar nada, de serie.
Puedes pensar que si, que muy bien pero es una herramienta local, la cosa no acaba ahí porque al utilizar OpenTelemetry únicamente tienes que cambiar el endpoint por el tuyo de producción para que esa misma telemetría apunte directamente a tu servidor de producción.
La telemetría, o bueno los traces distribuidos, puede ser uno de los pilares fundamentales que todo desarrollador tiene para crecer en su carrera, ser capaz de identificar un trace completo de una request o de una acción de un usuario. Sin unas traces distribuidas es prácticamente imposible ver qué es lo que sucede, en aspire, lo tienes en el dashboard, todo enlazado y relacionado de serie.
3 - Cuándo NO usar Aspire
Antes de acabar, mencionar que pese a que Aspire es una tecnología brutal, sobre todo en empresas, quizá no sea lo que quieres utilizar siempre, no es una solución única que te va a arreglar todo, hay en situaciones donde no cuadra.
Por ejemplo, funciona de maravilla en local, pero no puedes pedir que el apphost se ejecute en producción.
Es trabajo extra, más configuración más ficheros o más complicaciones en general que si tu proyecto tiene únicamente una base de datos y la api pues no te renta, te empieza a rentar cuando tienes varios servicios o aplicaciones de las que dependes.
La dependencia en C# o TypeScript, es obvio que si quieres usar aspire en la actualidad tienes que utilizar uno de estos dos lenguajes y aunque han prometido más, tienen que llegar, pero por ahora está limitado a esos lenguajes o entornos, así que la gran mayoría de personas aún no conocen Aspire, lo que no si es bueno o malo.
Conclusión
Mis primeras impresiones de Aspire no fueron las mejores, estaban bien, pero sin más. Durante estos más de dos años ha evolucionado muchísimo y es algo a mencionar.
Recomiendo a todo el mundo que le dé otra oportunidad. La distancia entre aquello y lo que es hoy es enorme: telemetría seria, integraciones con casi cualquier recurso, dashboard maduro, y un modelo de deployment que empieza a tener sentido.
Personalmente utilizo Aspire a diario en el trabajo, y simplemente este post es para ilustrar a quienes no usan lo que se están perdiendo.
