3 ms·

Monoliths have advantages except in that they also invite complexity (they do not necessitate it) when there's no clear interface between components. Even with

Monoliths have advantages except in that they also invite complexity (they do not necessitate it) when there's no clear interface between components. Even with interfaces, any empirically observable behavior can become a kind of contract - so nothing is perfect here. Microservices seem to serve Conway's Law more than anything else I can understand. Groups want to have scoped projects, and a bubble within which to work and validate what they do. But microservices seem to potentially hinder system-wide traceability, system-wide debugability and performance. Modularity eschews one class of problems for another. Both monolithic and modular designs require discipline to keep things manageable, and they're not the same kind of discipline or maturity.

crabbone 3y ago
This is not an argument against modularity. The argument is that if you want modularity -- go all the way. Microservices is the argument that says "nah, let's divorce, but keep living in the same house". Here, to make it more concrete: two Unix programs assume no knowledge of each other's existence (ideally), they rely on standard input / output / pipes / signals (i.e. some communication methods that aren't unique to any of the programs, but provided by the third program -- environment). This, in my example would be to go all the way: no need to know that the other program exists. Microservices are as if you had an OS similar to Unix, but any pair of programs could decide on their own kind of pipes / signals / the way loader resolves symbols / function calling convention etc. Now, the argument the proponents make is that it's hard to make a universal "medium" used by all programs run in such an environment, and that if you want to "move fast", then you can skip working on this universal "medium" and just hack it together for any pair of components you have in the fastest way you can. Despite how ridiculous it sounds... this argument isn't without merit. I've seen a lot of systems that tried to develop "universal medium" and failed. The latest largest such example is Kubernetes itself, if you think about various entities in Kubernetes as being components that need to communicate to each other. Kubernetes developers are slow to acknowledge the failure and are trying to fight it point-wise (eg. not so long ago they axed PSP), but the system keeps getting more complex and unpredictable with every new edition. So, in frustration, one may decry the idea of universal medium, suggesting reducing the scope of the problem... and that's what microservice apologists seem to be suggesting. But, to me, it sounds like giving up on an essential desirable quality of a program. Kind of like if you wanted an automobile, but you couldn't get the engine to work quite right, and, in the end, abandoned the effort and just rode a horse.

crabbone 3y ago

This is not an argument against modularity. The argument is that if you want modularity -- go all the way. Microservices is the argument that says "nah, let's divorce, but keep living in the same house". Here, to make it more concrete: two Unix programs assume no knowledge of each other's existence (ideally), they rely on standard input / output / pipes / signals (i.e. some communication methods that aren't unique to any of the programs, but provided by the third program -- environment). This, in my example would be to go all the way: no need to know that the other program exists. Microservices are as if you had an OS similar to Unix, but any pair of programs could decide on their own kind of pipes / signals / the way loader resolves symbols / function calling convention etc. Now, the argument the proponents make is that it's hard to make a universal "medium" used by all programs run in such an environment, and that if you want to "move fast", then you can skip working on this universal "medium" and just hack it together for any pair of components you have in the fastest way you can. Despite how ridiculous it sounds... this argument isn't without merit. I've seen a lot of systems that tried to develop "universal medium" and failed. The latest largest such example is Kubernetes itself, if you think about various entities in Kubernetes as being components that need to communicate to each other. Kubernetes developers are slow to acknowledge the failure and are trying to fight it point-wise (eg. not so long ago they axed PSP), but the system keeps getting more complex and unpredictable with every new edition. So, in frustration, one may decry the idea of universal medium, suggesting reducing the scope of the problem... and that's what microservice apologists seem to be suggesting. But, to me, it sounds like giving up on an essential desirable quality of a program. Kind of like if you wanted an automobile, but you couldn't get the engine to work quite right, and, in the end, abandoned the effort and just rode a horse.