6 ms·

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

36 points by dustedcodes 2y ago

tomalaci 2y ago
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.
- chokolad 2y ago
  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-developer-cli/ https://learn.microsoft.com/en-us/azure/developer/azure-deve...).
  - noworriesnate 2y ago
    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?
    - chokolad 2y ago
      > 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/manifest-format https://learn.microsoft.com/en-us/dotnet/aspire/deployment/m...
      - yodon 2y ago
        Yes, Amazon is actively working to support Aspire for AWS.
  - yodon 2y ago
    The associated aspir8 (aspirate) project handles deployment to k8s[0]. [0]https://github.com/prom3theu5/aspirational-manifests https://github.com/prom3theu5/aspirational-manifests
- phillipcarter 2y ago
  FWIW Pulumi is the standard for infrastructure as proper code: https://www.pulumi.com/ https://www.pulumi.com/
- noworriesnate 2y ago
  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/ https://www.pulumi.com/docs/languages-sdks/dotnet/ [2] https://testcontainers.com/ https://testcontainers.com/
  - zihotki 2y ago
    Pulumni is a great example of a leaky abstraction. Even yaml is better in some regards.
  - sbelskie 2y ago
    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.
- deleted 2y ago
  [deleted]
asabla 2y ago
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
okhudeira 2y ago
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.
- yodon 2y ago
  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.
  - dustedcodes 2y ago
    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.
    - davidfowl 2y ago
      That's how innovation happens.
ledgerdev 2y ago
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.

36 points by dustedcodes 2y ago

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.

chokolad 2y ago
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-developer-cli/ https://learn.microsoft.com/en-us/azure/developer/azure-deve...).
- noworriesnate 2y ago
  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?
  - chokolad 2y ago
    > 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/manifest-format https://learn.microsoft.com/en-us/dotnet/aspire/deployment/m...
    - yodon 2y ago
      Yes, Amazon is actively working to support Aspire for AWS.
- yodon 2y ago
  The associated aspir8 (aspirate) project handles deployment to k8s[0]. [0]https://github.com/prom3theu5/aspirational-manifests https://github.com/prom3theu5/aspirational-manifests
phillipcarter 2y ago
FWIW Pulumi is the standard for infrastructure as proper code: https://www.pulumi.com/ https://www.pulumi.com/
noworriesnate 2y ago
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/ https://www.pulumi.com/docs/languages-sdks/dotnet/ [2] https://testcontainers.com/ https://testcontainers.com/
- zihotki 2y ago
  Pulumni is a great example of a leaky abstraction. Even yaml is better in some regards.
- sbelskie 2y ago
  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.
deleted 2y ago
[deleted]

asabla 2y ago

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

okhudeira 2y ago

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.

yodon 2y ago
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.
- dustedcodes 2y ago
  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.
  - davidfowl 2y ago
    That's how innovation happens.

ledgerdev 2y ago

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.