It got upvoted because microservices are currently sliding into the trough of disillusionment. It's trendy right now to hate on them, and the author is fully on the mindless hate bandwagon right along with a lot of HN readers.
In a few years we'll hopefully be out onto the slope of enlightenment, with microservices applied where they're useful and not applied where they're not. If we don't get there, then we'll just run the whole hype cycle over again with yet another rebrand of the same concept.
I dunno man, I worked at FB well before the micro services hype and saw a bunch of problems with them, particularly in debugging.
And in general, putting a network boundary between function calls is gonna add a whole bunch of complexity.
That being said, splitting services so that teams could deploy independently definitely also had a lot of benefits at FB, but I could never understand why so many much smaller companies took the micro services approach.
I'm not into the microservices hype either, I'm just opposed to the reactionary claims in places like TFA that you should basically never split out code into a new service. Both extremes are wrong.
My opinion is that the default should be to keep things in one service and only split them out if there's a very good technical or organizational case to be made.
Well, it's not easy to investigate how poverty affects your whole life history xD
It would take an investigator their entire life as well, assuming they started super young. And who wants to pay for such investigation?
I don't disagree with you. I don't have a solution either. I also know that the paper linked above put on HN will not make much of a difference to peoples perspectives on the matter since it doesn't have a ton of merit to it.
So the question becomes -- whats the point of posting it here other than to inflame commentary?