15

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.

Denis Stephanov
  • 4,563
  • 24
  • 78
  • 174
  • For Maven projects I would stick to the rule: One maven project, one repository. If your microservices are part of a multi-module project, put them into one, otherwise use separate ones. – J Fabian Meier Nov 08 '19 at 16:20
  • @JFMeier if there will be only maven projects we would use multi module project as you said, but there are javascripts apps a these shouldn't be as maven projects i guess – Denis Stephanov Nov 08 '19 at 16:23
  • 1
    Even if you decide to write multiple apps in the same repo, don't use foreign key relationship across the apps table. Instead whenever you need some object of another app Write a method. In future whenever you will decide to split your project to multiple microservices you just need to convert this method to api calls – Abhishek Ranjan Nov 08 '19 at 20:29

1 Answers1

35

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 require 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 these 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 a decision which is made project by project.

PythonForEver
  • 387
  • 2
  • 15
xargs
  • 2,741
  • 2
  • 21
  • 33
  • 2
    These are great points and I want to **emphasize #5**. We managed to build processes to work around some of the other considerations but the one we struggled with most was building CI / CD pipelines. In our case, we had over 15 microservices that would get recompiled, containerized, and redeployed with each commit or merge. This was a very costly and time consuming process, and not to mention, wasteful. The end result ended up being individual Git repositories for each microservice within the multi-module Maven project. – user0000001 Mar 02 '22 at 14:24
  • 1
    hey @user0000001 I believe you can make use of build tools like Bazel that lets you avoid running CI/CD for the apps that did not change when making a release. – roronoa Dec 22 '22 at 12:05