What would be the standard and better approach of the git repository structure for microservice architecture?

Question

The better approach of repository structure for microservice architecture based applications?

For example, I was referring through Microsoft reference architecture i.e. eShopContainers in github repository [https://github.com/dotnet-architecture/eShopOnContainers/tree/dev/src]. But that comes up with some more complexity of dynamic work environment, where team work on various UI, microservices, hence everything under one repository is making it more time consuming process on merge/conflicts, etc. Some team members would like to have each microservice in separate repository while development for better management and then to export to group repository after production i.e. while BAU. Appreciate to have a discussion the pros and cons to make a better decision for our environment.

Answer 1

One of main benefits of using microservice architecture is ability to introduce new technologies without performing full rewrite. It's easy to think only about programming languages and frameworks - but the truth is that version control software is exactly the same. I've seen teams migrating from SVN to Git, or TFS. It's naive to believe that Git will stay with us forever. I believe this is a strong argument for using multiple repositories.

Single repository - as long as it has advantages - will always tempt developers to make some kind of cross-project dependencies. Maybe it will be one build file in specific build tool used to compile all the microservices. It may be a common library directory with specific versions of external dlls or jars or anything. There always will be a tendency to create such a thing. Which will finally make these microservices somehow bound and dependent.

I believe that good way to store the project(s) created using microservice architecture in multiple, independent repositories.

Answer 2

Having done both, here are some of the tradeoffs:

For a monorepo (all code and services in the same repo):

• Much easier to keep related changes in sync (e.g., both a producer and a consumer change; the changes to both can be saved as a single commit).
• It's easier to set up a consistent build environment. Properly set up, all of the services can be built using exactly the same toolchain and possibly the same Makefile.
• If you choose to use a single GOPATH, all of the services need to be kept in lockstep. This can cause a lot of pain if one service needs to switch to a newer version of a library with a breaking change; every service using that library has to upgrade at once. Multiple GOPATHS make the process more complex to maintain.
• If properly managed with CI and testing, it's possible to keep HEAD in a deployable state at all times, decreasing the chance you'll end up with a set of services that can't interoperate because they don't match up.

Multiple repositories:

• Much easier to get a service to a stable level and leave it alone. Because it lives in its own repository, there's no requirement to do upgrades even if another service needs a newer version of a library, or you decide to change libraries (e.g. from Gin to Echo).
• Tempting to neglect upgrades on stable services (the Gin to Echo change, for example), possibly entailing a significant update for a breaking change under time pressure; definitely increasing maintenance load (do we do the long-postponed upgrade to Echo, or do we just leave it at Gin? If we have to make a significant change to our APIs, how many different frameworks will we need to work with when we do that?)
• Proliferation of repositories makes it harder to find something when it's needed (which service did we define this in? I need to reuse that over here)
• Proliferation of duplicate or (worse) near-duplicate code across multiple repositories. It's easy to get into the habit of copying a service as a base and then making changes on top of the old code, resulting in a fractal set of differences across the codebase, especially because "working" code doesn't tend to get updated to match the changes.

There are no doubt others, but these are some that I've actually experienced in both cases. A monorepo is probably better if you're going to be evolving a lot of services in parallel; multiple repos is better if you can architect your services pretty much independent of each other.