Hard times with distributed applications? .NET Aspire to the rescue!

.NET 8 is finally here! And despite its coming with many cool new features, something caught my eye among the things presented in the preview section.

And that was .NET Aspire. Which is an opinionated, cloud ready stack for building observable, production ready, distributed applications. So, it can help a lot of pain point and problems if you build cloud-native applications.

Let us see what it offers for us!

Orchestration & Service Discovery

If you have worked with microservices and cloud-based resources, you must have realized that configuring them is not easy (especially not for a new developer in the team).

Orchestration refers to the coordination and management of various elements within a cloud-native application. .NET Aspire streamlines the configuration and interconnection of various parts of your cloud-native app. It provides useful abstractions for managing service discovery, environment variables, and container configurations without having to handle low-level implementation details.

You need to define the .NET projects, containers, executable files, and cloud-based resources that constitute the application. Aspire does the rest for us.

Without exact URLs, ports, and connection strings, we can simply identify our services with names and which services refer to each other (Similar to docker-compose files):

var builder = DistributedApplication.CreateBuilder(args);

var cache = builder.AddRedisContainer("cache");

var apiservice = builder.AddProject<Projects.MyTestApp_ApiService>("apiservice");

builder.AddProject<Projects.MyTestApp_Web>("webfrontend")
    .WithReference(cache)
    .WithReference(apiservice);

builder.Build().Run();
        

Components

The .NET Aspire components, available as NuGet packages, make it easier to connect to popular services like Redis or PostgreSQL. They handle various cloud-native concerns for you, such as setting up health checks and tracking system performance.

Every individual component is intricately tailored to seamlessly collaborate with the .NET Aspire orchestration framework. They possess the inherent capability to propagate their configurations across dependencies, guided by the relationships established within .NET projects and package references.

For example, consider the following code using the .NET Aspire Service Bus component:

builder.AddAzureServiceBus("servicebus");
        

The AddAzureServiceBus method performs these key tasks:

• Sets up a ServiceBusClient as a singleton within the Dependency Injection (DI) container to establish a connection with Azure Service Bus.
• Allows configuration of the ServiceBusClient either directly within the code or through external configuration settings.
• Activates specific health checks, logging, and telemetry functionalities tailored for the effective utilization of Azure Service Bus.

Project Templates & Tooling

The integration of Aspire tooling is now part of Visual Studio, accessible from VS2022 version 17.9 or higher (Preview 1) onwards.

Within the .NET Aspire offerings, two primary starter templates are available: a fundamental starter template (skeleton) and an advanced starter application encompassing boilerplate UI and API projects.

You’ll notice two new projects that you haven’t seen before <appname>.AppHost and <appname>.ServiceDefaults.

• The AppHost project operates to execute any necessary .NET projects, containers, or executables integral to establishing your distributed application.
• The ServiceDefaults project contains common service-centric logic that applies to each of the projects in the app. This is where cross cutting concerns like service discovery, telemetry, and health check endpoints are configured.

.NET Aspire templates also include boilerplate extension methods that handle common service configurations for you:

builder.AddServiceDefaults();
        

By adding this one line to your services, you will get the following:

• OpenTelemetry: Sets up formatted logging, runtime metrics, built-in meters, and tracing for ASP.NET (Opens in new window or tab) Core, gRPC, and HTTP.
• Default health checks: Adds default health check endpoints that tools can query to monitor your app.
• Service discovery: Enables service discovery for the app and configures HttpClient accordingly.

Dashboard

The goodness doesn't stops there! Launching the .NET Aspire starter application brings you the developer dashboard.

Code:

var builder = DistributedApplication.CreateBuilder(args);

var cache = builder.AddRedisContainer("cache");

var apiservice = builder.AddProject<Projects.MyTestApp_ApiService>("apiservice");

builder.AddProject<Projects.MyTestApp_Web>("webfrontend")
    .WithReference(cache)
    .WithReference(apiservice);

builder.Build().Run();
        

How it looks in the Dashboard:

The developer dashboard serves as your central hub for consolidating all diagnostic data during your development process. It allows you to address slowdowns and bugs encountered on your development machine. Importantly, it uses all the same open standards as you would use in production when you configure your production telemetry systems like Grafana+Prometheus, Application Insights, and others.

We have the ability to observe not just the Environment variables and logs of our .NET applications but also those of the corresponding running containers!

Summary

In my assessment, .NET Aspire appears to be a highly promising tool, particularly in streamlining local development across various scenarios. I intend to closely track its progress and development.

The article was written by Daniel Berki .

Resources

• .NET Aspire documentation
• Introducing .NET Aspire: Simplifying Cloud-Native Development with .NET 8
• GitHub