[noop_joe]

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

[davidfowl]

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.

[liammclennan]

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.