CS PAPERS DEEP-READ · PAPER 63
Jonas, Schleier-Smith et al. · UC Berkeley · 2019 (read against Hellerstein et al. · CIDR 2019)
When you open a website, some machine has to be sitting there, switched on, waiting for you. Serverless tries to make that somebody else's problem: you hand over a piece of code, the cloud runs it only when a request arrives, tears it down afterwards, and charges you nothing while nobody is visiting. "Serverless" does not mean there are no servers — it means the servers are no longer yours to manage. In 2019 a group at Berkeley wrote this verdict on the idea: one half says "this is the future of the cloud," the other half lists, honestly, what it still cannot do.
The old way is like renting a warehouse by the month: you have to guess in advance how much floor space your busiest day will need — too small and you are crushed, too large and you pay for the empty space anyway, which is most of the year. Serverless is like hailing a van per delivery: one job, one van; no jobs, no vans on the road, and no parking to pay for.
In the old world an engineer first had to answer a pile of questions that have nothing to do with their actual product: how many machines? which type? how much memory? shut them down overnight? what happens when we get famous at 3am? Get any of them wrong and you either burn money or fall over. Serverless takes the whole pile away: you say "this code should run," and the rest is the cloud's problem. The paper's own analogy is the move from assembly language to high-level languages — the programmer stops placing every register by hand.
The trick is to chop "running" into a swarm of very short-lived temps: each request hires one, and it vanishes the moment the job is done. Precisely because a temp can be created and killed at any instant, it cannot keep anything on it (the next one is brand new and remembers nothing) and cannot phone the others (you have no idea which machine one is on, or whether it still exists). So everything that must be kept or handed over has to be checked into a shared locker room — a cloud storage service — for whoever needs it to fetch.
That single fact is both why it is cheap and where all its trouble comes from: when several temps need to pass a lot of data back and forth, what used to be a sentence said face to face becomes write it into a locker, then walk over and take it out again — and with enough temps, a queue forms at the lockers. The body of this paper is exactly that list of "things you cannot do here today": no locker that is both fast and cheap, no way for temps to signal one another, and no dependable, predictable speed.
A rebuttal published the same year put it more bluntly: this amounts to shipping the data to the code, whereas forty years of distributed systems say the opposite — ship the code to the data, because data is heavy and code is light. So anything data-hungry, anything that shuffles intermediate results around, is slow and expensive here. Together the two papers became the field's shared vocabulary, and the potholes on the list have been getting filled in one by one. One honest sentence: six years on, the prediction that serverless would replace ordinary servers as the default shape of the cloud has not come true — it turned out to be a very good tool in the box rather than the only one.
Serverless = you hand over code, the cloud starts and stops the machines and charges nothing while idle; the price is that functions are short-lived and cannot address each other, so every shared thing has to detour through storage. This paper made that trade explicit — and turned "what it still lacks" into a checklist everyone has used since.
Want the formal definition, the four obstacles and the rebuttal in full? → switch to the deep read
This is not a paper that proposes a system; it is a verdict plus a defect list. It first gives the marketing-worn term "serverless computing" a usable definition — cloud functions (FaaS) + backend services (BaaS), identified by three tests: compute and storage are decoupled, you submit code instead of requesting resources, and you are billed for what you use rather than what you allocate. It then probes that model with five real application classes and shows it is structurally stuck in four places: ephemeral shared storage, fine-grained coordination, communication patterns, and predictable performance. Finally it predicts this is where cloud computing is heading. The same year, Hellerstein et al. took the same facts and reached the opposite conclusion.
Eric Jonas, Johann Schleier-Smith, Vikram Sreekanti and a dozen more from UC Berkeley's RISELab, including Joseph Gonzalez, Raluca Ada Popa, Ion Stoica and David Patterson; released in February 2019 as a Berkeley technical report (UCB/EECS-2019-3). It deliberately continues the lineage of the same lab's 2009 Above the Clouds: A Berkeley View of Cloud Computing — that one fixed the meaning of "cloud computing," this one wants to fix the meaning of "serverless." The opposite half arrived the same year at CIDR: Hellerstein et al., Serverless Computing: One Step Forward, Two Steps Back, with an overlapping author list (Gonzalez, Schleier-Smith and Sreekanti appear on both).
Until then the standard way to use a cloud was what the paper calls serverful: you rent virtual machines, choose their type, count and memory yourself, and install, patch, autoscale and fault-tolerate them yourself. Three kinds of pain follow. First, you are forced to answer questions unrelated to your product — how many cores does this service need, how much bigger is the peak than the average? The answers need both experience and clairvoyance, and the cost of guessing wrong is asymmetric: guess high and you burn money daily, guess low and you go down, so everyone guesses high. Second, you pay for what you allocate, not what you use: the meter runs from the moment a machine boots, even through a night with zero requests. Third, elasticity is your job, and virtual machines boot far too slowly to catch a surge.
Meanwhile AWS Lambda had been making "just hand over a function, pay per call" work since 2014. But the word "serverless" had been beaten out of shape by marketing: every managed service claimed it, nobody could say where its boundary lay, and therefore nobody could say what it was actually missing. Hence the two jobs of this paper: define it, then measure its edges.
The paper's equation is serverless = FaaS + BaaS: cloud functions run your code, backend services (object storage, managed databases, queues) hold the data and everything else. What actually separates it from serverful is three tests:
The paper's own analogy is assembly language to high-level languages: high-level languages automated register allocation, serverless automates machine resource allocation. There is a second, often-missed elegance here: billing by usage also fixes the provider's incentives — idle capacity is no longer paid for by you, so filling the machines becomes, for the first time, the seller's own problem.
To be startable, killable and billable by the millisecond, a function has to live under hard constraints. On Lambda as of the paper: 15 minutes maximum per execution, a memory ceiling of about 3 GB, and no inbound network connections — you cannot send a message to a running function, because you neither know which machine it is on nor can guarantee it will still exist a second from now.
Together those force one consequence: any sharing between functions has to detour through external storage. In the serverful world two processes exchanging data open a TCP connection, or simply share memory. In the serverless world the same exchange becomes "A writes to object storage → B reads it back": one hop becomes two, and an object-storage round trip costs tens of milliseconds — four orders of magnitude slower than the microseconds the same handoff would take in memory.
Multiply that constraint by scale and it bares its teeth. In a shuffle, N upstream functions each have to hand data to N downstream functions: serverful, that is direct transfer between N machines; serverless, it becomes N×N small objects written to storage and read back. The finer you slice the work — and slicing finely is the entire selling point of serverless — the more brutally this all-to-all cost grows. That is not one cloud vendor implementing things badly; it follows directly from "functions must be stateless and unaddressable," which is why the paper calls the blockage structural.
The authors take five real application classes — real-time video encoding, MapReduce-style batch processing, large-scale linear algebra, machine learning training and serving, and databases — move each onto serverless, and distill the walls they hit into four:
Of the four, the first is the worst, and the other three largely descend from it: intermediate state has an unusual profile — it lives for seconds, wants very low latency, and can be large — while the available options are all-or-nothing. Object storage is cheap but slow; in-memory key-value stores are fast but billed for standing capacity, expensive, and yours to operate. Neither honors the "pay per use, zero when idle" spirit of serverless. The fourth is the most off-putting in practice: accelerators like GPUs and TPUs were simply not offered by FaaS platforms then, which locks deep learning training out entirely.
Two further notes from the paper: slicing multi-tenancy this finely puts more neighbours on your physical machine, raising side-channel risk; and because you can declare "I want this much memory" but not "this function is related to that data," the platform has no information with which to schedule computation near its data — which is precisely where the rebuttal lands its hardest punch.
At CIDR the same year, Hellerstein et al. (three of them co-authors of this paper) read the same facts the other way. Their central claim is a single sentence: FaaS is a data-shipping architecture — it ships the data to the code. The first principle accumulated over forty years of distributed data systems is the reverse: ship the code to the data, because data is heavy, code is light, and moving data is the expensive operation. FaaS inverts that by force, hence "one step forward (elasticity and no operations), two steps back (data locality and the ability to compute in a distributed way)."
Their four limitations overlap heavily with the Berkeley checklist but are stated more harshly: limited lifetimes, I/O bottlenecks (a function gets a fraction of a normal server's network bandwidth, and everything has to cross that network), communication only through slow storage, and no specialized hardware. They ported four workloads — model training, low-latency prediction serving, distributed transactions and streaming dataflow — onto Lambda and measured them: typically an order of magnitude slower and an order of magnitude more expensive. Their prescription is not retreat but making state a first-class citizen of serverless (their group's later Anna and Cloudburst follow exactly that line). The two papers agree almost entirely on the facts; they disagree on whether these limits are early defects or original sin — and Berkeley bets on the former.
It has to be said plainly: this is a position paper. It offers no new system and no new benchmark. Its "results" are two things.
First, five case studies. The authors take systems already built in their own group and drive them into the wall; each crash points at one line of the checklist. Real-time video encoding is blocked by the need for frequent fine-grained communication between functions; MapReduce-style batch processing and sorting are blocked by shuffles that can only cross object storage; large-scale linear algebra is blocked by the absence of fast shared memory; ML training and serving are blocked by missing accelerators and low-latency shared state; database workloads are blocked by the inability to hold long-lived connections. As for the platform limits — 15 minutes, roughly 3 GB, 100 ms billing granularity, no inbound connections — those are all in the public docs; the paper's contribution is arguing that they are not arbitrary, but the technical price of a business model built on "billed by usage, killable at will."
Second, the cost argument. Per unit of compute, a cloud function is more expensive than a comparable virtual machine; but because it costs nothing while idle, the total bill for bursty, low-duty-cycle workloads comes out lower. So the economics of serverless are not "cheaper" but "the cost curve changes shape, from a rectangle into something that follows demand" — the steadier your load, the worse the deal. A separate section on "fallacies and pitfalls" answers common objections (the verdict that cloud functions are inherently unfit for low latency, for instance, strikes the authors as premature), and the paper closes on predictions: serverless will come to dominate cloud computing, prices will fall, heterogeneous hardware will be brought in.
It gave academic calibration to a word marketing had worn out. "Serverless = FaaS + BaaS, identified by decoupling, not requesting resources, and usage-based billing" became the common starting point for papers, textbooks and vendor documentation alike, and the obstacle list became the sub-field's research agenda — for several years you could read new papers using it as a table of contents. The ephemeral shared storage line produced Pocket (elastic ephemeral storage built for serverless) and Locus (mixing a little fast storage with object storage to make shuffles work). The cold start and isolation line got its finest answer in Firecracker (2020), the lightweight microVM built for Lambda that wants virtual-machine isolation at container startup speed. On the platform quota side, Lambda raised its memory ceiling to 10 GB around 2020, refined billing granularity from 100 ms to 1 ms, and added mountable shared file systems. And stateful serverless became the rebuttal camp's main line (Anna, Cloudburst).
The broader legacy is the vocabulary itself: "serverless database" and "serverless warehouse" are intelligible phrases today precisely because this paper moved the test away from "is there a function?" to "do you still have to request and keep resources alive, and does the bill fall to zero when usage does?"
① In one line: give "serverless" a usable definition, then probe its edges with five application classes and write the result up as a four-item obstacle list.
② The definition: serverless = FaaS + BaaS, with three tests — compute and storage decoupled, code submitted instead of resources requested, billed for usage rather than allocation (zero cost when idle).
③ The old pain: you were forced to guess sizes and peaks, with asymmetric costs for guessing wrong; the meter ran from boot; elasticity was your own job.
④ Mechanism and price: to be startable, killable and billable by the millisecond, functions must be short-lived, stateless and unaddressable; so there is no direct line between two of them and all sharing detours through external storage, turning a microsecond in-memory handoff into tens of milliseconds. A shuffle degrades from "N machines connected directly" into "N×N small objects written to storage" — and the finer the slicing (serverless's whole selling point), the worse it gets.
⑤ The four obstacles: no low-latency ephemeral shared storage (the worst one), no fine-grained coordination, expensive broadcast/aggregation/shuffle, unpredictable performance (cold starts + hardware lottery + no accelerators).
⑥ The truth about the economics: per unit of compute it is more expensive; it wins by charging nothing while idle, so it pays off only for bursty, low-duty-cycle workloads — the steadier the load, the worse the deal.
⑦ The rebuttal (Hellerstein et al., CIDR 2019): FaaS is a data-shipping architecture that inverts forty years of "ship the code to the data," and for data-intensive work it comes out roughly an order of magnitude slower and more expensive.
⑧ Legacy and limits: the checklist became the sub-field's research agenda (Pocket, Locus, Firecracker and Cloudburst all follow it); but this is a position paper rather than an experimental one, its "serverless will replace serverful" prediction has yet to come true, and the architectural objection from the other side was never truly answered.