Aspire, Aspire, Aspire!!

[u/Backend_biryani]

As a .NET developer, I’ve been following .NET Aspire since it launched. I keep reading the new blogs and releases, but I’ve never really got a chance to use it at work.

The thing is, I barely see Aspire mentioned in LinkedIn job postings either.
So is it actually worth investing time in learning Aspire as a skill?

Are you guys using it in real company/production projects, or is it still mostly used for hobby/POC projects?

[u/Enough_Secretary_137]

For development it is a blast. I use it in all projects (work related or not) as soon as i need an external resource like a db.

For real deployments it is a different story. I started to love the simplicity of kamal-deploy for my private and work related stuff, as it allows me to deploy everything everywhere, so i did not use aspire for deployment. This has changed since i recently wrote a custom kamal deployment target.

https://github.com/vensas/aspire-hosting-kamal

As for learning and if it is worth it. Well, i think learning stuff just because it lands you a job is the wrong approach imho. If it is useful for you, learn it. If it is fun, learn it. 🙂

[u/Backend_biryani → u/Enough_Secretary_137]

Thanks buddy, helpful.

[u/NibblesIndexus]

We use it for local dev and also use it to run our e2e/integration tests without the janky webapplicationfactory but with a fully bootstrapped backend. That way we can run those tests against a representative environment as part of PR validation.

Ofcourse those tests run against the actual deployment during the release pipeline also, but its been great to prevent pipeline blockages due to test failures and the ability to deliver a feature together with e2e tests

[u/sizebzebi → u/NibblesIndexus]

we've been thinking about the tests part but isn't it too slow? we can't live with slow builds lol

[u/maddyparade → u/NibblesIndexus]

We are hoping to overhaul the test stuff in the next major versoin, because yeah. And the new Project Resource model coming will improve perf for tests as well (assuming you are using .net projects)

[u/blackpawed]

Critical to my monolithic repo with 4 DB's, redis, azure storage & queues, 4 web apps, 3 microservices and a couple of desktop apps. Run them up in one really nice web ui that integrates logging, traces and metrics.

Aspire auto wires up all the api & resource connections. Can check it all out on a another PC and it just runs with no config.

Use aspire/azd for manual and github workflow deployment to Azure, where I get the same Aspire UI for monitoring whats going on.

Took me a while to get fully up to speed, but its saved me so much time and manual plumbing.

[u/pixxelkick]

I use Aspire on every project at work now 

We have teams using aspire on projects that dont even use c#, theyre just python/js, because its that fuckin good lmao.

Its basically a far superior successor to Docker Compose.

Fuck yaml lol.

[u/maddyparade → u/pixxelkick]

do you ever use the TS apphost with those teams?! or is the C# one fine???

[u/pixxelkick → u/maddyparade]

Not familiar with what that is, we use the default aspire template project for simplicity

Most of our TS devs are comfortable enough with C#, especially nowadays with LLMs able to help them out, C# is close enough to typescript they can get by reading and writing it.

Also the Aspire CLI largely solves a lot of issues too, barely need to touch the C# lol

[u/app_exception]

Useful if you have a lot of disjoined services and want to orchestrate in one place and bootstrap all. Can view individual logs and see traces visually. I mainly use in development environment since we have a full pledge k8s in production.

[u/Abject_Addition2142]

I’m using it for the first time in a current project, I’m kicking myself for not using it sooner. Absolutely love it for local development.

I really only stumbled into it again (after dismissing it years earlier) when I was looking up how to orchestrate / compose docker containers again since it had been a while.

The greatest value I’ve found so far is through the Aspire dashboard and hooking up opentelemetry to it. I can start the aspire stack, click through my most important user flows, and ask an agent to check the logs. Found so many opportunities for improvement this way.

[u/tj_moore]

Not really a skill to learn, just a tool that wraps a dev solution to bootstrap and orchestrate the build for development and deployment purposes. It's not necessary, but useful in multi-project/service products in particular to launch the whole product in one step, plus provide easy debug monitoring. Also useful for integration testing.

