4 ms·

Like versioning services, deployment of the code base, breaking out new microservices, transitioning to any container based deployment solution. Monorepos aren’

Like versioning services, deployment of the code base, breaking out new microservices, transitioning to any container based deployment solution. Monorepos aren’t just a nightmare for release management, they’re a nightmare for any sort of single responsibility oriented architecture. I’m really exhausted of “senior devs” that believe they’re architects championing monorepos just because they’re too lazy to change minor versions in a repo.

gonehome 5y ago
Like anything it's a tradeoff. You trade simplicity of having everything in one place vs. ability to independently version pieces at the cost of more complex tooling and build systems required to test. Usually there's some sweet spot, but the answer isn't obvious and one isn't clearly better.
hsn915 5y ago
Why is any of this necessary? You have to understand, many of us think microservices is a stupid idea, so the fact that the core of your argument is "monorepos make microservices difficult" is not an appealing argument.
- wirrbel 5y ago
  Where is this 'microservices is not the answer to everything' club? I want to sign up.
  - funcDropShadow 5y ago
    The definition of an ideology is a school of thought that claims to have the answer for everything. What does that tell us about the microservices fan club?
    - exikyut 5y ago
      Possibly that `problem-solving` is an external microservice that the microservices fan club depends on for all their answers.
    - wirrbel 5y ago
      If you have a hammer everything looks like a nail.
  - hsn915 5y ago
    I don't know any online community that esposes some of the ideas I believe about web technology. There's "handmade network" but they don't seem to be much into web programming.
Trasmatta 5y ago
I think you're massively misrepresenting the senior devs you've worked with if you think the reason they've advocated for monorepos is because they're "too lazy to change minor versions". If a monorepo puts a barrier in the way of turning everything into a microservice, then all the better, as far as I'm concerned.
hamandcheese 5y ago
How does a monorepo make any of these things harder? Make a new folder, slap a version on it, push your versioned artifacts. Container based solutions become harder? Again… build your artifacts and deploy all the containers you want? What is so hard about this? Meanwhile, with multi-repo you lose out on a whole host of opportunities to robustly track dependencies and keep things up to date.
- urthor 5y ago
  Monorepos don't make it harder. Everything in software is about dependencies, and monorepos are playing double or nothing with dependencies. The issue with Monorepos is that they can amplify bad decisions and tech debt. Any bad decisions are magnified across the organization. But they definitely don't make it easier or harder to make that initial bad decision. The upside is that dependencies are just there and not hidden behind interfaces. The downside is that a bad dependency cannot be abstracted behind a micro-service interface. Once it's out in the wild it can do crazy things.
- bryanrasmussen 5y ago
  >How does a monorepo make any of these things harder? Make a new folder, slap a version on it, push your versioned artifacts. not liking microservices myself but - if I did this wouldn't it mean that the code in version 19 was now removed from the code in version 18 and back in git history making it more difficult to figure out just where things went wrong on a difficult little edge case.
  - tharkun__ 5y ago
    I don't see where microservices or not have much to do with having a monorepo or not. We have a monorepo and we have both. We have "microservices" and we don't. It's also a huge variable term. What I call microservices you guys might call "a bunch of monoliths communicating with each other". Same difference. git bisect helps to easily identify hard to find but reproducible bugs. Since we try to have small PRs once you found the breaking commit it is usually easy enough to the find the bug. Murphy and exceptions obviously apply.
tharkun__ 5y ago
OP here. We do not version our services in that sense. It's a monorepo after all. We do have microservices. We use kubernetes. Deployment is a breeze. Only services with changes are actually deployed. We do hourly deploys to production. None of the issues you describe apply here and the monorepo works awesomely for us. This is a SaaS situation where all services making up that SaaS solution and that we host are in that monorepo. YMMV if you are in a different situation such as having to ship versioned software for customers to self host/install for example. Our accompanying software that is usable in conjunction with the SaaS solution is not part of that Monorepo and each of those are versioned and deployed to various external marketplaces.
- randmeerkat 5y ago
  There’s plenty of reasons to want to version APIs in a SaaS offering…
  - tharkun__ 5y ago
    That's a different story and a monorepo has zero effect on that. The versioning that was mentioned before was versioning of the services themselves, i.e. this build produces version 1.5.4, next build is 1.5.5 etc. We don't do that any longer since moving to a monorepo. We deploy by commit hash basically. That is way different from providing v1 of your API and changes come out in v2 of the API while you also still provide v1 of the same API. You can (and we do) do that perfectly well with or without a monorepo. Mostly for the public API. Internal API's often don't need to do versioning and one can go with backwards compatible changes and/or rolling a change out over multiple commit deploy cycles. Some of this will depend on your size I suppose. The larger the org, the more services etc. the more stable versioning I would suppose happening.
    - randmeerkat 5y ago
      > The larger the org, the more services etc. the more stable versioning I would suppose happening. Which is why I said in my original comment this may work fine in a small environment, but it won’t scale well.

