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
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.
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...).
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.
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.
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.
[+] [-] asabla|1 year ago|reply
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
[+] [-] tomalaci|1 year ago|reply
If so I hope they succeed to make it popular so it spreads to other languages as well.
[+] [-] noworriesnate|1 year ago|reply
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/
[+] [-] chokolad|1 year ago|reply
[+] [-] phillipcarter|1 year ago|reply
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] okhudeira|1 year ago|reply
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.
[+] [-] yodon|1 year ago|reply
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.
[+] [-] noop_joe|1 year ago|reply
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
[+] [-] dragonwriter|1 year ago|reply
weary = tired/fatigued
wary = not trusting, on guard against danger
Contextually, it looks like you probably mean the latter.
[+] [-] davidfowl|1 year ago|reply
[+] [-] ledgerdev|1 year ago|reply