3 ms·

I prefer microservices/microrepos _conceptually_, but we had the same experience as your quoted text - making changes to four repos, and backporting those chang

I prefer microservices/microrepos _conceptually_, but we had the same experience as your quoted text - making changes to four repos, and backporting those changes to the previous two release branches, means twelve separate PRs to make a change. Having a centralized configuration library (a shared Makefile that we can pull down into our repo and include into the local Makefile) helps, until you have to make a backwards-incompatible change to that Makefile and then post PRs to every branch of every repo that uses that Makefile. Now we have almost the entirety of our projects back into one repository and everything is simpler; one PR per release branch, three PRs (typically) for any change that needs backporting. Vastly simpler process and much less room for error.

esperent 2y ago
Isn't there some middle ground between microservices and monorepos? For example, a few large clearly defined projects that talk to each other via versioned APIs?
- svieira 2y ago
  Mono-repo is not the same as mono-service. You can deploy multiple services out of a single repository.
- 0xFACEFEED 2y ago
  Assuming you're just referring to repos: not really IMO. As soon as you split 1 repo into 2 repos you need to start building tooling to support your 2 repos. If your infrastructure is sufficiently robust with 2 repos then you might as well have 3 or 4 or 10. If it's built to _only_ support 2 repos (or 3 or 4) then it's brittle out of the gate. The value of a monorepo is that you completely eliminate certain classes of problems and take on other classes of problems. Classic trade off. Folks that prefer monorepos take the position that multirepo problems are much harder than monorepo problems most of the time.
  - Lvl999Noob 2y ago
    The classic 0, 1, or N. You can have 0 repos (no-code or outsourced or just some unversioned blob of code). You can have 1 repo (a mono-repo). Or you can have N number of repos (individual micro services). Limiting yourself to a number that's higher than 1 but still finite is just asking for pain. (Of course implementation limits can apply but there shouldn't be logical limits)
    - echelon 2y ago
      Monorepo and microservices are orthogonal. You can have as many build targets in a monorepo as you like. You can also have large monoliths in a monorepo.
      - bvrmn 2y ago
        I worked with monolith split into multiple repos as well. It's orthogonal indeed.
  - chipdart 2y ago
    > As soon as you split 1 repo into 2 repos you need to start building tooling to support your 2 repos. No, not really. If you're talking about projects for modules and components, all you need is a versioning strategy and release consumable packages of your projects. If you're talking about services, all you need to do is support versioned APIs and preserve your contracts. No tooling required. For projects you can even make do with git submodules. For services, all you need to do is update clients of your downstream dependencies. What problems are you facing, exactly?
    - joshuamorton 2y ago
      Let me rephrase this: If you aren't using a monorepo, you need some versioning process, as well as procedural systems in place to ensure that everyone's dependencies, stay reasonably up to date. Otherwise, you end up deferring pain in really unwanted ways, and require sudden, unwanted upgrades through api incompatibility due to external pressure. This also has the downside of allowing api-owning teams to make changes willy-nilly and break backwards compatibility because they can just do it behind SemVer, and then clients of the api need to own the process of migrating to the new version. A monorepo fixes both of these: you cannot get out of sync, so it is the api-owning team's responsibility to upgrade clients, since they can't break the API otherwise. Similarly, you get a versioning process for free, and clients can never be using out of date or out of support versions of a dependency. Services work approximately the same either way, since you can't assume synchronous upgrades across service/rpc boundaries anyway.
- KGunnerud 2y ago
  Done that at two different places. This was public sector in both cases so typically many products in the organization. So one product was one monorepo. Wrote this some years ago: https://dev.to/kgunnerud/our-experience-monorepo-with-java-maven-and-github-actions-2aho https://dev.to/kgunnerud/our-experience-monorepo-with-java-m... Nobody in our team wants to go back to nonmonorepo now, although everone was sceptical initially
- mirekrusin 2y ago
  Two monorepos: Primary monorepo – single versioned packages for libraries and services that are deployed as a whole. Secondary monorepo – individually versioned packages for shared libraries and independent (micro)services.
chipdart 2y ago
> I prefer microservices/microrepos _conceptually_, but we had the same experience as your quoted text - making changes to four repos, and backporting those changes to the previous two release branches, means twelve separate PRs to make a change. You only need to coordinate this sort of changes if you have absolutely no versioning strategy in place and accept breaking contracts for no reason at all. If you have any form of versioning in place, you do not need to push multi-project commits. You update upstream packages and services, roll them out, and proceed to update the projects that consume them to gradually point them to the newly released versions.
- gugagore 2y ago
  Surely the git SHA is "a form of versioning", isn't it? Yet I don't see how that form of versioning helps.
  - chipdart 2y ago
    > Surely the git SHA is "a form of versioning", isn't it? If you're consuming a module from a git as a submodule, yes.

