Microservices and Difference Between Mono Repo and Multiple Repositories

Microservices are currently the hottest topic in software development. The concept is simple: Break down your application into smaller pieces that each performs a single business function and can be developed and deployed independently. These pieces, commonly called services, can then be assembled into an application using some flavor of service discovery like Nginx or Consul. The microservices approach is considered the architecture of choice for teams that want to build scalable platforms and efficiently and rapidly innovate on them.

Advantages of Using Microservices

1. By linking together each traditional tier of the application (database, business logic, and web layers), individual services can address each other by leveraging an API that more closely mirrors an MVC-style pattern.

2. Using an API interface, the application can scale significantly to accommodate large spikes in traffic.

3. A service-oriented architecture can also provide significantly greater visibility into the operation of the application, making it easier to troubleshoot.

4. Each microservice packaged into its own container is also resilient against failure. In other words, the failure of one microservice does not impact another microservice.

5. Another advantage of microservices is their ability to be built and signed to ensure their integrity. Verified base images can be leveraged from trusted repositories like Docker Hub to speed builds.

When you start moving to microservices, 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? The two approaches are illustrated below:

Multiple Repositories

Clear ownership. Since the codebase mimics the architecture, a small team can own and independently develop and deploy the full stack of a microservice.

Better scale. Smaller codebases are easier to manage and lead to fewer instances of "merge hell." Teams do not need to coordinate with other teams leading to faster execution.

Narrow clones. Most source control providers including git do not support cloning parts of a repository. For large codebases, clones, pulls, and pushes take too much time, which is inefficient.

Mono Repository

Better developer testing. 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.

Reduced code complexity. Senior engineers can easily enforce standardization across all services since it is easy to keep track of pull requests and changes happening across the repository.

Effective code reviews. Most developers now understand the end to end platform leading to more bugs being identified and fixed at the code review stage.

Sharing of common components. Developers have a view of what is happening across all services and can effectively carve out common components.

Easy refactoring. 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.

Conclusion

Mono repos are the right choice for teams that want to ship code faster. There are concerns that this doesn't scale well, but these are largely unfounded. Companies like Twitter, Google, and Facebook run massive monolithic repos with thousands of developers.

The only thing you really give up with a mono repo is the ability to shut off developers from code they don’t contribute to. There should be no reason to do this in a healthy organization with the right hiring practices.