1

As part of a larger project, my team is building a microservices API layer. We do not have experience with building microservices so we have been trying to figure out how to go about the project.

The first decision we are working on is if we should use a mono-repository or split each microservice into a separate repository. It seems like there are pros and cons to each option.

A mono-repo will increase development time, promote code reuse and make refactoring easier. However, the code base is larger, longer clone time, could run into issues merging and could increase complexity of deployments.

A multi-repo approach will have smaller code bases, less code to clone and will reduce the deployment complexity. However, this approach will increase the development effort. Debugging time can increase and makes it difficult to share common code.

To sum it up, it seems multi-repo is better when the application is in production while a mono-repo is better for development.

With all that said, is there anything else I should consider when deciding whether to use a mono-repo or a multi-repo approach?

Improve this question
3
  • How is the software being deployed? How independent are these microservices. If they are fully independent they should be supplied by separate packages. Services that must be deployed at the same time should live in the same package to ensure they are deployed at the same time. Figure out how many packages are going out. Make sure your code is organised in the repos to support building each package from a single commit. Its fine for a single commit to generate multiple packages, although i would glare at the reasoning to keep it sane.
    – Kain0_0
    Aug 1, 2019 at 2:39
  • @Kain0_0 Thanks for your comment. We plan to deploy using Azure DevOps into separate Azure App Services. Also, these services will have some communication with each other and I think there will be some overlapping code.
    – DFord
    Aug 1, 2019 at 14:20
  • 1
    If you are going to share code, use a separate library repository, and a package manager to import it into each service. It is best if the library is hidden from the Service interface (it is a pure implementation detail). This will allow each service to use different versions and be upgraded as needed, not as dictated by another service. If you must expose it it at the interface level be very careful. You will have to design your Service interface as purely additive and your library will need to be 100% backward compatible. It will also force other services to upgrade to use new functionality.
    – Kain0_0
    Aug 5, 2019 at 23:24

1 Answer 1

Reset to default
2

When building microservices, we can choose to use a dedicated database for each service or share one database with multiple services. However, the repository code should always belong to only one service. Using microservice, we want to make the development and deployment of each service to be independent of each other. If the repository code is used by two services, these two ones should not be separated.

Normally, I refactor the current application into another monolith one but with better module structure before converting each module into services one by one. Managing dependencies between microservices is always hard and it will become even harder if we let services sharing code.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.