The need for asynchronous FaaS call chains in serverless systems
Ben Kehoe

I think this whole argument builds on the idea that the clouds would forever bill their customers by the total execution time. It would be a non-issue for cloud operators to turn their billing to be based on CPU time (can be measured in kernel level easily) instead of total function execution time. Of course, the I/O and memory reservation could measured accordingly.

It is just that we as their customers need to demand that instead of being happy of paying for nothing.

For the past 40 years and probably onwards the idea about subdividing some chunks of execution (call them modules, classes or functions) has been that they should be serving a single purpose. I do not see how asynchronicity would change that, it is a simple technical detail.

This does not mean that there weren’t need for RPC between the functions -actually billing by CPU time supports that thinking — execute a function/service, have it call another service over RPC (and turn off billing while waiting) etc.

I am just saying it should not be done on micro level — there is no need to terminate the function while it is waiting for a reply. That just unnecessarily complicates things — storing the intermediary state in-between etc. You would not want to do that in micro level while it might make sense macro level.