8 ms·

After years of working with various microservice-based systems, I got the impression that the whole idea of "microservices" means ignoring various nuances of pa

After years of working with various microservice-based systems, I got the impression that the whole idea of "microservices" means ignoring various nuances of particular products and organizations and just splitting your system in a pinky-sized codebases and services. You are completely right, every project is different, and that's why the general idea of microservices is bad. Split your services where there are technical or heavy political and organizational reasons to do so, but don't go for splitting as your default solution.

bluGill 3y ago
Your code structure should match your org chart is the best advice I've seen for splitting code. Each team in the org maintains their own micro service. They do whatever they want within it, but when going to a different one they go to an interface. It isn't perfect, but it seems to work the best.
- lelanthran 3y ago
  > Your code structure should match your org chart is the best advice I've seen for splitting code. I've seen that so often it now feels like a sarcastic meme to me. The org structure changes much faster than your code structure does. Good luck getting those two to stay in sync longer than the CTO stays in their role.
- vilunov 3y ago
  There are interfaces besides RPCs
- bdougherty 3y ago
  Until the org chart is reorganized, then what?
  - bluGill 3y ago
    Then you reorg the system. Note that this can go either direction - you can also change your system to how you want the org chart to look. Generally it goes one way because engineers rarely have the power to change the org chart, but sometimes we are consulted and can suggest 'improvements'.
    - pacaro 3y ago
      You can't fight Conways Law[1]. Or you can fight it I guess, but you will lose. [1] https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law
- dasil003 3y ago
  Org charts tend to change faster than services can possibly be re-architected in a large scale system that is growing quickly. Honestly you need a critical mass of engineers who can think end-to-end with a product and business-first mentality, they should decide what tradeoffs make the most sense taking into account a broad range of hypothetical future requirements and what makes sense given current domain knowledge. They must do this with real expertise and ownership, not basing it purely on a 3-year roadmap from non-technical PM. Then teams should be organized around the design of these systems (not the other way around). This overall process should be repeated iteratively as the product and business scales.

bluGill 3y ago

Your code structure should match your org chart is the best advice I've seen for splitting code. Each team in the org maintains their own micro service. They do whatever they want within it, but when going to a different one they go to an interface. It isn't perfect, but it seems to work the best.

lelanthran 3y ago
> Your code structure should match your org chart is the best advice I've seen for splitting code. I've seen that so often it now feels like a sarcastic meme to me. The org structure changes much faster than your code structure does. Good luck getting those two to stay in sync longer than the CTO stays in their role.
vilunov 3y ago
There are interfaces besides RPCs
bdougherty 3y ago
Until the org chart is reorganized, then what?
- bluGill 3y ago
  Then you reorg the system. Note that this can go either direction - you can also change your system to how you want the org chart to look. Generally it goes one way because engineers rarely have the power to change the org chart, but sometimes we are consulted and can suggest 'improvements'.
  - pacaro 3y ago
    You can't fight Conways Law[1]. Or you can fight it I guess, but you will lose. [1] https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law
dasil003 3y ago
Org charts tend to change faster than services can possibly be re-architected in a large scale system that is growing quickly. Honestly you need a critical mass of engineers who can think end-to-end with a product and business-first mentality, they should decide what tradeoffs make the most sense taking into account a broad range of hypothetical future requirements and what makes sense given current domain knowledge. They must do this with real expertise and ownership, not basing it purely on a 3-year roadmap from non-technical PM. Then teams should be organized around the design of these systems (not the other way around). This overall process should be repeated iteratively as the product and business scales.