Nuget vs Multi-repo solution for Microservices shared libraries

Question

Story:

1. We have a lot of microservices and communication happens mostly through Service Bus by sending serialized DTOs.
2. Some microservices share the DB, so entity models, for now, are duplicated in each microservice.

   Problems:

   1. Whenever we want to modify DTO which is used for communication between microservice we need to modify it in each microservice.
   2. Any change in the shared DB requires making changes in all related microservices and single DB field edit causes multiple PRs.

      Possible solutions:

      Move any shared code to other repositories (DTOs repo, Entity Models repo, etc.), and create solutions with Class Library projects.

      I have two approaches after this point:

      • Create NuGets and add them to microservices.
      • Add bare Class Library projects as a reference for all microservices and we'll get Multi-repo solutions with microservices.

      Pros/Cons:

      For NuGets I see mostly cons:

      • It will require some extra infrastructure built around it to create artifacts.
      • To test any change it will be needed to modify Nuget Solution, trigger some CI pipeline and wait to build the NuGet itself, update the microservice with a test version of NuGet, and only after that we can test the microservice itself.
      • If any errors occur - repeat an entire process.

      For bare Class Library projects I see mostly advantages:

      • VS 2022 brought some nice support for Multi-repo solutions.
      • It will be possible to make changes in shared projects and immediately test them with actual microservices.

      Questions:

      • Could you add any pros/cons for my possible solutions?
      • Could you recommend any other solutions for problems (with pros/cons)?

Answer 1

Not an answer for your question, at least a full one, but few things to think about:

I would recommend to start deeper and look into pros and cons for monorepository vs multirepositories which has been discussed many times (for example here or here) so go through those articles first.

Whenever we want to modify DTO which is used for communication between microservice we need to modify it in each microservice.

In general case with correct design and versioning approach you don't need to modify DTOs in each microservice on every change (if that change is not relevant to that microservice), unless it is a breaking change and breaking changes should be done as rare as possible and should be handled via versioning.

Another thing you can try looking into - using schema registry to define shared contracts and add it to every project via git submodule and write some kind of generator to build DTOs automatically from it.

Any change in the shared DB requires making changes in all related microservices and single DB field edit causes multiple PRs.

I would argue that shared database in microservice architecture is a huge antipattern which should be addressed as soon as possible (and yes, I understand that life is not always goes with patterns) and fixing it will remove quite a lot of your current problems, so I would suggest to concentrate on it (if it is possible/feasible) then on fixing the symptoms.

Also you can look into replicating somehow the VMR which .NET team is shifting to.

As for the actual question for "Bare Class Library projects" and VS multi-repo support - first of all currently multi-repo support is limited only to 10 repos, and not everyone is using VS (for example cause it is not available on Linux ATM), secondary there is a question of setting up build servers to work with this (which would be easier with nugets).