4 ms·

> the major foot-gun that got a lot of places in trouble was the premature move to microservices I sometimes wonder if the move to microservices isn't just a w

by bambax 4y ago

> the major foot-gun that got a lot of places in trouble was the premature move to microservices I sometimes wonder if the move to microservices isn't just a weird consequence of Conway's law in reverse: make a department of each developer, let them have their thing. (See also this amazing video about Conway's law: https://www.youtube.com/watch?v=5IUj1EZwpJY https://www.youtube.com/watch?v=5IUj1EZwpJY )

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 ago
  You can do that without introducing a HTTP/RPC boundary.
  - mejutoco 4y ago
    You can, but it requires discipline and/or tooling. With microservices you are very incentivized (I would say forced).
    - mjdiloreto 4y ago
      Exactly! 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 ago
        I 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).

by bambax 4y ago

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 ago
You can do that without introducing a HTTP/RPC boundary.
- mejutoco 4y ago
  You can, but it requires discipline and/or tooling. With microservices you are very incentivized (I would say forced).
  - mjdiloreto 4y ago
    Exactly! 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 ago
      I 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).