4 ms·

> If you put microservices in a monorepo (...) What exactly do you gain with this approach, other than pinning versions of all microservices? Any competent te

> If you put microservices in a monorepo (...) What exactly do you gain with this approach, other than pinning versions of all microservices? Any competent team working on services does not suffer from "versioning hell" because APIs are stable and tracked with integration tests and smoke tests, and you version the API and not the code.

TakkemTan 4y ago
It vastly reduces the complexity of things like dependencies, testing, CI/CD, versioning. Dependencies can be relative paths. Relative path dependencies will break the build on your machine, so you don't get devs pushing broken stuff. CI/CD servers don't get plugged up with billions of repos building because one changed. CI/CD servers don't need to wait for other builds to finish and push artifacts to do their job. Testers don't need to say "I used version 10.2 of x and 11.5 of y", they can have a single version number for the whole stack. All these things are possible with microservices in different repos. But they require a lot more time to set up and require regular maintianance. If your company isn't large enough to need that, then it makes no sense to move away from a monorepo. Arguably no company is big enough, Google has all it's code in a single 80 terabyte monorepo. But I can understand why that wouldn't scale well either...
- simplotek 4y ago
  > It vastly reduces the complexity of things like dependencies, testing, CI/CD, versioning. Did it, though? The only conceivable advantage is version pinning. I makes absolutely no difference in terms of test coverage whether you use a monorepo or not. Dependencies-wise, the only thing that a monorepo saves is releasing individual components, which ultimately is not an advantage but a drawback and a liability. So exactly what's the upside, if any?
  - cobalt 4y ago
    what is the upside of separating them?

TakkemTan 4y ago

It vastly reduces the complexity of things like dependencies, testing, CI/CD, versioning. Dependencies can be relative paths. Relative path dependencies will break the build on your machine, so you don't get devs pushing broken stuff. CI/CD servers don't get plugged up with billions of repos building because one changed. CI/CD servers don't need to wait for other builds to finish and push artifacts to do their job. Testers don't need to say "I used version 10.2 of x and 11.5 of y", they can have a single version number for the whole stack. All these things are possible with microservices in different repos. But they require a lot more time to set up and require regular maintianance. If your company isn't large enough to need that, then it makes no sense to move away from a monorepo. Arguably no company is big enough, Google has all it's code in a single 80 terabyte monorepo. But I can understand why that wouldn't scale well either...

simplotek 4y ago
> It vastly reduces the complexity of things like dependencies, testing, CI/CD, versioning. Did it, though? The only conceivable advantage is version pinning. I makes absolutely no difference in terms of test coverage whether you use a monorepo or not. Dependencies-wise, the only thing that a monorepo saves is releasing individual components, which ultimately is not an advantage but a drawback and a liability. So exactly what's the upside, if any?
- cobalt 4y ago
  what is the upside of separating them?