Evaluate integrating .NET Aspire for Dev-time orchestration and observability

[nanotaboada]

Description

Our current development workflow is containerized via Docker and Compose, but lacks a cohesive orchestration layer tailored for .NET services. As the architecture grows, managing service dependencies, observability (traces, metrics, logs), and local debugging becomes increasingly complex.

.NET Aspire offers a .NET-native orchestration and diagnostics platform for development-time, which could streamline the setup of service dependencies (e.g., databases, caches, telemetry collectors) while providing built-in support for OpenTelemetry and diagnostics dashboards.

This issue is to investigate and document the potential benefits, drawbacks, and integration approach for Aspire in our project.

Proposed Solution

Evaluate .NET Aspire as a local development orchestrator that:

• Runs our existing ASP.NET Core Web API project alongside other dev-time dependencies
• Provides OpenTelemetry-based tracing, metrics, and logging integration
• Offers a local dashboard for diagnostics and service health
• Simplifies service discovery and configuration without requiring full Docker Compose setups
• Remains compatible with our Docker/Compose-based deployment strategy

Suggested Approach (The How)

1. Scaffold a Minimal Aspire Setup

• Add a new .NET Aspire AppHost project to the solution
• Reference the existing Dotnet.Samples.AspNetCore.WebApi project from AppHost
• Define the Web API project as a service using AddProject(...)

var builder = DistributedApplication.CreateBuilder(args);

builder
    .AddProject<Projects.Dotnet_Samples_AspNetCore_WebApi>("webapi")
    .WithOtlpExporter("http://localhost:4317");

builder.AddOpenTelemetryCollector();
builder.AddZipkin();
builder.AddDashboard();

builder.Build().Run();

2. Add Local Observability Tools

• Add an OpenTelemetry Collector resource to the AppHost
• Add a Zipkin or Jaeger exporter
• Enable Aspire’s built-in dashboard (AddDashboard())

3. Run Services Locally

• Run the AppHost using dotnet run to validate orchestration and tracing
• Confirm Web API logs and traces appear in dashboard and OTEL backend

4. Assess Compatibility with Docker

• Validate that the Aspire-based workflow can interoperate with Docker containers (e.g., for database or message queue)
• Optional: Replace Docker Compose for dev-time scenarios

Acceptance Criteria

• A minimal Aspire AppHost project is scaffolded and builds successfully
• The Web API runs under Aspire and is accessible at a known port
• Aspire dashboard shows Web API service status
• OTEL traces are exported and viewable in Zipkin or Jaeger
• README or internal doc is updated with findings on:
  • Benefits and tradeoffs of Aspire
  • Compatibility with current Docker-based setup
  • Recommendations for adoption (partial or full)