4 ms·

Organized as in... kept in different repos? People live/die on this hill and it makes no sense. One or many repos, it's just an organizational question, not som

Organized as in... kept in different repos? People live/die on this hill and it makes no sense. One or many repos, it's just an organizational question, not some Super Serious Big Decision. I work at a small, early stage startup and I'm about to create a new repo for our Slack bot. I'm going to use the Docker image another of our repos generates as the base Docker image for this new repo, and it's going to be just fine.

lolinder 4y ago
Organized as in everything lives in the same deployment unit (and therefore most likely in the same repo) but with clearly defined module boundaries. If you've got separate docker images, you have separate services. OP is saying that most startups that think they need to split out their code into independent services actually just need to organize their single service better. > One or many repos, it's just an organizational question, not some Super Serious Big Decision. When people talk about monoliths they're not usually talking about repo structure, they're talking about deployment structure. One or many repos is just an arbitrary organizational question. One or many services is a really big deal: It's the difference between running a distributed system and not.
- TameAntelope 4y ago
  "one or many services" is also not a Really Big Deal. You can have a few services that do a category of things and not even sniff microservices architecture. It's not a boolean, it's a spectrum, and where precisely you land on that spectrum is not as important if you're actually focused on getting work done.
  - lolinder 4y ago
    It's a spectrum, yes, and adding an extra service might be the right move, especially if they are well and truly independent (don't interact with each other). But it's still a significant architectural decision to go for a distributed system, much more so than whether you split your services into separate repos or go for a monorepo. Getting work done is important, but it's not an excuse to avoid thinking through the long-term implications of your decisions. If you shrug and say "it's just one more service" every time you're tempted to add a new docker image, you'll not just end up with microservices, you'll end up with poorly planned microservices.
- taowen 4y ago
  It is just like static linking in c. We can split code into different object files, and statically link to a big application. We help of header file, we can invert the dependency relationship to keep implementation private to keep autonomy. It also applies to node.js/web frontend application, here is a vite demo: https://github.com/taowen/vite-howto/tree/main/packages/STATIC-LINKING/inversion-of-control https://github.com/taowen/vite-howto/tree/main/packages/STAT...
yCombLinks 4y ago
You're missing the point entirely. The big deal is choosing between 1. distributed vs non-distributed. 2. A single build deploy process / release cycle, vs multiple. A distributed system and multiple build systems / releases is orders of magnitude more complex over time.

lolinder 4y ago

Organized as in everything lives in the same deployment unit (and therefore most likely in the same repo) but with clearly defined module boundaries. If you've got separate docker images, you have separate services. OP is saying that most startups that think they need to split out their code into independent services actually just need to organize their single service better. > One or many repos, it's just an organizational question, not some Super Serious Big Decision. When people talk about monoliths they're not usually talking about repo structure, they're talking about deployment structure. One or many repos is just an arbitrary organizational question. One or many services is a really big deal: It's the difference between running a distributed system and not.

TameAntelope 4y ago
"one or many services" is also not a Really Big Deal. You can have a few services that do a category of things and not even sniff microservices architecture. It's not a boolean, it's a spectrum, and where precisely you land on that spectrum is not as important if you're actually focused on getting work done.
- lolinder 4y ago
  It's a spectrum, yes, and adding an extra service might be the right move, especially if they are well and truly independent (don't interact with each other). But it's still a significant architectural decision to go for a distributed system, much more so than whether you split your services into separate repos or go for a monorepo. Getting work done is important, but it's not an excuse to avoid thinking through the long-term implications of your decisions. If you shrug and say "it's just one more service" every time you're tempted to add a new docker image, you'll not just end up with microservices, you'll end up with poorly planned microservices.
taowen 4y ago
It is just like static linking in c. We can split code into different object files, and statically link to a big application. We help of header file, we can invert the dependency relationship to keep implementation private to keep autonomy. It also applies to node.js/web frontend application, here is a vite demo: https://github.com/taowen/vite-howto/tree/main/packages/STATIC-LINKING/inversion-of-control https://github.com/taowen/vite-howto/tree/main/packages/STAT...

yCombLinks 4y ago

You're missing the point entirely. The big deal is choosing between 1. distributed vs non-distributed. 2. A single build deploy process / release cycle, vs multiple. A distributed system and multiple build systems / releases is orders of magnitude more complex over time.