General Availability of .NET Aspire: Simplifying .NET Cloud-Native Development | Hacker News Reader

General Availability of .NET Aspire: Simplifying .NET Cloud-Native Development

devblogs.microsoft.com

36 pointsdustedcodes23 comments

Been using preview versions of Aspire for a while now. At early stages there were a lot of bugs, but since preview 3 (or if it was 4) it's been pretty stable.

Adding services has also been really nice. I've even found my self not writing docker-compose files anymore.

Kind of hyped what upcoming versions of it will offer.

Be aware tho, be careful to use .Net 9 version of the packages as of now. They can be a bit iffy if you mix .net 8 packages with 9. It will probably be fixed very soon tho

Am I getting this right? With this you can actually write infrastructure as proper code? No more YAML?

If so I hope they succeed to make it popular so it spreads to other languages as well.

Kinda. At the moment it only does local orchestration, basically running stuff on your workstation. Sorta like docker compose, but in C# + a really nice Open Telemetry dashboard. For deployment it creates a manifest, which can be used to generate kubernetes Yamls, or deploy to Azure using azd (https://learn.microsoft.com/en-us/azure/developer/azure-deve...).

Interesting. The kubernetes yaml generation would be a pain--I don't want to keep my database or S3 in k8s but I do want to manage it via IaC.

Edit: looks like the k8s export is a community-supported tool, not official MS. Which begs the question, could other cloud providers add support for .NET Aspire?

> Edit: looks like the k8s export is a community-supported tool, not official MS. Which begs the question, could other cloud providers add support for .NET Aspire?

Nothing stops them from doing it. The manifest is documented https://learn.microsoft.com/en-us/dotnet/aspire/deployment/m...

Yes, Amazon is actively working to support Aspire for AWS.

The associated aspir8 (aspirate) project handles deployment to k8s[0].

[0]https://github.com/prom3theu5/aspirational-manifests

FWIW Pulumi is the standard for infrastructure as proper code: https://www.pulumi.com/

Infrastructure as code in C# is already supported by Pulumi[1]. However, developing anything significant requires a lot of copying values from one part of the stack to another, lots of magic strings and lots of combinations of parameters that don't work. Plus sometimes you choose a combination of parameters that works until your cloud provider upgrades Kubernetes or whatever and now that specific version of k8s isn't supported with the parameters you chose.

You have no control over your cloud provider's updates, there's TONS of trial-and-error in developing the stack, and often error messages are extremely unhelpful. Your cloud provider's UI is so much easier on the initial setup vs. infrastructure as code.

Then there's TestContainer[2], which is infrastructure as code but only for tests. The syntax is a lot more natural, but it only runs Docker containers which are automatically destroyed when the tests are complete.

It looks like .NET Aspire is the best of both worlds: a simple syntax that deploys local resources (replacing docker-compose.yml dev files) AND it also supports deploying cloud resources. Which is really great! Only downside is you're tied into Azure.

[1] https://www.pulumi.com/docs/languages-sdks/dotnet/

[2] https://testcontainers.com/

Pulumni is a great example of a leaky abstraction. Even yaml is better in some regards.

I don’t see anything about Aspire being Azure only. The docs specifically call out that it’s cloud agnostic, though Azure specific support appears to be a first class citizen.

I’m always weary of using abstractions like this. I understand the desire to simplify the process of creating new apps, but tools like this take an opinionated stance on how to couple and interact with all of these dependencies like Npgsql, meaning you might end up stuck with an older version of Npgsql until your Aspire package catches up.

Developers are also abstracted one more layer from their dependencies which isn’t always a good thing when debugging or for understanding how the dependencies work.

The manifest file seems like a step in the wrong direction. I see no reason to learn this .NET specific thing when I can learn to use docker-compose or the like.

The otel dashboard is nice but there are alternatives.

Having used Aspire during pre-release, it's so nice as a developer to be able to work on deployments in a real programming language where I can set breakpoints and right-click down into the code to see what's going on.

I'm definitely never going back to working in opaque yaml-variants that can't make up their mind about whether they want to be a programming language or not.

People were already doing that with PowerShell and as you'd expect, from a very complicated language which lets you do many things in very complicated ways, absolutely nothing good came out of it.

Then people started to migrate to YAML, because although it's tedious, it's actually very dumb and the declarative nature of it keeps things very very simple. Sure the domain it is applied to is complex but infra will always be complex.

It looks like we are just going in circles. Now people think that using a complex language to build complex infrastructures is a good thing again, until they use it in anger then get burnt and then they will arrive at the next YAML variant in 10 years.

That's how innovation happens.

> It looks like we are just going in circles.

That's what our industry does :)

> I’m always weary of using abstractions like

weary = tired/fatigued

wary = not trusting, on guard against danger

Contextually, it looks like you probably mean the latter.

Thanks. I did mean the latter or maybe the wariness has turned into weariness!

If I understand correctly, the benefit of using this over something like Compose is the parity with production.

In my experience Compose is great for local development, but doesn't hold up well for complex architectures in production.

I work for a company [0] building something similar, but mostly agnostic to programming language. One thing I particularly like about the approach is the reduction of time debugging pipeline issues. I find increasingly that that is where my time goes -- most unfortunate.

0. https://noop.dev

Aspire doesn't provide parity with production. Locally it has its own container host and production deployment is outside of Aspire. Aspire has a bit more flexibility to run things that are not containers.

This is great!

Aspire has a code-based application model that is used to represent your application (or a subset of your application) and its dependencies. This can be made up of containers, executables, cloud resources and you can even build your own custom resources.

During local development, we submit this object model to the local orchestrator and launch the dashboard. This orchestrator is optimized for development scenarios and integrates with debuggers from various IDEs (e.g. VS, VS code, Rider etc, it's an open protocol).

For deployment, we can take this application model to produce a manifest that (which is basically is a serialized version of the app model with references). Other tools can use this manifest to translate these aspire native assets into deployment environment specific assets. See https://learn.microsoft.com/en-us/dotnet/aspire/deployment/m...

This is how we support Kubernetes, azure, eventually AWS etc. Tools translate this model to their native lingua franca.

Longer term, we will also expose an in-process model for transforming and emitting whatever manifest format you like.

You can update dependencies on your own. The model is quite extensible and nuget is great. You can override container image tags, or any settings we default to. That's the great part about using code!

So I have not yet tried out this aspire, but my gut feeling (as a long time dotnet dev) is that this will turn into a tangled web of complexity down the road.

Reply on news.ycombinator.com