Multiple microservices in one repository

Question

I have question about microservices and repositories. We are a small team (5 people) and we creating new project in microservices. Expected microservice applications in our project is between 10-15.

We are thinking about one repository for all microservices in structure like that:

-/
--/app1
--/app2
--/app3
-./script.sh
-./script.bat

What do you think about this design? Can you recommend something better? We think if we will have repository per app it will be overkill for that small project in one team. As our applications you can imagine spring boot or spa applications in angular. Thank you in advice.

Answer 1

In general you can have all your micro-services in one repository but I think while the code grows for each of them it can be difficult to manage that.

Here are some things that you might want to consider before deciding to put all your micro-services in one repository:

1. Developer discipline: Be careful with coupling of code. Since the code for all your micro-services is in one repository you don't have a real physical boundary between them, so developers can just use some code from other micro-services like adding a reference or similar. Having all micro-services in one repository will require some discipline and rules for developers not to cross boundaries and misuse them.

2. Come into temptation to create and misuse shared code. This is not a bad thing if you do it in a proper and structured way. Again this leaves a lot of space for doing it the wrong way. If people just start using the same shared jar or similar that could lead to a lot of problems. In order to have something shared it should be isolated and packaged and ideally should have some versioning with support for backwards compatibility. This way each micro-service when this library is updated would still have a working code with the previous version. Still it is doable in the same repository but as with the 1. point above it requires planing and managing.

3. Git considerations: Managing a lot of pull requests and branches in one repository can be challenging and can lead to the situation: "I am blocked by someone else". Also as possibly more people are going to work on the project and will commit to your source branch you will have to do rebase and/or merge source branch to your development or feature branch much more often(even if you do not need the changes from other services). Email notifications configured for the repository can be very annoying as you will receive Emails for things which are not in your micro-service code. In this case you need to create some Filters/Rules in your Email clients to avoid the Emails that you are not interested in.

4. Number of micro-services grow even further then your initial 10-15. The number can grow? If not all fine but if it does at some point you could maybe consider to split each micro-service in a dedicated repository. Doing this at the point where you are in later stage of project can be challenging and could required some work and in worst case you will find out that there are some couplings that people made over time which you will have to resolve at this stage.

5. CI pipelines considerations: If you use something like Jenkins to build, test and/or deploy your code you could encounter some small configuration difficulties like the integration between Jenkins and Github. You would need to configure a pipeline which would only build/test a specific part of the code(or one micro-service) if someone creates a merge/pull request against that micro-service. I never tried to do such a thing but I guess you will have to figure out how to do it(script and automate this). It is doable I guess but will required some work to achieve it.

Conclusion

Still all or most of this points can be resolved with some extra management and configuration but it is still worth knowing what additional effort you could encounter. I guess there are some other points to be taken into considerations as well but my general advice would be to use separate repositories for each micro-service if you can(Private Repository pricing and similar reasons). This is decision which is made project by project. Hope this notes help you :)