Why net.aspire if there are industry standard feature-complete tools already available?

[gitvadim]

Can someone please explain Aspire's purpose to me and what problem it is aimed at solving?
The reason I'm asking is because there are already industry standard tools available for pretty much everything that Aspire's documentation promises. i.e.:

• Orchestration: docker compose is what everyone is using. It can easily be repurposed to deploy to Kubernetes or to any other stack for that matter
• Service discovery: while I appreciate having an abstraction over this concept, the same docker compose offers native service discovery that works out of the box in Kubernetes and, if you need something more sophisticated, there are tools like Consul that you can use.
• Tracing and Telemetry: OpenTelemetry is something that can already be used in .NET.
• Observability: Grafana, Jaeger, Prometheus have it all figured out.

All of the above runs in docker compose on any machine that can run docker, uses easy to understand syntax for configuration files, works with visual studio, supports debugging and can be deployed to most if not all platforms. Not only that, these tools are universal and are not tied to .NET and can be used with any modern language/framework out there.
Why is there a need for a yet another framework to do what's already being done very well by everyone else? Perhaps we could be better off with an opinionated project template that has all of the above preconfigured and a bunch of supporting dlls providing the missing abstractions?

[davidfowl]

Orchestration: docker compose is what everyone is using. It can easily be repurposed to deploy to Kubernetes or to any other stack for that matter

Docker compose is excellent but is unproductive when all you want to do is run several projects or executables. Docker compose requires developers to build container images, and run inside of containers. That's a barrier when I just want to run my front end, backend, workers and a database. You don't need to learn anything else beyond what you already know.

Just imagine trying to call your back-end API from your front-end API (using a simple http://backend url) and having to under docker compose in order to enable that? It's too much.

Also code >> yaml. Docker compose gets complex once you attempt to do any form of abstraction or composition (see the old eshopOnContainers base directory https://github.com/dotnet-architecture/eShopOnContainers/tree/dev/src). Environment variable replacements (and includes), no types or IntelliSense, hard to reason about what exactly is running (and good luck debugging!). We think we can produce a better experience that's easy to get started and scales up to something like compose using a real programming language (very pulumi like but for the developer experience!)

Service discovery: while I appreciate having an abstraction over this concept, the same docker compose offers native service discovery that works out of the box in Kubernetes and, if you need something more sophisticated, there are tools like Consul that you can use.

The service discovery APIs are an abstraction that works with various providers (like Kubernetes and consul). One of the big advantages is that it works locally, and is backed by .NET's IConfiguration abstraction. This means you can implement service discovery across your compute fabric in a way that doesn't result in code changes. What happens to your application code if you have multiple kube clusters or services on app services, azure functions, ECS etc? Do I have to fundamentally change it to make it work locally, in a single cluster or across multiple? Well, no you don't. That's the benefit of the abstraction.

Tracing and Telemetry: OpenTelemetry is something that can already be used in .NET.

We didn't invent, this, aspire takes a big bet on .NET's integration with OpenTelemetry. Have you watched the videos? Our dashboard is a standard OTLP server that visualizes various telemetry data. Leaning on these open standards makes it very easy to build these things without breaking compatibility with the broader ecosystem.

Observability: Grafana, Jaeger, Prometheus have it all figured out.

Sure. We have a great sample showing how you can use them together! https://github.com/dotnet/aspire-samples/tree/main/samples/Metrics (well this is grafana and prometheus).

All of the above runs in docker compose on any machine that can run docker, uses easy to understand syntax for configuration files, works with visual studio, supports debugging and can be deployed to most if not all platforms. Not only that, these tools are universal and are not tied to .NET and can be used with any modern language/framework out there.
Why is there a need for a yet another framework to do what's already being done very well by everyone else? Perhaps we could be better off with an opinionated project template that has all of the above preconfigured and a bunch of supporting dlls providing the missing abstractions?

Because we can build a better developer experience. While everything is possible today, it's not easy. The entire cloud native ecosystem is built around tying various lego pieces of CNCF software together to build a stack (unix philosophy). You can think of aspire as trying to do the same thing, using what we've come to understand about the cloud native space and picking some opinions (in ways that use the same building blocks). I think one novel thing about how we're building various pieces of the stack is that we're really not making it a "walled garden". As people play with it more, they'll realize how composable and extensible it is (in fact I'm counting on it!).

Why is there a need for a yet another framework to do what's already being done very well by everyone else? Perhaps we could be better off with an opinionated project template that has all of the above preconfigured and a bunch of supporting dlls providing the missing abstractions?

Aspire isn't a framework. Perhaps the most controversial part of it is the DistributedApplication APIs that are a way to build up the orchestration model in any .NET based language. The rest of it is already what you're describing.

I look forward to more feedback!

[gitvadim]

Thank you for such a good explanation. It does really help put things in perspective. Now I see that my confusion came from this article https://devblogs.microsoft.com/dotnet/introducing-dotnet-aspire-simplifying-cloud-native-development-with-dotnet-8/ and the example I looked at: https://github.com/dotnet/eShop/blob/main/src/eShop.AppHost/Program.cs.

I looked at the AppHost there and couldn't see any dependencies besides the ones used by the code in the project, which made me assume that all that extra plumbing like tracing, dashboards and service discovery was being reinvented by Aspire. Something that docker compose is very explicit about.

But I am glad that under the hood it's all the same tools albeit orchestrated in a different, more .net friendly, way.

[hades200082]

My question on this after reading the responses is - why can't Aspire have options to generate those orchestration files that are already industry standards? docker-compose, etc.?

Doing so would broaden the use case of Aspire to allow developers to host their orchestrated application stacks anywhere that supports these existing technologies.

In its current form, this feels very much like MS is trying to create something to further lock .Net devs into the Azure ecosystem rather than something that's needed.

[davidfowl]

My question on this after reading the responses is - why can't Aspire have options to generate those orchestration files that are already industry standards? docker-compose, etc.?

It does! https://github.com/prom3theu5/aspirational-manifests generates docker compose and k8s manifests from the aspire manifest. This was always the plan, we just had to make sure the model we were building could even do it (in a reasonable reliable way).

[hades200082]

@davidfowl Thanks for the reply. I do like the look of Aspire... I just have some small issues that I think prevent it from being production-ready.

Looking into Aspir8 it seems as though the docker-compose capabilities are limited - it can't use secrets?

Additionally, Aspir8 also looks like a 3rd party solution to something lacking in the core of Aspire.

From all the videos and documentation I've seen about Aspire it sounds as though Aspire already has all the information it needs to know what the services & containers are - indeed it already creates them when running locally. Why can't that just be extended to create the relevant compose file automatically.

In "ye olden times" we had a simple "right-click -> publish" approach to deploying apps from Visual Studio - either using local folder publish or publish profiles and web-deploy.

Why can't Aspire be that simple?

In the ideal world looking at today's hosting landscape I'd expect something like Aspire to automatically produce a production-ready docker-compose or kubernettes manifest (configurable per solution) on publish... or even just have it create and update that file on-build.

That way, we developers could commit out changes to git, let our CI/CD pull those changes, build the solution and push it to our host of choice. There are many hosts out there that use docker-based deployments (Railway, Coolify, etc.) and others that use Kubernettes based deployments in a similar way. They mostly just need a docker-compose.yaml (or dockerfile for simpler apps) in the repo to manage the deployment.

[davidfowl]

We'll get there, but we're not there yet.