Should each Microservice have a separate Git Repository? | Apoorv Bedmutha, Friend of Tech

Описание: Medium Blog:   / should-each-microservice-have-a-separate-g...  

Subscribe to my newsletter:   / subscribe  

Yesterday, a fellow engineer sparked a debate between my team, by asking whether “Each microservice have it’s own repository?”. Chaos erupted, there was no single bias to this problem. So I took it upon myself to find the ultimate truth.

Note that a microservices does not refer to the services package we commonly have in a backend API project.

What is a microservices architecture?
A Microservices architecture refers to building a system with separate isolated and independent parts. The benefit of this approach is:

Manageability: Breaks down large codebases in small and manageable parts
Availability: Each micro-service is independent, if one malfunctions, it does not infect the whole system.
Flexibility: Microservices is a plug and play design, i.e any new service can be added at any time and any existing service can be remove or detached from the system.
Vertical Scalability: Very often, increasing the number of servers is more affordable than upgrading the existing servers. The Microservice architecture enables this as each service can be isolated and duplicated across different set of servers.
Why to use different repositories?
There are several benefits to maintaining different microservices in different repos, as follows:

Keeping separate repositories, makes it easy to setup different code deployment cycles and configure CI-CD. ( This will makes your Devops guy very happy :)
Often different teams are responsible for different services, having different repos provides a way to manage codebase access, and minimizes confusion for engineers working.
The whole soul of microservices is that the services are isolated and independent, so truly follow this principle having different repos seems like a very obvious choice.
As the size of each micro-service module will increases, so does the whole project. hence, having these services separate ensures readability, maintainability and more.
Often each server runs only a set of services, so have different codebases for each service makes it possible to run these as different containers without pulling all of them.
Hope that shed some light on why you should opt for this approach. Alternatively, for smaller projects which won’t scale to a bigger size in future. Having a single parent project with each service as a child module works great, as here having different repos is just over-engineering.

See you in the next one.

#backend #devops #systemdesign