Cloud-native application development with .NET Aspire and aspirate

After evaluating RedHat ODO, colleagues from the .NET universe happened to enlighten me about .NET Aspire and aspirate, setting me up for a short .NET adventure. This is a short post on how to locally develop a cloud-native distributed .NET Aspire application, iterating and deploying on a local Kubernetes cluster.

.NET Aspire includes the framework and tooling to bootstrap, develop and deploy distributed .NET applications developed for the cloud-native context. I learn that aspirate, a community tool, is being roped in into aspire to support the local Kubernetes deployment scenario. I tried to bootstrap a simple aspire application, iterate and deploy it locally.

So, lets see the steps followed in this small experiment.

Step 1: Install dotnet10

sudo apt update && sudo apt install dotnet10

Step 2: Install aspire and aspirate

dotnet tool install -g aspire.cli
dotnet tool install -g aspirate

Step 3: Create a basic Aspire project

Lets call it HelloWorldK8s.

aspire new aspire-starter -n HelloWorldK8s

At this point we start interacting with Kubernetes. I use the k8s snap and could not get it working with images from the local Docker daemon. I configured a local in-cluster container registry. Refer to these steps to install k8s and configure the registry.

Step 4: Initialize aspirate

cd HelloWorldK8s/HelloWorldK8s.AppHost && \
aspirate init -cr localhost:32000 --disable-secrets #cr - container registry

Step 5: Generate container images and Kubernetes YAML

aspirate generate --disable-secrets

On successful completion of the above command, you must find the container images pushed to the in-cluster container registry.

$ curl http://localhost:32000/v2/_catalog
{"repositories":["apiservice","webfrontend"]}

You must also find all the relevant YAML descriptors generated in the aspirate-output directory.

$ find ./aspirate-output/ -name "*.yaml"
./aspirate-output/apiservice/kustomization.yaml
./aspirate-output/apiservice/deployment.yaml
./aspirate-output/apiservice/service.yaml
./aspirate-output/kustomization.yaml
./aspirate-output/webfrontend/kustomization.yaml
./aspirate-output/webfrontend/deployment.yaml
./aspirate-output/webfrontend/service.yaml
./aspirate-output/dashboard.yaml

Step 6: Deploy

Finally, lets deploy the application.

aspirate apply --disable-secrets

The web front-end must now be accessible. We’d need to do port forwarding for the webfrontend service.

kubectl port-forward svc/webfrontend 8080:8080

Now open http://localhost:8080 in a browser to access the web frontend!

Step 7: Development iterations

Developers may make changes to the application and repeat steps 5 and 6. Before deploying I had the explicitly destroy the existing deployment.

aspirate destroy && aspirate apply --disable-secrets

Conclusion

I am evaluating different cloud-native development tools and the three metrics I use to grade them are:

1. How much Kubernetes complexity does the tool abstract away?

2. How much manual intervention (typing commands) does the tool get rid of, for development iterations?

3. How easy is it to clone a desirable application framework stack?

While aspirate does indeed abstract away a good amount of Kubernetes complexity, it does require considerable manual intervention in the development loops. Also, from a framework point-of-view, it is very specific to .NET. Furthermore, aspirate is being integrated into aspire and the future workflow of aspire is expected to be much better than the current one.

Thank you for reading on! Watch the screen-cast to view the complete workflow.