esperent 2y ago

Isn't there some middle ground between microservices and monorepos? For example, a few large clearly defined projects that talk to each other via versioned APIs?

svieira 2y ago
Mono-repo is not the same as mono-service. You can deploy multiple services out of a single repository.
0xFACEFEED 2y ago
Assuming you're just referring to repos: not really IMO. As soon as you split 1 repo into 2 repos you need to start building tooling to support your 2 repos. If your infrastructure is sufficiently robust with 2 repos then you might as well have 3 or 4 or 10. If it's built to _only_ support 2 repos (or 3 or 4) then it's brittle out of the gate. The value of a monorepo is that you completely eliminate certain classes of problems and take on other classes of problems. Classic trade off. Folks that prefer monorepos take the position that multirepo problems are much harder than monorepo problems most of the time.
- Lvl999Noob 2y ago
  The classic 0, 1, or N. You can have 0 repos (no-code or outsourced or just some unversioned blob of code). You can have 1 repo (a mono-repo). Or you can have N number of repos (individual micro services). Limiting yourself to a number that's higher than 1 but still finite is just asking for pain. (Of course implementation limits can apply but there shouldn't be logical limits)
  - echelon 2y ago
    Monorepo and microservices are orthogonal. You can have as many build targets in a monorepo as you like. You can also have large monoliths in a monorepo.
    - bvrmn 2y ago
      I worked with monolith split into multiple repos as well. It's orthogonal indeed.
- chipdart 2y ago
  > As soon as you split 1 repo into 2 repos you need to start building tooling to support your 2 repos. No, not really. If you're talking about projects for modules and components, all you need is a versioning strategy and release consumable packages of your projects. If you're talking about services, all you need to do is support versioned APIs and preserve your contracts. No tooling required. For projects you can even make do with git submodules. For services, all you need to do is update clients of your downstream dependencies. What problems are you facing, exactly?
  - joshuamorton 2y ago
    Let me rephrase this: If you aren't using a monorepo, you need some versioning process, as well as procedural systems in place to ensure that everyone's dependencies, stay reasonably up to date. Otherwise, you end up deferring pain in really unwanted ways, and require sudden, unwanted upgrades through api incompatibility due to external pressure. This also has the downside of allowing api-owning teams to make changes willy-nilly and break backwards compatibility because they can just do it behind SemVer, and then clients of the api need to own the process of migrating to the new version. A monorepo fixes both of these: you cannot get out of sync, so it is the api-owning team's responsibility to upgrade clients, since they can't break the API otherwise. Similarly, you get a versioning process for free, and clients can never be using out of date or out of support versions of a dependency. Services work approximately the same either way, since you can't assume synchronous upgrades across service/rpc boundaries anyway.
KGunnerud 2y ago
Done that at two different places. This was public sector in both cases so typically many products in the organization. So one product was one monorepo. Wrote this some years ago: https://dev.to/kgunnerud/our-experience-monorepo-with-java-maven-and-github-actions-2aho https://dev.to/kgunnerud/our-experience-monorepo-with-java-m... Nobody in our team wants to go back to nonmonorepo now, although everone was sceptical initially
mirekrusin 2y ago
Two monorepos: Primary monorepo – single versioned packages for libraries and services that are deployed as a whole. Secondary monorepo – individually versioned packages for shared libraries and independent (micro)services.

chipdart 2y ago

> I prefer microservices/microrepos _conceptually_, but we had the same experience as your quoted text - making changes to four repos, and backporting those changes to the previous two release branches, means twelve separate PRs to make a change. You only need to coordinate this sort of changes if you have absolutely no versioning strategy in place and accept breaking contracts for no reason at all. If you have any form of versioning in place, you do not need to push multi-project commits. You update upstream packages and services, roll them out, and proceed to update the projects that consume them to gradually point them to the newly released versions.

gugagore 2y ago
Surely the git SHA is "a form of versioning", isn't it? Yet I don't see how that form of versioning helps.
- chipdart 2y ago
  > Surely the git SHA is "a form of versioning", isn't it? If you're consuming a module from a git as a submodule, yes.