Monorepo vs Polyrepo

There has been a debate in the developer circles about which approach is better when managing source code versioning: monorepo or polyrepo.

Monorepo

Monorepo essentially means that all of your source code is kept in one single repository. It includes all projects, no matter how related or unrelated they are.

Polyrepo

Polyrepo means having repositories at the most granular level but ideally, it should be a one-to-one mapping between a repository and a service.

Following are 3 factors and anti-factors you should use to determine which repository architecture is right for you.

The Celebrity Syndrome (Anti-factor)

I find it funny when I see one of the arguments for using monrepo is that Google and Facebook use it. I call it the Kardashian effect. Hyperscalers have different scales, different needs, and most likely are using highly customized version control systems. They also have immense technical debt. This argument is ridiculous and therefore I call it an anti-factor.

Are you using Git or a stone-age version control system?

I am not Linus but what I understand is that the way git is designed has a huge influence on how you structure your repositories. Git stores the whole repository as a blob and then applies every commit as a layer of change on top of it. Think of a monorepo for a significant size company that is using git. it’s a non-starter.

In legacy source control systems, the granularity of operation is at a file system level. I am simplifying it as the organization of file systems and blocks is outside the scope of this blog. The key fact is that legacy file systems have more ways to avoid the negative effects of monorepo.

Are you using modern DevOps practices?

If you are using continuous integration and/or continuous deployment, it becomes very easy to define the pipeline if you have a polyrepo. In fact, in a repo designed for a single service or application, it is recommended (read mandatory) to also bundle in infrastructure as code. It is also possible to automate most of the DevOps pipeline using modern infrastructure as a service (EaaS) tools like roost.io.

Summary

Monorepo architecture may work for smaller teams but the power a developer gets by using polyrepo is immense. It is a good idea to use a nuanced approach to build repositories so each repo represents an application or service and nothing else.

This post was created with Typeshare