Microservices: Mono repo vs. multiple repositories
Colorful boxes image via Shutterstock
Moving to microservices? Great but the first question before you write a single line of code is: How do you organize your codebase — do you create a repository for each service or do you create a single ‘mono repo’ for all services?
Microservices still represent a hot topic but we should not be taking this architecture for granted.
If you want a simple definition, it’s basically about breaking down a single monolithic application into multiple pieces so that each piece performs a single business function without depending on other pieces and functionalities but with a common purpose of doing a specific task altogether. Each piece is developed and deployed independently.
One of the most important details wit regard to adopting to microservices architecture is that there should not be any design time dependencies. You might have seen this example of a banking application using microservices:
You can see there are a lot of differences between a traditional approach and microservices approach. This example clearly shows that if there is any web change, it shouldn’t affect the backend and other processes.
Microservices are also scalable and this is an added advantage of using microservices in organizations to handle any complex issues independently whenever a system identifies any fluctuating loads/requests. Furthermore, microservices can be packed in a container with all the required environment capabilities that makes it lightweight and easy to handle.
But there is one big question
When creating a system to perform a specific task, you need to make one decision clear, i.e, whether to keep the code in one repository or split it across multiple repos.
Let’s make it clearer:
Before we move further, don’t forget:
- Facebook has a mono repo
- Google is rumored to have mono repo as indicated by many posts on the internet
- Shippable recently moved from multiple repositories to a mono repo
One cannot argue that here are some really good advantages of having multiple repositories. Here are a few:
- Code style: Some companies find it useful to have a consistent coding format enforced across their code. This is certainly more difficult to achieve when you have separated repositories.
- Testing: It is easier to create integration tests when you have all the services in one repository because the creation of testing environment and deployment becomes easier.
- Clear ownership: A small team can own and independently develop and deploy the full stack of a microservice.
- Better scale and coordination: Smaller codebases are easier to manage and lead to fewer instances of “merge hell”. Teams do not need to coordinate with other teams, thus leading to faster execution.
But there are also disadvantages:
Since you break down the application into multiple pieces, this creates confusion between teams and localized knowledge across the organization. The purpose of the organization as a whole gets diluted since the teams are scattered and do not know the main objective of the company. The teams lacked understanding of the bigger picture and hence not bothered about what others are doing as long as their work is done.
You might be wondering why some successful companies like Facebook, Google etc have moved from multiple repositories to mono repositories. Instead of an answer, let’s allow the advantages of having mono repositories to shine:
- Simplified organization: With a mono repo, projects can be organized and grouped together in whatever way you find to be most logically consistent, and not just because your version control system forces you to organize things in a particular way. Using a single repo also reduces overhead from managing dependencies.
- Improved overall work culture: With the adoption of mono repo, every individual in the organization is aware of business objectives and this makes it a unified team and hence can contribute more specifically towards the goals and objective of the organization.
- Better coordination between developers: Developers can easily run the entire platform on their machine and this helps them understand all services and how they work together. This has led our developers to find more bugs locally before even sending a pull request.
- Tooling: The simplification of navigation and dependencies makes it much easier to write tools.
- Refactoring made easy: Any time we want to rename something, refactoring is as simple as running a grep command. Restructuring is also easier as everything is neatly in one place and easier to understand.
Mono or multiple?
This clearly indicates that having a unified knowledge across the organization is very important and hence we see the advantages of mono repos are at organizational level contributing directly to the improved work culture and easy understanding of the whole business objective for individuals.
Mono repos are the right choice for teams that want to ship code faster.