Add Multi repo support

[dosper7]

In several companies that use microservices have their own cloud platform teams and normally this "translates" into having a service per git repos.

In this cases how to use .NET Aspire? Meaning, different projects from different repos? It's not common to have multiple services within the same repo (unless you have a monorepo like Google 😆)

What is your suggestion?

[davidfowl]

Clone multiple repos locally, create an Uber solution and add the apphost to it, wiring up all of the projects required.

That's where I would start.

it you don’t want to pull and run the other repos locally, then I’m not sure exactly what the workflow would be (point to something already running).

[DamianEdwards]

Some patterns I imagine might emerge:

• git sub-modules for service repos and a parent repo with the .sln file and AppHost project, if you want to build and run all services locally
• Services published as container images that are then composed into an AppHost project as containers, if you don't want to build the services locally but you do want to run them locally
• Dev-instances of services deployed to dedicated environments and/or locally that are then composed into an AppHost project as HTTP endpoints, if you don't want to build or run the services locally

[bbrandt]

I believe we would need to publish our service defaults as a NuGet package, published to our own private NuGet server (Azure Artifacts in our case). Then projects throughout all the different repos could add a reference to this service defaults NuGet package.

[DamianEdwards]

I believe we would need to publish our service defaults as a NuGet package, published to our own private NuGet server (Azure Artifacts in our case). Then projects throughout all the different repos could add a reference to this service defaults NuGet package.

Yep, or you could put the ServiceDefaults in a sub-module and include it that way. There are lots of ways for folks to share code and assets among teams and I don't think we want to be too prescriptive about it. We should ensure we're flexible enough to support different patterns.

[artyom-p]

@DamianEdwards would be nice to have some samples on how to proceed with multi-repo scenarios. It is definitely a very cool and useful tool, but a huge part of microservice solutions are split across different repos, and in this case its not that obvious how to utilize it in local environment.

[dosper7]

I also don't understand how the deployment story is in this scenario, where we "run" our k8s cluster with a custom cloud platform team.

