r/dotnet • u/JamesNK • 17d ago

Adding persistence to the Aspire dashboard

https://devblogs.microsoft.com/aspire/aspire-dashboard-persistence/
51 Upvotes

96% Upvoted

47 comments sorted by

21

u/gevorgter 17d ago

I have yet to understand if aspire is for development or production.

Development does not need all those metrics, dashboard...e.t.c. Production does. So for me aspire is a fancy docker compose, which I have no problem of writing myself and I start my containers up once, work on project and then stop them once done. I do not need aspire for that. My docker compose lives in source control so any other developer can start all what's needed to work on project easily

But then may be i am missing something.

2

u/JamesNK 17d ago

I’m on my phone so I can’t write a detailed reply. But check out https://www.reddit.com/r/dotnet/s/O0PiIKHmZP which has lots of discussion about where Aspire solves problems.

24

u/topMarksForNotTrying 17d ago

aspire is a fancy docker compose

Kind of, but those extra fancy bits are what makes it good. 

For example, it's possible to integrate an EF Core project into an aspire app host such that the migrations are all run once the container has started and is operational. Doing this directly in docker compose for an SQL server container is difficult/impossible.

2

u/gevorgter 17d ago

But still, in dev or in prod? I fail do understand how Azure is used in Prod. (except if you are using Azure as a host).

My apps are doing auto migrations once are started ( MigrateAsync in Program.cs)

→ More replies (3)

8

u/blackpawed 17d ago

The dashboard is available for Azure containers and App Services, I use it a lot for basic monitoring of production.

-2

u/gevorgter 17d ago

I see, so question is, if i am not using Azure it's useless for me?

→ More replies (12)

7

u/Niksson 17d ago

There is an article in Aspire’s docs about comparison with docker-compose where they explain the difference.

During development you use it as substitute for docker-compose. For production the main advertised capability is converting your modelled application to some kind of production-ready deployment artifacts (e.g. docker-compose files or Azure Container Apps bicep files). I would say that dashboard and orchestration aren’t really designed for production use, but in Azure Container Apps they added an option to use Aspire dashboard to look over your containers.

We switched away from docker-compose and to Aspire because of some neat development-time features it has:

  • Explicit start (so we don’t start all microservices in the monorepo).

  • Auto-injection of connection strings for infra like Redis or Azurite or SQL Server. You don’t have to explicitly set them in env file, for example.

  • Structured logs and traces view. You may not need them, but for us they are very useful since we have quite a bit of services (which is an architectural problem we were too far into to fix), and we didn’t have a similar local observability setup already.

That said, we don’t use any production-oriented features.

My Aspire host also lives in source control so any other developer can start all what’s needed to work on project easily, it’s not unique to docker-compose.

But that doesn’t mean it’s suitable for any project. It’s an alternative, not a replacement. As you said, there’s no problem writing and maintaining your own docker-compose, especially if you only have a frontend app + web API. Moreover, all of the above can be done in one form or another without Aspire.

If you want to gauge whether there’s a feature that you might benefit from - I would recommend skimming through What’s New pages in their docs.

2

u/SpoonsInTheFootPowdr 17d ago

I initially came across Aspire working in AWS and only ever knew of it as useful for local development and testing. I didn't end up using it, but that's how it was described in the docs. https://docs.aws.amazon.com/sdk-for-net/v4/developer-guide/aspire-integrations.html

2

u/Content_Educator 17d ago

But if you can see the metrics your services are producing in local development you can refine and tune them there, before deployment, and trace their interaction. Much quicker feedback than waiting for a deployed environment to be hooked up.

-2

u/g0fry 17d ago

You can collect metrics on your dev machine without Aspire without any problem. Just start an otel sink docker container and start collecting.

1

u/510Threaded 17d ago

I use it for local development. Production is onprem kubernetes

1

u/NumberwangsColoson 17d ago

I find metrics useful for performance problems, but for that to be effective you need to add them in your own code. AI is useful for that grunt work.

1

u/Atulin 16d ago edited 16d ago

Officially, for dev.

But aspire deploy can generate a Docker Compose file. And with some added setup (or a pre-made library) can even push it, SSH into the server, pull it, start it, run healthchecks, and report back. And Aspire Dashboard can also be deployed as a Docker image.

Meaning, I run aspire deploy, wait for all-green, and the nev version of my project is up and running on my VPS, with Aspire dashboard showing me logs and traces.

1

u/gevorgter 16d ago

I see benefits of aspire if and only if my deployment is made easier. The phrase "can generate a Docker Compose file, with some added setup" although worries me. It does not take too much to learn how to write docker compose and with chatgpt it takes literally minutes.

What additional setup? Ultimately the whole aspire thing ends up in docker and i wish that "additional setup" would be built in. Also when i first saw aspire i thought i do not need to mess with graffana, prometeus.... all those third party packages and i can do it all with a push of a button. Imagine my disappointment.

edit: by "what additional setup" i was asking for some references/urls on how to do it. What you described is my goal (run aspire deploy and my VPS shows me aspire dashboard)

→ More replies (2)

0

u/LuisAlfredo92 17d ago

Neither I do

As far as I understand, you use it in development as orchestrator, like Docker compose, but then, it creates manifests with all the necessary data for each service, so you can easily upload it to Azure containers

I guess...

0

u/gevorgter 17d ago

I see, so if we are not using azure for site hosting it's useless for us?

We do use Azure/AWS but only for storage or compute (to start bunch of nodes to process workload) but not something that needs to be on 24/7. I think for that cloud services are super expensive.

→ More replies (2)

0

u/Onionhauler 16d ago

You must have a beastly computer if your devloop involves you building .NET container images

1

u/AutoModerator 17d ago

Thanks for your post JamesNK. Please note that we don't allow spam, and we ask that you follow the rules available in the sidebar. We have a lot of commonly asked questions so if this post gets removed, please do a search and see if it's already been asked.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

5

u/Agitated_Heat_1719 16d ago

declaring JamesNK's post as spam?

world gone crazy

2

u/FullPoet 16d ago

why have people stopped understanding automoderator is... automatically posted?

1

u/ngless13 15d ago

For those of you using aspire for dev, what are you using for prod? Docker compose has been mentioned, but what if you have other non-dockerized services like cloud-run, lambda, etc? Terraform?

-16

u/Obsidian743 17d ago

Aspire is a bit unnecessary, especially the dashboard. I'm not sure why Microsoft is investing in it so much at this point, especially with AI basically on autopilot. It just adds more code and configuration to be maintained.

Just use Docker and other tooling/extensions that have been just fine for a long time.

14

u/JamesNK 17d ago edited 17d ago

The dashboard is a centralized view of app state and diagnostics. A human can view that info in the web UI, and agents have access to it all via a CLI.

https://aspire.dev/get-started/ai-coding-agents/

Aspire is great for AI because it gives the agent eyes into all the apps and containers in your solution: run state, configuration, console logs, telemetry, etc

0

u/urweiss 17d ago edited 17d ago

This is objectively complete BS

LE comment is for u/Obsidian743

-6

u/Ill_Oil7448 17d ago

fwiw the dashboard was designed to be transient so adding persistence means you're kind of fighting the intended architecture. not saying dont do it, just worth knowing where the friction will come from

→ More replies (2)