gonehome 5y ago

Like anything it's a tradeoff. You trade simplicity of having everything in one place vs. ability to independently version pieces at the cost of more complex tooling and build systems required to test. Usually there's some sweet spot, but the answer isn't obvious and one isn't clearly better.

hsn915 5y ago

Why is any of this necessary? You have to understand, many of us think microservices is a stupid idea, so the fact that the core of your argument is "monorepos make microservices difficult" is not an appealing argument.

wirrbel 5y ago
Where is this 'microservices is not the answer to everything' club? I want to sign up.
- funcDropShadow 5y ago
  The definition of an ideology is a school of thought that claims to have the answer for everything. What does that tell us about the microservices fan club?
  - exikyut 5y ago
    Possibly that `problem-solving` is an external microservice that the microservices fan club depends on for all their answers.
  - wirrbel 5y ago
    If you have a hammer everything looks like a nail.
- hsn915 5y ago
  I don't know any online community that esposes some of the ideas I believe about web technology. There's "handmade network" but they don't seem to be much into web programming.

Trasmatta 5y ago

I think you're massively misrepresenting the senior devs you've worked with if you think the reason they've advocated for monorepos is because they're "too lazy to change minor versions". If a monorepo puts a barrier in the way of turning everything into a microservice, then all the better, as far as I'm concerned.

hamandcheese 5y ago

How does a monorepo make any of these things harder? Make a new folder, slap a version on it, push your versioned artifacts. Container based solutions become harder? Again… build your artifacts and deploy all the containers you want? What is so hard about this? Meanwhile, with multi-repo you lose out on a whole host of opportunities to robustly track dependencies and keep things up to date.

urthor 5y ago
Monorepos don't make it harder. Everything in software is about dependencies, and monorepos are playing double or nothing with dependencies. The issue with Monorepos is that they can amplify bad decisions and tech debt. Any bad decisions are magnified across the organization. But they definitely don't make it easier or harder to make that initial bad decision. The upside is that dependencies are just there and not hidden behind interfaces. The downside is that a bad dependency cannot be abstracted behind a micro-service interface. Once it's out in the wild it can do crazy things.
bryanrasmussen 5y ago
>How does a monorepo make any of these things harder? Make a new folder, slap a version on it, push your versioned artifacts. not liking microservices myself but - if I did this wouldn't it mean that the code in version 19 was now removed from the code in version 18 and back in git history making it more difficult to figure out just where things went wrong on a difficult little edge case.
- tharkun__ 5y ago
  I don't see where microservices or not have much to do with having a monorepo or not. We have a monorepo and we have both. We have "microservices" and we don't. It's also a huge variable term. What I call microservices you guys might call "a bunch of monoliths communicating with each other". Same difference. git bisect helps to easily identify hard to find but reproducible bugs. Since we try to have small PRs once you found the breaking commit it is usually easy enough to the find the bug. Murphy and exceptions obviously apply.

tharkun__ 5y ago

OP here. We do not version our services in that sense. It's a monorepo after all. We do have microservices. We use kubernetes. Deployment is a breeze. Only services with changes are actually deployed. We do hourly deploys to production. None of the issues you describe apply here and the monorepo works awesomely for us. This is a SaaS situation where all services making up that SaaS solution and that we host are in that monorepo. YMMV if you are in a different situation such as having to ship versioned software for customers to self host/install for example. Our accompanying software that is usable in conjunction with the SaaS solution is not part of that Monorepo and each of those are versioned and deployed to various external marketplaces.

randmeerkat 5y ago
There’s plenty of reasons to want to version APIs in a SaaS offering…
- tharkun__ 5y ago
  That's a different story and a monorepo has zero effect on that. The versioning that was mentioned before was versioning of the services themselves, i.e. this build produces version 1.5.4, next build is 1.5.5 etc. We don't do that any longer since moving to a monorepo. We deploy by commit hash basically. That is way different from providing v1 of your API and changes come out in v2 of the API while you also still provide v1 of the same API. You can (and we do) do that perfectly well with or without a monorepo. Mostly for the public API. Internal API's often don't need to do versioning and one can go with backwards compatible changes and/or rolling a change out over multiple commit deploy cycles. Some of this will depend on your size I suppose. The larger the org, the more services etc. the more stable versioning I would suppose happening.
  - randmeerkat 5y ago
    > The larger the org, the more services etc. the more stable versioning I would suppose happening. Which is why I said in my original comment this may work fine in a small environment, but it won’t scale well.