Monorepos

There has been a renewed buzz about monorepos recently. First of all there was that announcement from Github about git sparse-checkout, an experimental feature in Git 2.25.0 that simplifies the process of partially dowloading a large repository, saving space and improving the performance. I suspect this feature was driven by the growing popularity of of the “microservices in a monorepo”.

Second, the new Software Engineering at Google book was recently released and it often references both the benefits and disadvantages to monorepos.

Over the last couple of years I experienced projects where monorepos organically came into being or were explicitly selected for. Similarly to many others out there I came to the same conclusions in terms of their advantages:

• Sharing dependencies, means managing less - if several services depend on eachother but are in the same repository you have the same version number so it’s less likely to encounter issues.
• No more cross-repo changes - many features I’ve had to implement, crossed service boundries and would require additional steps (cloning, checkingout, switching contexts), but with a monorepo it’s all in one place so you could make the change in a single commit.
• Seeing the bigger picture - if services from the same domain are centralised in a monorepo it’s much easier for someone to understand how they are related, rather than doing haphazard Github searches.

Macroservice:

- not a monolith
- Has no more than 20 devs/3 teams working on the service (5 pizza rule?)
- may or may not have/need monorepo. Dependency management becomes a lot easier (though still non-trivial) the fewer the services/repos
- better observability, debugging

— Cindy Sridharan (@copyconstruct) April 6, 2020

References:

• https://danluu.com/monorepo/
• https://research.google/pubs/pub45424/
• https://medium.com/@chrisnager/case-for-a-monorepo-28cebf26e1aa

image by Owen Davey