For instance, we use github + tekton pipelines + argo CD to deploy to k8s using multiple repos (one per service), all things k8s related are generated/managed by the platform (I've worked in previous companies with similar setup bu using different tools like gitlab as an example)

How Aspire can be helpful in this cases?

[davidfowl]

@artyom-p

@DamianEdwards would be nice to have some samples on how to proceed with multi-repo scenarios. It is definitely a very cool and useful tool, but a huge part of microservice solutions are split across different repos, and in this case its not that obvious how to utilize it in local environment.

Are you cloning everyone's repositories and running them today?

[davidfowl]

@dosper7

I also don't understand how the deployment story is in this scenario, where we "run" our k8s cluster with a custom cloud platform team.

It sounds like you don't need to use the deployment part of aspire because you have already figured it out! It's still great for local development, using components, and service discovery!

[artyom-p]

@davidfowl Yes, we clone all the repositories locally and debug service communication having multiple studio instances opened. Its doable, but its a pain.

[davidfowl]

@artyom-p What does the pain free solution look like? What would you ideal experience be?

[artyom-p]

@davidfowl Let's say we have 2 microservices that need to communicate with each other, they live in their own git repositories.

Each microservice can have its own or shared dependencies, for example:
ServiceA depends on ServiceB, Redis and MongoDB
ServiceB depends on MongoDB

There are cases when you want to debug only one service, but you still need another one to be running with all its dependencies, in this case, we can just somehow reference that second service and make it run, I think there was something similar in Tye before if I'm not mistaken.

The second case is more complex - when you want to debug both services. I'm not sure if it's doable without referencing projects of ServiceB in ServiceA solution.

[DGAISmith]

We also have the same multi-repo approach here, and this is where Tye was really strong for local development. A tye.yaml file could be relatively pathed to target x services, all cloned locally. Tye was also useable as a completely external tool, no changes were required to any service, and they could also target a variety of different dotnet versions.

Aspire looks so much better in many ways to Tye, and I can see it's trying to achieve different things, but being able to use Tye as a non-invasive external local dev orchestrator remains a huge benefit and time saver for multi-repo scenarios.

[davidfowl]

There are cases when you want to debug only one service, but you still need another one to be running with all its dependencies, in this case, we can just somehow reference that second service and make it run, I think there was something similar in Tye before if I'm not mistaken.

You can do a similar thing with the app host. Clone multiple repositories and create a project file that references individual projects. Maybe we need to enable referencing app hosts themselves 🤔.

Tye was also useable as a completely external tool, no changes were required to any service, and they could also target a variety of different dotnet versions.

Aspire does require .NET 8 and above.

but being able to use Tye as a non-invasive external local dev orchestrator remains a huge benefit and time saver for multi-repo scenarios.

Can you show me your tye setup?

[DGAISmith]

Many thanks for the reply, really enjoying the Conf this year.

Tye was also useable as a completely external tool, no changes were required to any service, and they could also target a variety of different dotnet versions.

Aspire does require .NET 8 and above.

You say that, and of course you're totally correct if you want to use everything in the Aspire stack (and who am I to argue with the mad professors who came up with this amazing stuff), but I have been able to hack something together today from the starter application template using AddExecutable():

var builder = DistributedApplication.CreateBuilder(args);

//var apiservice = builder.AddProject<Projects.AspireApp2_ApiService>("apiservice");
var apiservicePort = 5323;
var apiserviceScheme = "http";
var apiserviceHostname = "localhost";

var apiservice = builder
    .AddExecutable("apiservice", "dotnet", @"..\AspireApp2.ApiService6", "run", $"--urls={apiserviceScheme}://{apiserviceHostname}:{apiservicePort}")
    .WithServiceBinding(apiservicePort, apiserviceScheme)
    .WithOtlpExporter();

builder.AddProject<Projects.AspireApp2_Web>("webfrontend");
    // .WithReference(apiservice);

builder.Build().Run();

In this case, ApiService6 is a dotnet6 api, inside which I've added OpenTelemetry support based on the code in the ServiceDefaults project. You do then end up with traces and (partial) metrics in the Asipre dashboard. So this is potentially useful-ish (I should try this with func.exe as well to see if we can spin up Functions in a decent way while Function support isn't quite ready yet). Service discovery is obvs broken here, and Aspire Components are presumably off the table too.

This serves two purposes though - allows some use of older dotnet applications, and also allows targeting of different repos outside of the solution the Aspire AppHost lives in. So it falls back to a similar kind of experience to Tye in these respects.
Probably not what you had in mind when you designed Aspire of course, but it's really nice to get some of the new dashboard experience with older projects.

but being able to use Tye as a non-invasive external local dev orchestrator remains a huge benefit and time saver for multi-repo scenarios.

Can you show me your tye setup?

Sure, we have a lot of tye files, each targeting a specific surface area of our microservices (which are all in individual repos). Redacted example below:

name: Portal Backend Frontend
extensions:
- name: zipkin
- name: seq
services:
- name: Portal-UI
  executable: cmd
  args: '/c npm start'
  workingDirectory: ./MyCompany.Portal/src/Portal
  bindings:
    - host: localhost
      port: 80
      protocol: https
- name: Identity-Api
  project: ./MyCompany.IdentityApi/src/MyCompany.IdentityApi/MyCompany.IdentityApi.csproj
  bindings:  
   - port: 5000
     protocol: https	  
- name: Portal-Api
  project: ./MyCompany.PortalApi/src/MyCompany.PortalApi/MyCompany.PortalApi.csproj
  bindings:  
   - port: 19081
     protocol: http
- name: DataPull-Function
  azureFunction: ./MyCompany.Functions/src/MyCompany.DataPull.Functions
  bindings:
  - port: 7071
    protocol: http      
- name: DataMapper-Function
  azureFunction: ./MyCompany.Functions/src/MyCompany.DataMapper.Functions
  bindings:
  - port: 7072
    protocol: http      

Key thing here is that we haven't made any code changes to any of these services, and they're spread over 4 different repos.