Re:Developers Are the Problem, Not Monoliths
by mpweiher on Monday February 11, 2019 @05:58PM
(#19139339)
> RPCs failing is not really a problem.
Hmm...
1. Software applications are written with little error-handling on networking errors. During a network outage, such applications may stall or infinitely wait for an answer packet, permanently consuming memory or other resources. When the failed network becomes available, those applications may also fail to retry any stalled operations or require a (manual) restart.
Infinite retries aren't "not really a problem". If the server isn't there or can't be reached, it isn't there or can't be reached. This is not a problem software/infrastructure can paper over transparently. You can try your best to mitigate, but that's hard, and often makes things worse.
I remember a colleague trying out CouchDB. His takeaway was that all error-recovery attempts by distributed CouchDB servers made things worse. So you could use it as a semi-decent single-instance DB, but mercy on your soul should you be so brazen as to attempt to use the distribution features.
> heavy investment in microservice tooling.
And what percentage of microservices is that?
> costs in terms of infrastructure and latency
>> Or if they don't fail outright, have unpredictable latencies
Hmm...
1. Software applications are written with little error-handling on networking errors. During a network outage, such applications may stall or infinitely wait for an answer packet, permanently consuming memory or other resources. When the failed network becomes available, those applications may also fail to retry any stalled operations or require a (manual) restart.
https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu...
Infinite retries aren't "not really a problem". If the server isn't there or can't be reached, it isn't there or can't be reached. This is not a problem software/infrastructure can paper over transparently. You can try your best to mitigate, but that's hard, and often makes things worse.
I remember a colleague trying out CouchDB. His takeaway was that all error-recovery attempts by distributed CouchDB servers made things worse. So you could use it as a semi-decent single-instance DB, but mercy on your soul should you be so brazen as to attempt to use the distribution features.
> heavy investment in microservice tooling.
And what percentage of microservices is that?
> costs in terms of infrastructure and latency
>> Or if they don't fail outright, have unpredictable latencies
Hmm...