Each November, Microsoft unveils a major version of the .NET framework. And this year, the 2023 .NET Conference introduced .NET 8, the most significant upgrade yet, highlighting the pivotal role of .NET Aspire. From its humble beginnings over two decades ago, .NET has been steadily moving toward a vision of providing developers with a rich and powerful set of tools and services for creating software applications. Although originally .NET was focused on building applications that ran on the desktop, and to a lesser extent early web applications, today the focus is clearly on building powerful and fully-featured cloud native web apps that can run on Microsoft’s Azure cloud platform.¹
The big news from this year’s conference was a new offering called .NET Aspire. After reading this article, you’ll have a good idea of what Aspire is all about, and why it’s going to be an important addition to your developer toolkit.
What is .NET Aspire?
What does this .NET Aspire definition mean, exactly? Let’s pick this sentence apart:
- Opinionated: Microsoft has made some decisions about how to configure the various bits and pieces that will make up the final technology stack. Opinionated means these aren’t hard and fast rules, but rather a derived viewpoint about how things should be constructed in order to work well together.
- Cloud-ready: What you build with Aspire will be ready to be deployed in the public cloud. There’s no extra step to get an application ready to run in Azure or even AWS.
- Stack: This is a complete technology approach, not a single point solution. Stack implies both front-end (client) and back-end (server) code, as well as other stuff.
- Building: Aspire is focused on creating new distributed applications, although as we’ll see below, you can easily add Aspire to an existing application.
- Observable: Web apps need to be monitored and managed. Observability is the catch-all term for all the aspects of managing an app in real time, including telemetry, health, status, load balancing, user behavior and more.
- Production-ready: Aspire lets you build your apps and deploy them into Docker containers, easily setting up a successful push to production without the need for complex and fragile scripts.
- Distributed: Applications today are less frequently monolithic and more often distributed; they are a collection (if you will) of individual actors, whether API endpoints, serverless functions, web apps or databases. Historically, getting all those disparate pieces to work together seamlessly was a significant challenge — a single fail could break the whole system. Aspire is designed to prevent that.
At Growth Acceleration Partners (GAP), we summarize it this way:
Aspire is a set of tools and services to build an application, identify and connect various dependencies, publish to Azure in a container, and manage and monitor that app in production.
Why Aspire?
According to Microsoft, since the first release of .NET Core, the platform’s development has been focused on improving the process to create cloud native applications. By .NET 7 (in 2022), the platform included health checks, gRPC (global remote procedure call), support for container builds, native AoT (ahead of time compilation) and more.
But Microsoft also acknowledged that customers found the platform to be like a jigsaw puzzle, with little information about how to easily fit and configure the correct set of parts for their application. Things that should work together seamlessly either didn’t or required significant investigation and testing to work. Here’s some example feedback²:
Figure 1: .NET customer feedback
Native cloud applications are enormously complex, and developers today have to be able and ready to select not only which supporting libraries and services to use in their code, but also how to configure, integrate and verify all those disparate parts in a distributed application, without risking defects or failure in production.
With the widespread adoption of DevOps — a vital and important approach to building and running cloud native applications — developers have frequently felt overwhelmed with the need to develop expertise in a host of unrelated technologies. Look at these typical questions³:
Figure 2: Common developer issues for cloud native DevOps
Developers today are quite familiar with the following scenario: In the midst of writing an application, one encounters a simple question that is important for the application project, but requires knowledge the developer does not have. The current task is then suspended while the developer has to dive down a “rabbit hole” of learning and research on the new technical topic in order to answer the question. Sometimes that research also depends on additional knowledge about additional technologies, which require further digging. It is a form of “yak shaving” that can consume enormous amounts of precious time.
Microsoft’s answer to this dilemma is Aspire: an opinionated set of tools, components, services and sample code to jumpstart the development and publishing of cloud native applications.
It’s a full stack. Everything you need.
Let’s review the five things you need to understand Aspire.
- An Opinionated Components List
Reiterating the description above, Microsoft has made some choices as to the most appropriate components that can be added to an Aspire app. That isn’t restrictive; other components can be added as well. Here’s the list as it stands now:
Figure 3: Aspire Components List
Reviewing this list of initial components (to which Microsoft says they will be adding more over time), one sees a lot of critical services are available right away, including multiple database connections, Redis, Entity Framework, key management and more. While this might not be the exact list a given developer wants or needs for a specific project, it should handle most of the apps much of the time.
- Aspire Simplifies Orchestration
You could build a simple (i.e., non-distributed) application with Aspire, but that would be like using a one ton truck to pick up a single 2×4. Where Aspire shines is building and running distributed applications.
If Aspire were the kitchen, then orchestration would be something like mise en place, plus the recipe, plus the actual cooking of the dish. Some of the Aspire orchestration elements include:
- An app model that defines all the resources the application requires and their relationships
- An app host project in Visual Studio that is the traffic cop for all the applications and their projects used by the application
- Built-in resource types, which can be container images, .NET projects or executable files
- Connection strings and endpoint references, as Aspire supports both well-defined connection strings, as well as injecting environment variables to support service discovery
- Not the Same as Kubernetes
It’s important to understand Aspire is neither the same as Kubernetes, nor an alternative to Kubernetes. Indeed, an application might use both Aspire and Kubernetes.
.NET Aspire relies on orchestration and containers to deploy and run applications in the cloud. Kubernetes is a tool for managing clusters of containers running on multiple machines. Aspire can create a manifest list that can be used for deployment to Kubernetes.
Docker makes it easy to build, run and test an app locally, then push it to production by moving the container. Some connection strings will have to change to use production databases and services instead of test ones. But since you are actually moving the container tested locally, you know what is going to production is predictably correct. Containers are quick to spin up and easy to replicate, simplifying the process of adding and deleting hosting resources as demand changes, such as during an event like Black Friday for ecommerce sites.
Kubernetes, on the other hand, simplifies the process of managing all those containers, balancing user or customer experience (UX/CX) with cloud resources and subsequent hosting costs.
In short: build and run Aspire apps in Docker containers; use Kubernetes to scale and manage containers across the host environment.
- New Project Templates
.NET Aspire comes with two project templates for creating new production applications, or just learning how Aspire works:
- .NET Aspire application: This is a bare-bones Aspire application containing only the AppHost and ServiceDefaults projects (see below). This template is ideal if you either don’t want to build a Blazor app or already have another .NET app you want to use with Aspire.
- .NET Aspire starter app: This adds a simple “Hello world!” Blazor app to the .NET Aspire application template above. This is ideal for clean-sheet development, assuming you want at least one web app to be written in Blazor.
Creating a new Aspire .NET 8 application couldn’t be easier:
- From Visual Studio (requires Version 17.9 Preview or later), select File > New > Project and choose .NET Aspire Starter Application. Name your project and the scaffolding will be built in Visual Studio. You will need .NET 8 SDK and Docker Desktop installed on your development environment.
- Or, from a command shell, go to the directory where you want to create the project code and use the .NET CLI:
dotnet new aspire-starter --use-redis-cache --output AspireSample
Regardless of how you create your Aspire app, you’ll see two projects in the source tree that will be unfamiliar to first-time users.
Figure 4: Sample program in Visual Studio
AppHost
The AppHost project — identified as “[solution name].AppHost” — is the primary orchestrator for your application. The AppHost project will enumerate all the dependent projects in your application and build them as the starter project in your solution. For example, here’s the C# program⁴ from an AppHost project for an application with two projects and a Redis cache:
Figure 5: AppHost program example
As you add additional projects to your distributed app, they will appear here for orchestration. Aspire will handle all the dependencies and NuGet files needed. Additionally, connection strings and service bindings will be resolved here.
ServiceDefaults
The ServiceDefaults project (“[appname].ServiceDefaults”) brings a lot of the real power of Aspire to your application. A quick look at the default set of packages loaded gives a clue to what will follow:
Without any effort, our Aspire application is configured for telemetry, logging, metrics, analytics and more once it’s running on Azure. Again, this is Microsoft’s opinionated set of components, but you can add, delete or change as you desire.
Blazor
The alternative application template included with Aspire (“net aspire Starter App”) features a simple Blazor front-end web application. Blazor is an open-source web framework to build performant web applications using both HTML and C#. Similar to the original ASP.NET coding approach, where code styling with HTML and C# programming are intermingled, Blazor takes advantage of WebAssembly, a method to run .NET in the browser. Developers who are proficient in C# and .NET may find this approach to building rich web applications that avoid a lot of chattiness to be ideal.
Blazor is completely optional for Aspire applications. Any app written in .NET can be added to an Aspire solution.
- Developer Dashboard
Last, and perhaps most importantly, Aspire configures and launches a developer dashboard when you run your application, simplifying debugging. The dashboard contains logs, links to running web pages and containers, traces and more:
Figure 6: Basic Aspire Developer Dashboard
We can access our front-end web page by clicking the link to the running URL (running in http://localhost):
Figure 7: Sample home page
Perhaps more interestingly, however, is the available meta data on the running application. Clicking “Metrics” in the left menu gives access to quite a bit of data:
Figure 8: Some metrics available by default in Aspire
A full discussion of the data available in the Developer Dashboard would take more time and space than this blog post has room for. From this stage, however, it would be fairly simple to publish the application into a sandbox on Azure and run stress tests, watching the dashboard for signs of any issues that might surface once in a true multi-session host environment (as opposed to localhost).
Conclusion
.NET Aspire represents a major step forward to Microsoft’s goal of making .NET the most effective and trouble-free way to build cloud native apps. Aspire’s focus not only on the operational elements of applications but also on the actual building — including scaffolding, coding and debugging — will open the door to developers who want to take advantage of .NET, and help them over the otherwise difficult threshold of building great apps on the cloud.
For additional assistance or information, let GAP be your guide into this brave new development platform – contact us today.
¹ .NET applications are not constrained to Azure; rather they can run on any public or private cloud platform. However, some features may require Azure hosting.
² Source: .NET Conference 2023 “Building Cloud Native Apps with .NET 8”
³ IBID
⁴ Source: https://learn.microsoft.com/en-us/dotnet/aspire/app-host-overview
