4 ms·
This is absolutely what microservices are about. It's arguably their strongest strength, because (at least in theory) I can decouple my team from your team and
by mjdiloreto 4y ago
This is absolutely what microservices are about. It's arguably their strongest strength, because (at least in theory) I can decouple my team from your team and we can _only_ communicate over a strict interface.
- treis 4y agoYou can do that without introducing a HTTP/RPC boundary.
- mejutoco 4y agoYou can, but it requires discipline and/or tooling. With microservices you are very incentivized (I would say forced).
- mjdiloreto 4y agoExactly! To be clear to parent commenter, I'm not endorsing microservices to solve this organizational problem, just pointing out it's part of the reason to choose microservices.
- treis 4y ago>You can, but it requires discipline and/or tooling. Pretty much every language comes with a way of exposing a limited API to other parts of the application. Java, as an example, requires you to specifically export the parts of your module that other modules are allowed to consume. If you only export a public API then you've achieved the same benefit as a microservice except now it's type checked and doesn't encounter the pitfalls of a network call.
- mejutoco 4y agoI agree with you. There ara ways, and they work. If you have different teams stepping on each other toes, they might be disincentivized to keep the separation. Ideally they will not, but without someone enforcing it a team might end in this situation. I see it as a potential social question (like Conway’s law).