4 ms·
Huh? They can, and will, just add the things they want to the rest api of the microservice A and then call them from B. That doesn't change with microservices.
by esailija 4y ago
Huh? They can, and will, just add the things they want to the rest api of the microservice A and then call them from B. That doesn't change with microservices.
Look up a thing called "distributed monolith".
- jacobr1 4y agoThat is harder when each service and team has their own repo and review process. Doesn't mean they won't just get merged, but there is increased friction and less-trust about random PRs from engineers that aren't actively working on the same team, so those PRs might get more scrutiny.
- esailija 4y agoThen why cannot you have separate repos and review processes for modules? This has nothing to do with microservices vs modules.
- jacobr1 4y agoAgreed - ther is no reason for that not to be the case. It just is that in practice (and not as some essentialism of how organizations needs to structure things) that miroservices tend proliferate git-repos and modules tend to be part of monorepos. But, sure, there is no need for that to be the case. So given a world like that, the repo seperation is what enforces the friction for junior devs to submit changes across repos. With monorepos it is easier.