.NET Aspire: Bridging the Gap Between Application and Infrastructure

For years, application development and infrastructure management have operated in distinct areas. Developers focused on writing code, while operations teams handled underlying environment. Infrastructure as Code (IaC) emerged as a powerful solution, bringing consistency and version control to infrastructure provisioning.

Today .NET Aspire challenges these traditional boundaries, blurring the lines between application and infrastructure.

Understanding .NET Aspire

As Microsoft states, .NET Aspire is a set of tools, templates, and packages for building observable, production ready apps.

.NET Aspire application is considered as a set of cloud native applications who are tightly related to each other. It is up to you whether you want to build micro-services with it, or monolith applications which are sharing the core and the domain.

Basic idea is, you have multiple APIs, one frontend application and a couple of containers (e.g. Redis, PostgreSQL), and other integrations such as Azure Storage Account. You manage connection between them in one project called app host, which acts like orchestrator.

var builder = DistributedApplication.CreateBuilder(args);

var postgres = builder.AddPostgres("postgres");
var catalogDb = postgres.AddDatabase("catalogdb");

var basketCache = builder.AddRedis("basketcache");

var productsApi = builder.AddProject<Projects.Aspire_Products_Api>("productsapi")
    .WithReference(catalogDb);

var basketApi = builder.AddProject<Projects.Aspire_Basket_Api>("basketapi")
    .WithReference(basketCache);

builder.AddProject<Projects.Aspire_Frontend>("frontend")
    .WithReference(basketService)
    .WithReference(catalogService);

Upper code snippet clearly shows the idea behind .NET Aspire. We define database, cache and then we inject it in respective backend APIs for products and basket. Finally at the end, we inject backend APIs to the frontend application.

The frontend application itself doesn’t need to know the actual URL of the APIs, but it is enough to know the name of the services itself, e.g. productsApi or basketApi , for the actual integration.

builder.Services.AddHttpClient<ProductsApiClient>(client =>
    {
        client.BaseAddress = new("http://productsapi");
    });

Infrastructure in the app code?

While I am diving into the Aspire features and paradigm, I saw interesting tweet and code snippet from David Fowler showing how you can actually handle RBAC roles directly in the app:

And actually this post made me thinking where the boundary is between the Aspire and IaC. In David’s piece of code, we can only see infrastructural definitions of storage, blobs, API project with reference to the blobs, including role assignments.

Clearly, applications can manage themselves including the integrations to other services, containers and APIs, but also define the roles, boundaries and ways how to operate with another parts of the system.

This level of application-driven infrastructure requires careful attention to security, ensuring that access controls are properly implemented. Additionally, the need for orchestration between application-level and platform-level IaC becomes crucial.

Previously, all of those things were done exclusively through ARM templates, Terraform or Pulumi.

Where is the limit?

Going more into the depth of .NET Aspire context and idea, we can clearly see that choices are endless and more and more components are coming with each release. It is already possible to define api gateways on .NET level, and maybe Nginx is coming as a component in the future which will handle load balancing betwen the applications.

What is left for IaC tools to handle? Probably networking part, firewalls and low level infrastructure. IaC will make sure that the system is isolated enough and leave certain access points for public.

Whether this shift is welcomed varies. Many full-stack developers appreciate the increased control over the entire stack, including frontend, backend, pipelines, infrastructure. This way, it is definitely guaranteed.

What is my point?

.NET Aspire represents a significant shift towards application-centric infrastructure management. While platform-level IaC tools will continue to play a vital role in managing the broader infrastructure foundation, Aspire empowers developers to take greater control over their application’s runtime environment.

This paradigm shift requires careful consideration of security and orchestration, but it ultimately promises to streamline development workflows and enhance application resilience.

As cloud-native architectures evolve, we can expect to see further advancements in application-driven infrastructure, blurring the lines between code and environment.