The newest debate in town is whether you should keep your services in a single repository or multiple small repositories.
The idea of multiple small repositories is that code for each of your app’s micro service is kept in a repository of its own. With a mono-repo, you keep the all the code in a single repository and deploy the code as micro services.
So which should you use? Being too rigid about any one approach — without considering the purpose and uses of each approach — can lead to negative outcomes in the long run. If you’re aware of when to use each, it can increase your productivity and improve your project.
To bend the rules, we need to first understand why they exist. A common recommendation is to have an independent repository for every app/service. But why? Because, by having one repository for each micro-service, we gain:
Freedom to write code differently and independently of all other services. Velocity in making code changes while fixing bugs, making updates, testing and deploying. Since changes only have to be tested in a single repository, deployment of the code is faster and more reliable. Separation of code as independent units, which preventing bug leakages and performance bottlenecks between services. Clear ownership of each repository and service, which is especially helpful for large teams. But why did the need for mono-repos arise? Clearly the multi-repo approach has its benefits. But it also comes with its own challenges, especially in projects with a large number of microservices that use the same frameworks, language, tech stacks etc.
A few of these challenges are:
Enforcing standards and best practices across all repositories. With a multi-repo, changes in code standards and best practices need to be replicated across repositories. With a mono-repo, all the changes can be done in one place.
The effort of maintaining shared or common components. Security patches, version upgrades and bug fixes involve making sure that these changes are made across all repositories and that they work seamlessly everywhere. (On a side note, the repeated code in each service also bloats its size.) In a mono-repo, we can make updates in one place, saving both time and headaches. End-to-end testing in tandem with closely related or dependent services right from the developer’s machine. By having all the code in one place, we ease the process of starting up all the related services and running end-to-end tests.
On-premise deployments of code for other businesses. By deploying a mono-repo as microservices, we save time and reduce the redundant effort of bootstrapping each repository. Clearly, there are advantages and disadvantages to both approaches, and each approach will have its own benefits under different circumstances.
Therefore, we have adopted the approach of remaining flexible and using both multi-repos and mono-repos, but only after completely understanding why we have chosen to use each for each service. This has led us to have multiple repos containing several microservices, segregated in a way that has made:
Maintenance and updates both easy and fast.
Locating the code to debug or change much more structured.
Onboarding new teammates easier.
No comments:
Post a Comment