One service, one source repository. It’s a common pattern for startups. Multiple repositories give small engineering teams ownership of their own libraries and microservices, without the knowledge overhead of other source code. A monorepo is the opposite choice — putting all of the organization’s code in a single codebase. And it’s the right choice for a small company to keep people and code in sync. Many large companies, including Google and Facebook, agree too!
Monorepo != Monolith
At Datavant, we develop several services and libraries from our monorepo. Each of those is deployed separately. We still enjoy many of the benefits of a typical microservices + many-repo configuration, like independent deployment of services and build artifacts, and clear owners for each service.
Why monorepo? Keep people and code in sync
New developers learn from changes across the codebase. Experienced developers can easily review PRs in other projects. It’s easier to keep style conventions consistent across projects, and easier to avoid knowledge silos.
It forces atomic (all-at-once) changes and keeps dependencies in sync. If you make a breaking change to a library, you have to fix all consumers of that library in the same change otherwise tests will fail. With separate repos, it becomes a song-and-dance to update the library, publish a new build, and have separate teams update each consumer one-by-one, over days or weeks.
Why not monorepo? Requires high tooling investment
It’s not perfect. We already pay a price for the benefits of a monorepo, and these will grow over time.
We run extraneous builds and tests on every PR. We’re looking to solve this with better tooling, using a dependency-based build system like Bazel. Another problem is the growth of repository size as new revisions are added — like Pepperidge Farm, git remembers.
Many repos require high tooling as well
The tooling challenges aren’t unique to the monorepo. Managing dependencies and versions is complex and error-prone with many repos. Cross-service integration tests are also more complex with many repos. The challenges of long build and CI times, extraneous tests, and repository size also affect many repos; you simply encounter these earlier with a monorepo.
We’re investing in the tooling to make our monorepo great, and we look forward to seeing more startups join us in this choice.
We’re hiring for DevOps engineers to make testing, deployment and monitoring infrastructure at Datavant world-class. Send me a note at aneesh@datavant.com.
