It does not use Kubernetes at all. When you run locally, we don't need the overhead of a cluster to run simple executables or containers on your machine. The barrier to entry is extremely low in comparison and optimized for local development. There's no yaml, no containers required by default, no need to deploy a dashboard, no need to setup multiple containers with more yaml configured just right to get telemetry. It's just more productive when you are messing around in this space. Kubernetes is for deployment (as it should be).

@@davidfowl Indeed, it provides extra flexibility but with extra costs. If you start running your services as containers locally with Aspire, you start getting close to running Kubernetes locally (enabled with a tick of a checkbox) within your Docker Desktop / Rancher Desktop or minikube installation. When you do this, you don't need extra projects in your solution and understanding other orchestration dialects and their Nugets work. You are in the kubernetes + kustomize world. You reuse your skills. .NET can publish containers without dockerfiles into a local registry where from they can be picked up by your local k8s cluster. Let's acknowledge the fact that Docker(Dockerfile) is the standard for container format and Kubernetes(k8s metadata) is the standard for container orchestration There is a reason compose / tye / and other attempts to introduce alternative ways of orchestrating services didn't succeed... There is always a translation effort to your target infrastructure metadata while when targeting Kubernetes you are close to your target and covered cross-cloud provider. I guess, it's good to have options. I'll keep following Aspire evolution to understand it better and the contexts where it shines. So far The OTEL dashboard and the resilience packages are a universal win for .NET Thanks for answering!

@@davidfowl I agree it's a convenient way fror .NET devs to run microservice workloads locally. When you need to target pre-production / production environments I see friction with other tools in this space. Tools like kubernetes on one side and terraform, pulumi, ... on the other side. Devops people are not necessarily .NET devs so you get to step into two different worlds that complicate things at a higher level. Just a thought.