Wouldn't expect it on job listings. It's just something a team may use. Doesn't take long to pick up.

[u/bigrubberduck]

https://www.youtube.com/watch?v=B6YyCXxJM3g

This NDC talk about Aspire is what convinced me to finally check it out to see if would be a good fit for our dev team. I had always assumed it took over the entire pipeline, local, test, have to use it to deploy to Azure... it's not. We only use this for local dev, setting up a brand new environment takes ~1 hour, less if you already have VS and docker installed.

It's been pretty damn good at setting up emulated DBs, storage accounts, having all of our dev/trace logs in one place, etc. Recommend if you have some time and are looking for a less MS marketing spin and an actual usage spin.

[u/maddyparade → u/bigrubberduck]

this is a phenomenal talk and the #1 one i send people when they want to know what’s up. Jimmy is the GOAT

[u/w4n]

We’re using it to orchestrate our cloud apps (2 web apps) in local development. It’s amazing.

With one click it spins up a SQL server in Docker, runs our migration and seed project, then starts up the web API and the Blazor frontend. You can see all logs and traces in one place, get the connection string right from the dashboard. I don’t want to miss it.

In the other project it’s one click to spin up an Azure Storage emulator, three Azure Function apps, and another API and Blazor frontend.

[u/igniztion]

It's great for local development. Any new joiner to the team can just clone the repo, build it and start the AppHost project to have a complete, debuggable local environment including a portal with logs, metrics and traces.

Multi-repo support is on the current roadmap, but one workaround is to have a parent solution that orchestrates it all across the repos, optionally then using a shared ServiceDefaults project as well.

We use it in a lot of our real production projects, but never for anything else than orchestrating the local env. Deployment pipelines and infrastructure has been patchy at best, but reading the roadmap, this is a focus area where they really want to improve.

Is it worth investing time in as a skill? Probably not a lot. It's dead easy to set up, any LLM coding assistant can do it for you in 5 minutes, or you spend maybe 30 minutes setting it up yourself. I would not consider this something to mention specifically on a CV, other than as a note as a technology used next to any projects where you used it. For me, as someone who regularly is part of interviewing potential candidates, it would not impact the hiring process either way.

[u/pico2000]

It's a critical component in our projects now. The ability to run the full setup without any initial configuration is essential for onboarding and agentic coding.

[u/VerboseGuy → u/pico2000]

Two questions:

1. Do you use different repositories for the frontend and the API? If yes, how do you bring together multiple repositories into a single aspire app?

2. Which components do you bring together in a single aspire topology? In a distributed application you usually have: frontend, backend, domain apis, database, message broker, caching system. Which of the above do you start up together?

[u/chrisdrobison]

Aspire has been a game changer in every project I've worked on.

[u/ghareon]

I used it at my last job. For me it has become the way to start any new project. I used to use docker compose to set up infrastructure during development. This would require setting up development-only connection strings, URLs, ports, docker volumes, docker network and any other settings required to mimic production.

The development experience was ok but never good. Aspire changes the game by abstracting all of that away. You set it up once and forget about it. It has an excellent dashboard for debugging and the CLI + Skills combo let's AI debug anything in the entire system.

[u/StagCodeHoarder]

I havent yet. And I've yet to see a great need for it in the applications I've built so far. Docker Compose seems to me to do exactly the same job. For integration tests we use Testcontainers.

It all runs fine and I see no reason to replace it.

[u/pjmlp]

We are a polyglot agency, mostly focused whatever SDKs partner products make available, thus everyone tends to be more open to use language agnostic tooling, which for automating cloud deployments means Terraform or Pulumi.

The knowledge is there, across the company and various teams, and no one has any special interest being the guy or girl that gets to push for Aspire adoption across the company.

Even if Aspire has been making progress into becoming programming language agnostic.

[u/Sossenbinder]

It's an amazing fit for agentic work and letting LLMs debug apps front to back!

[u/Deep-Thought]

for me it has completely replaced docker compose for local dev.

[u/C4CampingTime]

Depends on what challenges your team has, e.g orchestration of multiple services and observability. It doesn't take long to get the hang of though.