Monorepo

In the monorepo approach, your entire code base is in a single source control repository. It is very easy to perform operations over the entire code base. Whenever you make a change, it is reflected immediately in your entire code base. Versioning is pretty much off the table. That's great for keeping all your code in sync. But, if you do need to upgrade some parts of your systems incrementally, you'll need to come up with workarounds, such as creating a separate copy with your new changes. Also, the fact that your source code is always in sync doesn't mean that your deployed services are all using the latest version. If you always deploy all your services at once, you're pretty much building a monolith. Note that you may still have multiple repos if you contribute to third-party open source projects (even if you only use upstream versions after your changes were merged).

Another big issue with monorepo is that you might need a lot of custom tooling to manage your multi repo. Large companies, such as Google and Microsoft, use the multi-repo approach. They have special needs and the custom tooling aspect doesn't deter them. I'm on the fence if the multi-repo approach is appropriate for smaller organizations. However, I'll use a monorepo for the Delinkcious —the demo application—so, we will get to explore it together and form an opinion. A major downside is that many modern CI/CD tool chains use GitOps, which trigger changes in source control repos. When there is just one monorepo, you lose the one-to-one mapping between a source control repo and a microservice.