Why do none of these articles about the appropriate way to organize RPCs in your service talk about technological reasons for doing an RPC? If I have a computation that has a very CPU-intensive part and a very memory intensive part, maybe I want more than one SKU/instance type involved. That’s a technical reason to do an RPC. I have a computation that doesn’t fit on any of my SKUs, gonna need some RPCs. If I have unsafe/unmanaged code for the performance sensitive part but managed code for the watchdog part, that could go either way, maybe I do IPC or maybe I use an FFI.
RPC boundaries have costs and benefits. They are a tool, not an ideal to aspire to.
It's in the early days but this is exactly what Architecture the Hard Parts[0] is working on: finding for each system the right balance between pulling things apart and putting them back together again.
RPC boundaries have costs and benefits. They are a tool, not an ideal to aspire to.