4 ms·

The cons to multi repo are all anti patterns for microservices anyway. If you're doing microservices you shouldn't have build dependencies on other projects. Th

The cons to multi repo are all anti patterns for microservices anyway. If you're doing microservices you shouldn't have build dependencies on other projects. The should only call eachother at a network level.

likeliv 7y ago
Calling eachother at network level is still a dependency. (And even a build dependency if you use something like protobuff or other protocol description files)
- nhumrich 7y ago
  A network dependency is not a build dependency. Protobuf files should be copy pasted, not referenced directly. Saying you need a single repo to build correctly for your network dependencies is like saying you cant use a third party system (aws, etc.) Without having a link to their code base.
  - likeliv 7y ago
    Point is that when you want to do a change in the "API" (or call it "protocol"), you need to touch the different repositories and coordinate to use the right versions together. About the copy/paste of protobuf files, it works but makes it more difficult to keep them in sync. And I did not say you need a single repo. I'm saying the stated disadvantages of multi repo are real.
pshirshov 7y ago
But... we do better things than microservices: https://github.com/7mind/slides/blob/master/02-roles/target/roles.pdf https://github.com/7mind/slides/blob/master/02-roles/target/...
- karmakaze 7y ago
  Read this, not worthwhile and OT.
  - pshirshov 7y ago
    > not worthwhile Why so? > and OT Not at all. In both cases it's about roles.
    - deleted 7y ago
      [deleted]
    - karmakaze 7y ago
      It misses the point of microservices in the same way that posts titled 'sharding' instead talk about load-balancing.
shhsshs 7y ago
That’s the part about monorepos I can’t quite wrap my mind around - yes deploying a single large change to many different systems simultaneously is cool in theory, but how does it actually pan out? Deployment is never instant, so any system-to-system breaking changes would cause a short downtime while everything deploys. In the world I operate in, that’s absolutely not acceptable. Not that you can’t still make your changes backwards compatible with themselves. But if I’m going to have to deploy everything in two steps anyway, what’s the point?

likeliv 7y ago

Calling eachother at network level is still a dependency. (And even a build dependency if you use something like protobuff or other protocol description files)

nhumrich 7y ago
A network dependency is not a build dependency. Protobuf files should be copy pasted, not referenced directly. Saying you need a single repo to build correctly for your network dependencies is like saying you cant use a third party system (aws, etc.) Without having a link to their code base.
- likeliv 7y ago
  Point is that when you want to do a change in the "API" (or call it "protocol"), you need to touch the different repositories and coordinate to use the right versions together. About the copy/paste of protobuf files, it works but makes it more difficult to keep them in sync. And I did not say you need a single repo. I'm saying the stated disadvantages of multi repo are real.

pshirshov 7y ago

But... we do better things than microservices: https://github.com/7mind/slides/blob/master/02-roles/target/roles.pdf https://github.com/7mind/slides/blob/master/02-roles/target/...

karmakaze 7y ago
Read this, not worthwhile and OT.
- pshirshov 7y ago
  > not worthwhile Why so? > and OT Not at all. In both cases it's about roles.
  - deleted 7y ago
    [deleted]
  - karmakaze 7y ago
    It misses the point of microservices in the same way that posts titled 'sharding' instead talk about load-balancing.

shhsshs 7y ago

That’s the part about monorepos I can’t quite wrap my mind around - yes deploying a single large change to many different systems simultaneously is cool in theory, but how does it actually pan out? Deployment is never instant, so any system-to-system breaking changes would cause a short downtime while everything deploys. In the world I operate in, that’s absolutely not acceptable. Not that you can’t still make your changes backwards compatible with themselves. But if I’m going to have to deploy everything in two steps anyway, what’s the point?