Source-linked AI summary
Cloud Programming Simplified: A Berkeley View on Serverless Computing
Eric Jonas, Johann Schleier-Smith, Vikram Sreekanti, Chia-Che Tsai, Anurag Khandelwal, Qifan Pu, Vaishaal Shankar, Joao Carreira, Karl Krauth, Neeraja Yadwadkar, Joseph E. Gonzalez, Raluca Ada Popa, Ion Stoica, David A. Patterson
TL;DR
The paper examines how serverless computing can reduce the operational burden and limitations that remain in cloud computing. It synthesizes serverless’s model, evaluates applications that stress current platforms, and identifies challenges and research opportunities. The authors conclude that the issues are solvable and predict serverless computing will grow to dominate cloud computing’s future.
Problem
Cloud users still manage complex virtual resources, while stateful workloads often fail to benefit from efficient multiplexing and serverless platforms remain limited for demanding applications.
Method
The paper defines serverless computing, reviews its history and distinctions, examines five applications using cloud functions, and discusses obstacles and research opportunities.
Results
The five applications exposed similar weaknesses, while databases and other state-heavy applications mapped poorly to FaaS and are expected to remain BaaS.
Takeaways & Limitations
The authors believe serverless challenges will eventually be addressed, enabling serverless computing to become the face of cloud computing.
Takeaways & Limitations
Traditional databases remain difficult to run atop FaaS because serverless lacks built-in persistent storage and conflicts with connection, addressing, and shared-memory assumptions.
Abstract
from arXiv · showhide
Serverless cloud computing handles virtually all the system administration operations needed to make it easier for programmers to use the cloud. It provides an interface that greatly simplifies cloud programming, and represents an evolution that parallels the transition from assembly language to high-level programming languages. This paper gives a quick history of cloud computing, including an accounting of the predictions of the 2009 Berkeley View of Cloud Computing paper, explains the motivation for serverless computing, describes applications that stretch the current limits of serverless, and then lists obstacles and research opportunities required for serverless computing to fulfill its full potential. Just as the 2009 paper identified challenges for the cloud and predicted they would be addressed and that cloud use would accelerate, we predict these issues are solvable and that serverless computing will grow to dominate the future of cloud computing.
1 Introduction to Serverless Computing
Cloud computing realized many anticipated benefits but left users managing complex virtual resources and underutilized stateful workloads. Serverless emerged to offload provisioning and administration through cloud functions and specialized services.
- Motivation: Cloud computing delivered its anticipated benefits, but users still faced complex operations and inefficient multiplexing for many workloads.Virtual resources remained the users’ responsibility, while multiplexing was more effective for batch workloads than stateful services.
- Motivation: Low-level virtual machines became dominant because they let users recreate local computing environments and simplify workload migration.This choice prioritized practical porting needs when cloud programming models were still uncertain.
- Motivation: Managing virtual machines required developers to handle extensive system-administration responsibilities, motivating simpler paths for new cloud applications.The burden included environment setup and operational tasks such as autoscaling and monitoring.
- Motivation: A phone-image workflow could require only dozens of JavaScript lines, while server setup demanded substantially more operational work.The example creates thumbnails and places them on the web after images are sent to the cloud.
- Definition: AWS Lambda, introduced in 2015, popularized cloud functions and helped establish serverless computing as FaaS combined with BaaS.FaaS provides general compute, while BaaS supplies application-specific services such as databases and other backends.
- Outlook: The paper frames serverless research as addressing remaining cloud challenges and predicts that resolving them will make serverless central to cloud computing.The authors explicitly acknowledge uncertainty about which solutions will prevail.
2 Emergence of Serverless Computing
Serverless computing shifts operational responsibility from developers to the provider through event-triggered functions, independently scaled services, and usage-based resource management. Its ecosystem, isolation mechanisms, and abstraction enable broad flexibility, while remaining part of a continuum with serverful platforms.
- Core model: Serverless users write event-triggered cloud functions while the platform handles instance selection, scaling, deployment, fault tolerance, monitoring, logging, and security patches.This contrasts with serverful computing, where users manage more of the underlying resources and operations.
- Core distinctions: Serverless differs from serverful computing through decoupled storage and computation, automatic resource provisioning, and payment based on resources used rather than allocated.Storage and computation are provisioned and priced independently, with computation generally stateless.
- Ecosystem: The serverless layer combines general-purpose FaaS with specialized BaaS offerings and selected big-data services above foundational cloud infrastructure.Examples include functions, object storage, databases, messaging, big-data query, and transformation services.
- Context: Compared with predecessors, modern serverless computing adds better autoscaling, stronger isolation, platform flexibility, and ecosystem support.AWS Lambda’s autoscaling could respond quickly to load increases and scale to zero resources and cost.
- Enablers: Warm and active pools, lifecycle management, and multi-tenant bin packing help provide fast function environments while maintaining isolation and utilization.The paper also discusses containers, unikernels, library operating systems, and language virtual machines as alternative isolation approaches.
- Core distinctions: Serverless and serverful computing form endpoints of a continuum that includes containerized orchestration frameworks such as Kubernetes.Kubernetes represents an intermediate function-based or server-centered platform.
- Architectural implications: Serverless raises the deployment abstraction from machine code toward high-level languages, potentially easing adoption of alternative instruction sets and hardware-specific optimizations.The paper identifies ARM and RISC-V as examples of possible alternatives to x86.
3 Limitations of Today’s Serverless Computing Platforms
The paper examines five applications to expose common limitations that prevent current serverless platforms from matching serverful-cloud performance. These limitations concern storage, coordination, communication efficiency, and predictable hardware performance.
- The five applications were selected to uncover common weaknesses that may prevent serverless versions of other interesting applications.The examples are not intended to represent all information technology outside the current serverless ecosystem.
- 3.1 Inadequate storage for fine-grained operations: Serverless platforms struggle to support stateful applications because existing storage services impose high access latency and cost for fine-grained operations.Small-object reads or writes take at least 10 milliseconds, while sustaining 100K IOPS on S3 costs $30/min.
- 3.2 Lack of fine-grained coordination: Fine-grained coordination is difficult because tasks need notification mechanisms to know when remote inputs become available.Applications currently use VM-based notification systems or their own mechanisms, such as a long-running rendezvous server.
- 3.3 Poor performance for standard communication patterns: Cloud functions increase communication costs because they cannot exploit the local sharing and aggregation available among tasks on the same VM.With K functions per VM, cloud functions send K times more messages for broadcast and aggregation and K^2 more for shuffle; K typically ranges from 10 to 100, producing two to four orders of magnitude more data in some cases.
- 3.4 Predictable Performance: Predictable performance is hindered by variability in the hardware resources selected by the cloud provider.Experiments sometimes received CPUs from different hardware generations, exposing a tradeoff between resource utilization and predictability.
4 What Serverless Computing Should Become
Serverless computing must expand beyond current cloud-function abstractions to support richer resources, data movement, storage, communication, security, and hardware diversity. The paper identifies provider- and application-level mechanisms to improve performance while preserving serverless simplicity, alongside trade-offs involving utilization and isolation.
- Abstraction challenges: Cloud providers should infer resource requirements from code, profiling, or recompilation rather than requiring developers to specify every resource.Automatic memory provisioning is appealing but must interact with garbage collection in high-level runtimes.
- Abstraction challenges: Exposing computation graphs could improve function placement by reducing communication, especially when platforms currently lack data-dependency information.Existing distributed frameworks and orchestration systems already produce such graphs.
- System challenges: Serverless platforms need high-performance ephemeral and durable storage with lower latency, stronger IOPS, and appropriate retention semantics.Ephemeral storage supports application-lifetime state and caching, while durable storage targets long-term mutable data.
- System challenges: Shared in-memory ephemeral storage can improve memory efficiency through statistical multiplexing, allowing unused memory to serve other applications.Internal fragmentation can still occur when functions do not use their entire local memory.
- Networking challenges: Cloud functions need faster coordination, distributed communication primitives, and placement strategies that reduce broadcast, aggregation, and shuffle overhead.Packing K functions on one VM can produce K times more messages, or K^2 more for shuffle, than an instance-based version.
- Security and architecture challenges: Security and architecture challenges include adversary-aware scheduling, fine-grained security contexts, protection against communication-pattern leaks, and support for heterogeneous processors.Physical isolation can conflict with startup time, utilization, or communication optimization, while x86 SIMD heterogeneity already affects performance.
5 Fallacies and Pitfalls
The paper challenges common assumptions about serverless computing, arguing that apparent disadvantages often reflect incomplete comparisons or limited elasticity, while identifying genuine concerns around cost predictability and portability.
- Serverless cost comparisons must include administration, availability, monitoring, logging, scaling, and fine-grained usage billing rather than instance price alone.Cloud providers report 4x-10x cost savings for some migrations, and serverless incurs no charge when no function events occur.
- Pure pay-as-you-go pricing can make annual budgeting difficult because future serverless costs are unpredictable.The paper suggests bucket-based pricing or historical usage as possible ways to improve predictability.
- High-level languages do not ensure portability because function semantics, packaging, and proprietary BaaS APIs differ across providers.The paper points to standard APIs and projects such as Knative as steps toward portability.
- Vendor lock-in may be stronger for serverless than serverful computing because difficult application porting increases dependence on providers.Cross-cloud frameworks may mitigate this lock-in.
- Serverless can support low-latency applications when functions are pre-warmed, although startup latency remains a design consideration.Serverful instances respond quickly because they are always on; regular invocation can maintain enough running functions for incoming requests.
- Few services match serverless elasticity because many require explicit provisioning, scale slowly, operate over limited ranges, or cannot scale to zero.The paper calls for a quantitative, broadly accepted definition or metric for elasticity.
6 Summary and Predictions
The paper presents serverless computing as a maturation of cloud programming that removes manual resource management and could broaden the range of suitable applications. It predicts continued growth alongside advances in storage, hardware heterogeneity, security, and cost-performance.
- 6 Summary and Predictions: Serverless simplifies cloud use by removing manual resource management and optimization, analogous to the transition from assembly language to high-level languages.The paper describes serverless as comprising Function as a Service and Backend as a Service offerings.
- 6 Summary and Predictions: The authors predict that serverless use will skyrocket, while hybrid on-premises cloud applications will dwindle except where regulation or data governance requires them.
- 6 Summary and Predictions: New ephemeral and durable BaaS storage services could expand serverless to applications requiring local-block-storage-like performance or long-term storage.The paper also anticipates low-latency signaling and support for popular communication primitives.
- 6 Summary and Predictions: Future serverless systems must improve security and accommodate cost-performance advances from special-purpose processors.High-level cloud-function programming may make it easier to exploit changing hardware, while randomized placement may address side-channel concerns.
- 6 Summary and Predictions: The paper notes that the earlier Berkeley cloud predictions were realized and that cloud computing is growing 50% annually and proving highly profitable for providers.
- 6 Summary and Predictions: The paper concludes by predicting that serverless computing will become simpler to program securely than serverful computing and will support more heterogeneous hardware.
8 Appendix. More Depth on Five Applications that Stretch Today’s Serverless Computing
Five applications show both the promise of serverless computing and the systems challenges that remain when workloads require fine-grained state, communication, coordination, or persistence. Results range from competitive performance to substantial limitations in cost, scale, and supported communication patterns.
- ExCamera: ExCamera uses cloud functions to scale video encoding quickly, but fine-grained state and NAT restrictions make direct communication and external-storage exchange challenging.Cloud functions start in seconds and require no management, yet S3 transfers add overhead for tasks lasting only a few seconds.
- MapReduce: 1.11 billion transfers arise when shuffling 100 TB with 33,000 map and reduce functions through external storage.The resulting S3 IOPS costs alone can reach $12,000, and the shuffle can take tens of hours.
- MapReduce: 50 shuffle stages reduce the high-performance storage requirement for a 100 TB shuffle to 2 TB, bringing serverless closer to VM-based frameworks.The staged design addresses the cost of using high-performance storage for all shuffled data.
- Numpywren: Linear algebra: Numpywren reaches 1.3x ScaLAPACK completion time across the reported algorithms, with CPU consumption ranging from 0.44x to 1.3x depending on the algorithm.Its performance is competitive because computation can dominate communication for large linear-algebra problems.
- Numpywren: Linear algebra: Numpywren competes with dedicated implementations mainly beyond 256K ×256K dense matrix operations, while high-latency storage hurts smaller instances and broadcast remains inefficient.These limitations constrain serverless linear algebra beyond large problem sizes and favorable communication patterns.
- Cirrus: Machine learning training: Cirrus converges 3x faster than Tensorflow and 5x faster than Bosen on sparse logistic regression, but its cost may be up to 7x higher.On collaborative filtering, Cirrus reaches a lower RMSE of 0.83 versus 0.85 in less time.
- Serverless databases: Serverless databases face remote-storage latency and connection-oriented protocol conflicts, although SQLite was successfully run inside serverless computing.Stateful workloads remain particularly challenging because serverless platforms are fundamentally stateless and lack built-in persistent storage.