The bill, and serverless execution

What does a distributed execution model really charge, and what changes when every operator is a function?

The bill has three items

1. A granularity mismatch. A message costs 100 ns at best inside one process, and 10–100 µs across machines, against about 1 ns for a function call. Any interaction that was going to be fine-grained is now 2 to 5 orders of magnitude more expensive. So the actor model is a poor query execution model and a good substrate model: it loses badly if the message is a tuple, and wins if the message is a task.
2. No barrier means no consistent snapshot. Getting one needs an explicit distributed-snapshot protocol (a way to record a consistent global state while everything keeps running). That is a debt incurred here and paid in the topic of distributed coordination.
3. Mailboxes are unbounded by default, so the canonical actor failure is memory exhaustion in a mailbox. The producer owns the decision to send, and the consumer cannot refuse, so the system must add explicit backpressure or die. This is the third independent confirmation, in this article, of the principle that control flow is flow control. Erlang, Akka and Ray all grew the same mechanism for the same reason.

Where it genuinely wins: long-lived, stateful, irregular, per-key work with low fan-in: session and connection state, per-entity simulation, model serving. In data engineering it appears almost only beneath a dataflow API, not as one. The honest framing is that it is a distribution model that some data systems use to implement their runtime. It is not a peer of the iterator model.

---

Serverless / function-per-operator execution

In serverless execution, every worker is a short-lived function that the platform starts for you. The platform imposes four constraints, and all of them are properties of the platform, not of computation:

1. No worker-to-worker networking (no inbound connections, short-lived addresses).
2. A wall-clock execution cap (a function may only run for some minutes).
3. No state across invocations.
4. Cold-start latency (the delay of starting a function that is not already warm).

Each one forces something.

No direct networking forces all exchange through external storage. This is where the key division of Three idlenesses does its work. Bytes per connection = total shuffle bytes ÷ (M × R).

The request arithmetic is decisive. At roughly $5 per million write requests (per-request pricing), the request cost per gigabyte is

• At 100 KB objects (10⁻⁴ GB): $5 ÷ (10⁶ × 10⁻⁴) = $0.05 per GB.
• At 10 KB objects (10⁻⁵ GB): $5 ÷ (10⁶ × 10⁻⁵) = $0.50 per GB.

Compare that with effectively nothing for a byte moved over a network socket. Request cost scales as M × R, while byte cost scales with the data. So past some width, requests dominate the whole cost of the query. That single inequality is why every serious serverless-analytics design adds either a tree-structured exchange (to reduce M × R) or an ephemeral fast intermediate store. It also predicts that pure function-per-operator (one function per operator instance, talking pairwise) stays rare, which it has. What actually ships is function-per-task, with a full pipeline inside each function.

The cap and the lack of state force each task to be self-contained and idempotent (safe to repeat). That is fine. Cold start forces either provisioned warmth (paying for idleness you were trying to avoid) or acceptance of a latency floor.

What serverless buys. About 1,000 workers in about a second, compared with minutes for a cluster. That is not a performance property. It is an elasticity property, and the trade is "costs are moved" in the money dimension. Per unit of compute, function pricing runs several times VM pricing: roughly $0.06 per GB-hour against about $0.01 for an on-demand virtual machine, so 3–8× depending on shape. Serverless is therefore a bet that your utilization is low enough that 5× the unit price on the seconds you use beats 1× the price on the hours you do not. For bursty, short, narrow-shuffle work that bet wins. For a steadily loaded warehouse it loses. State the type of claim clearly: this is economic contingency, not a permanent constraint. The price ratio is a pricing decision and has moved before.