Ya, for a new project for local dev, I see the value. Although I'm still trying to wrap my mind around not using it for production and how you have service discovery for local, but then for production end up having to use whatever that may be depending where it's hosted. There's a mismatch there I'm trying to find a solution to and can't think of. How would that work?

They are adding in WAF testing stuff - there's a big github comment thread and a sample what's to come. I agree - without that, can't use it.

We are working on locking down the PublishAsAzure...(....) APIs that enable fine tuning of resources. Feedback heard it is something that is on our priority list. We are working with the Azure SDK team on this.

Not all devs are in a situation where there needs to be cross-team consideration, and could benefit from the velocity a platform like this affords smaller start ups and projects.

@@PraiseYeezus why the fuck would they need distributed microservices then 😂

@@MiningForPies because they work on an ecommerce platform in a small team that need to scale services separately because of black friday coming up? Source: real life

Hi @awright18 as @davidfowl indicated above, how we work across multi-repos is a work in progress (we took some initial steps in GA and we'll improve that over time). The workflow that works for you depends a lot more on your organizational structure. For example, lets say you have an organization where each service/cluster of services are managed by a seperate team, but there are well defined connections between them. Then you might have mutliple repos, each one with a AppHost that helps that service team build and debug the things that they are repsonsible for. Where those services have interdependencies then you can use things like builder.AddConnectionString(...) to reference those external dependencies (just depends on protocols etc). As teams mature they might find some benefits of having lightweight versions of services that their partner teams can use for debugging locally and so they have things like builder.AddPaymentGateway(...) that allows a partner team to have a payment gateway emulator that they just plug into their services for debugging purposes. Teams that are more tightly coupled might tackle it a different way. Our goal is to provide building blocks to help people work the way they want. Where we don't have the right shape blocks yet we see that as a potential set of features we can add.

@@PraiseYeezus yeah ok lol. 😂 Cause that’s so common. There’s thousands of shitty little companies that go viral a couple of times a year and need to scale quick 🤣

I’ve been using the jaeger all in one container locally for at least 3 years. No need for aspire.

​@@DanielGraham655t didn't try Jaeger yet but the aspire dashboard is also just a docker container so super easy to setup in just minutes.

Hell yeah

I think local is where I see the value. That's what I mentioned in the video. It's docker compose in code. For some that might be valuable. Where I'm missing the value is deployment.

@@CodeOpinion okay I get you.

"avoiding docker compose for local is ideal" why? genuinely curious, wanting to get into using containers for my current project

@@Ry4nWTF visual studio support for docker compose is weird. I’ve never liked it. MS do their usual and make things work under the hood that often go wrong and are difficult to diagnose.

Sorry I was unhelpful 😅

​​​​@@Ry4nWTF FWIW, using docker compose works well at my work. We have multi-repo and a central docker compose file. It's like 10 lines of yaml per service, most of which is just setting environment variables for config, not exactly difficult, and then you can just docker compose up. You can also just start a specific service and its dependencies. We use renovate to keep the versions of images up to date. As well as local dev, we also use this to run integration tests easily in pipelines. In prod we use k8s.