5 ms·

> “It is as if some people think "good code" and "microservices" are synonyms. No. They are orthogonal.” I disagree very strongly, and it is also part of why I

by mlthoughts2018 8y ago

> “It is as if some people think "good code" and "microservices" are synonyms. No. They are orthogonal.” I disagree very strongly, and it is also part of why I believe monorepos are generally a mistake. Microservices are a natural extension of things like decoupling and Single Responsibility Principle. Just because you superficially could achieve similar effects with gargantuan amounts of tooling and imposed conventions in a monolith class or something is absolutely no type of refutation of the fact that modularity and separated boundaries between encapsulations of units of behavior represent a better way to organize and structure the design. It is no different and there is no leakiness to the same abstraction when you move to discuss services instead of classes or source code units, or polyrepos v monorepos. The abstraction definitely can become leaky if taken too far in other domains, it just happens that the abstraction is depicting precisely the same organizational complexity properties in the case of source code -> service boundaries -> repository boundaries.

dagss 8y ago
Well, but some services composed of microservices turn into a distributed spaghetti monolith though. They only "naturally decouple" if you draw the lines between units correctly in the first place. And if you are able to do that well, that's the most important step in making any code turn out well regardless of the size of the services and how much of the boundaries are in the same class/repo/process/service. It also correlates with the "tendency to cheat" within a single service. There ARE real advantages to micro-services, sure. But you trade them against an ability to quickly refactor if it turns out you drew the lines completely wrong initially. Or perhaps you end up with something that becomes very complex that could in fact have been short-circuited and replaced by 5% as much code by looking at the problem from an entirely different angle -- which you never do because of the pattern that has settled in how the micro-services were divided. (At the end of the day, the code that is simplest to maintain is the one you don't need to run..) So I maintain that it's a trade-off. This seems relevant: https://xkcd.com/2044/ https://xkcd.com/2044/
- mlthoughts2018 8y ago
  What you propose ends up sounding like this from my point of view: Salad is generally better for your health than red meat. However, some people eat so much salad, with so much dressing, that it ends up being worse than red meat. Meanwhile, with great care about meal planning and moderation, some people stay pretty healthy eating red meat. Therefore red meat is actually healthier than salad.
  - dagss 8y ago
    Well in that context, red meat is obviously healthier if you know up front that the people in question are going to pile on dressing... Context is everything. I am mainly advocating that it depends on the kind of coders on the teams, how many teams, how sure you are about the up front design / boundaries between services (I have seen such boundaries drawn VERY wrong, so wrong that nothing else ever mattered), how sure you are about the spec, etc Start with monolith and refactor smaller services gradually as the design solidifies...
    - balfirevic 8y ago
      > Well in that context, red meat is obviously healthier if you know up front that the people in question are going to pile on dressing... I think you're being too charitable accepting this analogy at all - somehow microservices are presented as something obviously and inherently better (salad) versus non-microservice approach (red meat). If we're going down the route of silly analogies which are terrible way to argue anything, how about this: Non-microservice architectures are normal diet of meat, fish, vegetables, grains and sugar which you can keep under control if you have any idea of what you're doing. Microservices are gluten-free diet - very popular for no good reason, it makes everything harder and you should only pursue it if you have very good reason to and you understand the cons.
      - mlthoughts2018 8y ago
        > “somehow microservices are presented as something obviously and inherently better (salad) versus non-microservice approach (red meat).” Yes, this is called the Single Responsibility Principle, in this case applied to service architecture. More generally it is a property of modularity and decoupling. All else equal then satisfying these properties is better than not satisfying them. The all else equal assumption clearly holds in practice, where people write equally awful code in both cases and so microservices introduces no additional tech debt yet it does introduce SRP and modularity benefits. Could you find specific examples of monolith services with small enough tech debt that they outperform some specific other example using microservices? Of course. Does this matter for reasoning more generally about which pattern is better ceteris paribus? Very little, probably not at all.

dagss 8y ago

Well, but some services composed of microservices turn into a distributed spaghetti monolith though. They only "naturally decouple" if you draw the lines between units correctly in the first place. And if you are able to do that well, that's the most important step in making any code turn out well regardless of the size of the services and how much of the boundaries are in the same class/repo/process/service. It also correlates with the "tendency to cheat" within a single service. There ARE real advantages to micro-services, sure. But you trade them against an ability to quickly refactor if it turns out you drew the lines completely wrong initially. Or perhaps you end up with something that becomes very complex that could in fact have been short-circuited and replaced by 5% as much code by looking at the problem from an entirely different angle -- which you never do because of the pattern that has settled in how the micro-services were divided. (At the end of the day, the code that is simplest to maintain is the one you don't need to run..) So I maintain that it's a trade-off. This seems relevant: https://xkcd.com/2044/ https://xkcd.com/2044/

mlthoughts2018 8y ago
What you propose ends up sounding like this from my point of view: Salad is generally better for your health than red meat. However, some people eat so much salad, with so much dressing, that it ends up being worse than red meat. Meanwhile, with great care about meal planning and moderation, some people stay pretty healthy eating red meat. Therefore red meat is actually healthier than salad.
- dagss 8y ago
  Well in that context, red meat is obviously healthier if you know up front that the people in question are going to pile on dressing... Context is everything. I am mainly advocating that it depends on the kind of coders on the teams, how many teams, how sure you are about the up front design / boundaries between services (I have seen such boundaries drawn VERY wrong, so wrong that nothing else ever mattered), how sure you are about the spec, etc Start with monolith and refactor smaller services gradually as the design solidifies...
  - balfirevic 8y ago
    > Well in that context, red meat is obviously healthier if you know up front that the people in question are going to pile on dressing... I think you're being too charitable accepting this analogy at all - somehow microservices are presented as something obviously and inherently better (salad) versus non-microservice approach (red meat). If we're going down the route of silly analogies which are terrible way to argue anything, how about this: Non-microservice architectures are normal diet of meat, fish, vegetables, grains and sugar which you can keep under control if you have any idea of what you're doing. Microservices are gluten-free diet - very popular for no good reason, it makes everything harder and you should only pursue it if you have very good reason to and you understand the cons.
    - mlthoughts2018 8y ago
      > “somehow microservices are presented as something obviously and inherently better (salad) versus non-microservice approach (red meat).” Yes, this is called the Single Responsibility Principle, in this case applied to service architecture. More generally it is a property of modularity and decoupling. All else equal then satisfying these properties is better than not satisfying them. The all else equal assumption clearly holds in practice, where people write equally awful code in both cases and so microservices introduces no additional tech debt yet it does introduce SRP and modularity benefits. Could you find specific examples of monolith services with small enough tech debt that they outperform some specific other example using microservices? Of course. Does this matter for reasoning more generally about which pattern is better ceteris paribus? Very little, probably not at all.