aspire dotnet 8 instant cloud native apps

.NetAspire promises to be a genuine break-through in cloud-native development.

The recent production release of .Net 8 co-incided with the release of an Alpha version of Aspire. Aspire is a framework for making cloud-native app development and deployment easier.

The goals of this project are not small since cloud-native development is acknowledged to be very difficult, due to the large number of moving parts, comprising both applications and services. Therefore, I had a healthy sense of scepticism prior to using the technology. Firstly, would the technology itself be so complex that it would be unusable? Secondly, would it be so flaky that it would be unusable?

Since this is an Alpha version, I expected the worst. Alpha versions still fill me with dread, as in the past they have broken my computer, forcing a re-build and re-install of everything.

To use an Alpha version of technologies like Aspire there is a Pre-Release version of Visual Studio. So I updated that and Aspire was installed.

The sample template in Visual Studio worked locally without any hitches. I then followed the commands to deploy the Apps to an Azure Container Environment using AZD. For those that aren't familiar with it, AZD is the short name for the Azure Developer CLI (which is a different and far more powerful technology to Azure CLI).

The real test of course was whether I could extend the sample applications quickly to create cloud-native applications for my own purposes. From previous experience of Alpha version software and of AZD, I expected to hit a brick wall fairly early on. However, everything I tried worked almost first time including adding another service in the API, adding a new screen in the Blazor App and calling the new service in the API, and finally adding another API project and calling it from another new screen in the Blazor App.

Then I ran AZD to push everything to Azure including the completely new App. This also worked perfectly including communication between the new API and the Blazor front end, without any additional Azure configuration.

So what did I end up with? All applications including the one I added used best practices for Http communication, including retry policies, had logging and Open Telemetry built in, and had commonly used telemetry metrics configured.

Also, since the apps were deployed to an Azure Container App environment, Kubernetes, including auto scaling was configured, meaning as traffic increased so would the number of instances of each App.

To create a working set of cloud-native applications, that could be deployed to the cloud in a single click, all that would be required is to add any additional Apps and Components (eg ServiceBus, Queues etc), and then to add business logic into those Apps.

Looking forward to the production ready version towards the middle of the year.