8 ms·
And even then, I no longer believe that "removes as much friction as possible compared to local functions" is a desirable goal in the first place. Over the cou
by mumblemumble 3y ago
And even then, I no longer believe that "removes as much friction as possible compared to local functions" is a desirable goal in the first place.
Over the course of my short 20-year career, I've encountered far too many applications that accumulated terrible performance or reliability problems that were directly attributable to their authors feeling a bit too comfortable about getting chatty with the slow, unreliable remote procedure calls.
By contrast, the most successful microservices shop I ever worked at was very conscientious about doing nothing to hide the messiness of RPC. (Ease the implementation, yes, but not hide the messiness.) And that seemed to foster a culture of being much more thoughtful about interaction patterns and data flows and how they might contribute to or detract from the overall performance and stability of the system.
- lunarcave 3y agoOne of the author here. I definitely agree that you get markedly lower reliability and performance one you move a local function call to be remote. So, we're definitely not advocating that moving a local function call to be remote is inherently virtuous. However, I've found the abstraction to be useful when someone _has_ already made the decision to refactor their service out to be a separate service.