3 ms·

>If your codebase has failed to achieve modularity with tools such as functions and packages, it will not magically succeed by adding network layers and binary

>If your codebase has failed to achieve modularity with tools such as functions and packages, it will not magically succeed by adding network layers and binary boundaries inside it This is assuming you're converting an existing non-modular monolithic service to micro services. If you're starting from scratch or converting a modular monolithic service then this point is moot. It says nothing about the advantages or disadvantages of maintaining a modular code base with monoliths or microservices which is what people are actually talking about.

mic47 6y ago
If you are starting from scratch (again), you can make good monolith too, since you already know a lot about the problem you are solving.
- marcinzm 6y ago
  The issue generally isn't just creating something clean but rather it's maintaining something clean. Something that will be owned not by you but by multiple teams whose members change over the course of years. On a side note, I've found that creating something again usually leads to messes as you try to fix all the issues in the original which just creates new issues.
- bdcravens 6y ago
  This seems to always be the case when two alternatives are discussed on HN. The new and shiny is muddled with the new design, so it's hard to tease out where the improvement came from, and in most cases, the new design is possible in the old and trusted.
marcosdumay 6y ago
The point stands. If you can create good interfaces over a network, you can create good interfaces over function calls too.
- marcinzm 6y ago
  The difference you miss is that the former discourages bad interfaces and the latter does not. There is no "you" in most businesses. There's dozens of people who changes over time. People with deadlines and concerns of their own.
  - marcosdumay 6y ago
    > the former discourages bad interfaces That does entirely depend on your language and tooling. > the latter does not And that does entirely depend on your processes and internal communication. If your people keep changing, your chances are much less astronomically bad with a monolith.

mic47 6y ago

If you are starting from scratch (again), you can make good monolith too, since you already know a lot about the problem you are solving.

marcinzm 6y ago
The issue generally isn't just creating something clean but rather it's maintaining something clean. Something that will be owned not by you but by multiple teams whose members change over the course of years. On a side note, I've found that creating something again usually leads to messes as you try to fix all the issues in the original which just creates new issues.
bdcravens 6y ago
This seems to always be the case when two alternatives are discussed on HN. The new and shiny is muddled with the new design, so it's hard to tease out where the improvement came from, and in most cases, the new design is possible in the old and trusted.

marcosdumay 6y ago

The point stands. If you can create good interfaces over a network, you can create good interfaces over function calls too.

marcinzm 6y ago
The difference you miss is that the former discourages bad interfaces and the latter does not. There is no "you" in most businesses. There's dozens of people who changes over time. People with deadlines and concerns of their own.
- marcosdumay 6y ago
  > the former discourages bad interfaces That does entirely depend on your language and tooling. > the latter does not And that does entirely depend on your processes and internal communication. If your people keep changing, your chances are much less astronomically bad with a monolith.