Replies: 1 comment 1 reply
-
Yes! Long term. Though its unclear if these experiences will work out of the box. There's enough extensiblity to plug into the orchestrator to build it though.
It's unclear how far we will go. We're not going to re-build dev spaces and that entire toolchain if that's what being asked for. There will be a first class way to reference remote urls from your local environment. Hopefully we can integrate with existing tools that let you work in this hybrid mode and project their features through aspire. |
Beta Was this translation helpful? Give feedback.
-
I read that Aspire is to be the result of the learnings of the Tye project. I hadn't come across the Tye project until after it was abandoned, but I thought that part of the project was a replacement for a feature Azure Dev Spaces that allowed for the orchestration of services in multiple ways and multiple version combinations, independently of each other.
In other words, ServiceA may be debugged locally using Kestral, ServiceB may be the most recent version already deployed into a local Docker container, and ServiceC may be an older version that needs to be debugged and is already deployed to a production Azure environment.
And the orchestration between these distributed services was configured at runtime.
While I haven't begun digging into Aspire yet, I imagine this is probably possible by creating multiple launchSettings.json (for whichever deployment scenario one desires) with environment variables that are then consumed by the Aspire Service Discovery. And then the versioning orchestration is probably handled by splitting GIT repositories per service.
Long story short, is this type of flexible debugging orchestration a goal of Aspire? Will there be additional tooling for it? Or is it already easily done with what's currently in Aspire, with maybe just more documentation or samples needed?
Beta Was this translation helpful? Give feedback.
All reactions