4 ms·

>The latest paradigm “Microservices” became popular in the mid 2010s. Microservices isn't for re-usability. It's main benefit is better encapsulation, which sh

>The latest paradigm “Microservices” became popular in the mid 2010s. Microservices isn't for re-usability. It's main benefit is better encapsulation, which should let you do independent resource management/deployments/failures. >If we look at reusability, we notice that this is the tightest form of coupling possible: If the reused part is not available, the reusing part cannot complete its work by definition. What? This is a weird nothing-burger of a sentence. Why can't multiple components re-use some resource without gracefully handling any failures? Why does re-usability mean "cascading failures by design"? >An important property of reuse is that the reusing part ... does not work without the reused asset ... The reused functionality is an integral part of the solution that (re-)uses it. Oh, I see: because the author has defined it this way. Then the article goes on to try to argue a semantic difference between "usability" and "re-usability", in that usable components can be re-used independently, but in a way that can gracefully fail! So the whole thing is just begging the question. There's no argument here as to why I can't write a distributed component with an eye to it being re-used in the future. There is no criticism of re-use in distributed systems. The only criticism is of tight coupling, which is totally valid, and then saying that re-use demands tight coupling, which is not substantiated.

jungturk 7y ago
>An important property of reuse is that the reusing part ... does not work without the reused asset Its also naive to expect that implementing your own local provider (if even an option for you) will generally improve on the reliability over a remote/reused provider.
hinkley 7y ago
Or independent rewrites.
smitty1e 7y ago
> Microservices isn't for re-usability. Isn't that AWS Lamdba environment getting reused at a very high frequency? Maybe what we should consider is that coarse-reuseabulty--thinking OS and container images, cloud services--works semi-well, but that the more fine the grain of the re-use at the application level, the more TFA author's points kick in.
derefr 7y ago
I think the concept the author is talking around here can be stated more simply: When you refactor software to reduce duplication, you by default are increasing coupling. At the start, you some lines of code that were just sitting in the bodies of two different functions. Now, both of those functions call one shared function. But, in a proper minimal-change refactoring, you didn't change the semantics of the code by doing this. So the shared function is still acting the way that its parents did: as sets of lines sitting in the bodies of functions. There's no circuit breaking or graceful failure there, because there was no circuit breaking or graceful failure in the original, non-refactored code. Another way to put this is: compression makes data more fragile, in the sense that small numbers of bits can be "depended on" by more bits in compressed data than in uncompressed data. Direct duplication-elimination refactoring is, essentially, just compression. To actually get robustness, you can't just do this kind of refactoring and then stop; you have to continue on and introduce a stable API to your factored-out function/component/service, with a specified interface. Once you do that, then you cancel out the increase of coupling, because now everything is just coupled to a description of the interface. Then you get the ability to re-use the function/component/service. Until you do that, though, you just have something that is known to work exactly in the use-cases it was extracted from; and which shouldn't be expected to work anywhere else.
- ivanbakel 7y ago
  I'd agree with you for this post, minus the weird re/usability semantics, but that interpretation goes against the previous parts of this series. If you read Part 1, the argument is largely against even well-architectured versions of re-usability. The author takes issue with all components designed for drop-in future use, believing that each problem requires a tailor-made solution. The re/usability debate seems weirdly entangled with the coupling debate for no good reason. The author believes re-usability means tight coupling, and "usability" means good APIs with loose coupling (which can be re-used...).

jungturk 7y ago

>An important property of reuse is that the reusing part ... does not work without the reused asset Its also naive to expect that implementing your own local provider (if even an option for you) will generally improve on the reliability over a remote/reused provider.

hinkley 7y ago

Or independent rewrites.

smitty1e 7y ago

> Microservices isn't for re-usability. Isn't that AWS Lamdba environment getting reused at a very high frequency? Maybe what we should consider is that coarse-reuseabulty--thinking OS and container images, cloud services--works semi-well, but that the more fine the grain of the re-use at the application level, the more TFA author's points kick in.

derefr 7y ago

I think the concept the author is talking around here can be stated more simply: When you refactor software to reduce duplication, you by default are increasing coupling. At the start, you some lines of code that were just sitting in the bodies of two different functions. Now, both of those functions call one shared function. But, in a proper minimal-change refactoring, you didn't change the semantics of the code by doing this. So the shared function is still acting the way that its parents did: as sets of lines sitting in the bodies of functions. There's no circuit breaking or graceful failure there, because there was no circuit breaking or graceful failure in the original, non-refactored code. Another way to put this is: compression makes data more fragile, in the sense that small numbers of bits can be "depended on" by more bits in compressed data than in uncompressed data. Direct duplication-elimination refactoring is, essentially, just compression. To actually get robustness, you can't just do this kind of refactoring and then stop; you have to continue on and introduce a stable API to your factored-out function/component/service, with a specified interface. Once you do that, then you cancel out the increase of coupling, because now everything is just coupled to a description of the interface. Then you get the ability to re-use the function/component/service. Until you do that, though, you just have something that is known to work exactly in the use-cases it was extracted from; and which shouldn't be expected to work anywhere else.

ivanbakel 7y ago
I'd agree with you for this post, minus the weird re/usability semantics, but that interpretation goes against the previous parts of this series. If you read Part 1, the argument is largely against even well-architectured versions of re-usability. The author takes issue with all components designed for drop-in future use, believing that each problem requires a tailor-made solution. The re/usability debate seems weirdly entangled with the coupling debate for no good reason. The author believes re-usability means tight coupling, and "usability" means good APIs with loose coupling (which can be re-used...).