Source-linked AI summary
Serverless Computing: One Step Forward, Two Steps Back
Joseph M. Hellerstein, Jose Faleiro, Joseph E. Gonzalez, Johann Schleier-Smith, Vikram Sreekanti, Alexey Tumanov, Chenggang Wu
TL;DR
Current serverless offerings have architectural and platform gaps that limit their fit for data-centric, distributed, and hardware-accelerated cloud innovation. The paper identifies these shortfalls through architectural analysis and case studies, then outlines challenges for preserving autoscaling while improving performance.
Problem
Creative developers lack programming frameworks that let them exploit cloud resources radically, while FaaS separates short-lived functions from data and limits support for distributed and custom-hardware computing.
Method
The paper analyzes FaaS architectural shortcomings and evaluates them through distributed-systems and machine-learning case studies using Lambda, DynamoDB, SQS, and EC2.
Results
Current FaaS offerings are a poor fit for cloud and data-systems innovation; a Lambda leader-election algorithm was 21× slower and 7.3× more expensive than EC2.
Takeaways & Limitations
The paper argues that current FaaS constraints can be overcome while maintaining autoscaling and unlocking the performance potential of data and distributed computing.
Takeaways & Limitations
Leader-election cost estimates assume each leader is elected immediately after joining; practical costs might be much higher.
Abstract
from arXiv · showhide
Serverless computing offers the potential to program the cloud in an autoscaling, pay-as-you go manner. In this paper we address critical gaps in first-generation serverless computing, which place its autoscaling potential at odds with dominant trends in modern computing: notably data-centric and distributed computing, but also open source and custom hardware. Put together, these gaps make current serverless offerings a bad fit for cloud innovation and particularly bad for data systems innovation. In addition to pinpointing some of the main shortfalls of current serverless architectures, we raise a set of challenges we believe must be met to unlock the radical potential that the cloud---with its exabytes of storage and millions of cores---should offer to innovative developers.
1 INTRODUCTION
Serverless computing promises autoscaling, pay-as-you-go cloud programming, but current offerings remain constrained by proprietary services and weak support for data-centric innovation. The paper evaluates existing vendor offerings and identifies fundamental architectural shortcomings.
- 1 INTRODUCTION: Current cloud usage remains concentrated on outsourcing standard enterprise data services, leaving creative developers without frameworks that exploit the cloud’s full potential.The paper frames programming frameworks as necessary for changing this pattern.
- 1 INTRODUCTION: Serverless aims to let developers upload code that executes automatically at any scale, without provisioning servers, with billing tied to invoked resources.Functions-as-a-Service infrastructure responds to events, allocates runtimes, executes functions, and persists results.
- 1 INTRODUCTION: The paper assesses vendor offerings as they exist today rather than debating the broad meaning of “serverless.”AWS Lambda receives primary attention because AWS was the first and remains the largest public cloud provider.
- 1 INTRODUCTION: FaaS is not sufficient alone: practical applications also require persistent and temporary storage, triggering, scaling, and vendor-provided supporting services.AWS examples include S3, DynamoDB, SQS, and SNS.
- 1 INTRODUCTION: Autoscaling advances cloud programming by letting workloads drive resource allocation and deallocation, but current FaaS offerings neglect efficient data processing and hinder distributed systems.The paper presents these as two major steps backward relative to serverless computing’s autoscaling potential.
2 SERVERLESS IS MORE? THE EASY CASES
Current FaaS works well for simple independent tasks and integrations with proprietary cloud services, but stateful workflows face high latency and limited scope. These constraints narrow the practical space for third-party serverless applications.
- 2 SERVERLESS IS MORE? THE EASY CASES: FaaS is attractive for independent, embarrassingly parallel workloads whose function invocations never need to communicate.Examples include image resizing, image recognition, and integer-programming tasks.
- 2 SERVERLESS IS MORE? THE EASY CASES: Dataprep illustrates a broader architecture in which a client generates Dataflow programs, autoscaling services relay requests, and Dataflow executes them at scale.The middle tier is not implemented with FaaS, although similar architectures could use it.
- 2 SERVERLESS IS MORE? THE EASY CASES: Current FaaS solutions suit simple independent tasks or jobs delegated to proprietary cloud services.The paper characterizes these as the attractive use cases available today.
- 2 SERVERLESS IS MORE? THE EASY CASES: Stateful tasks can have surprisingly high latency, with a sign-up workflow taking 10 minutes to turn around.The paper says these realities discourage third-party programs beyond vendors’ proprietary offerings.
3 WHY SERVERLESS TODAY IS TOO LESS
Current FaaS realizes autoscaling execution but restricts sophisticated serverless applications through data-shipping, weak distributed communication, limited hardware access, and short-lived execution. The resulting systems are attractive mainly for independent parallel tasks or proprietary services, while case studies show substantial latency and cost penalties.
- Data and distributed computing: 538Mbps average bandwidth per Lambda falls to 28.7Mbps with 20 functions, making shared network capacity far slower than a modern SSD.The per-function bandwidth shrinks as compute scales because multiple functions share limited bandwidth on packed virtual machines.
- Data and distributed computing: Direct communication is unavailable between Lambda functions, so distributed computation must use storage intermediaries that are slower and more expensive than point-to-point networking.This leaves large-scale coordination largely limited to uncoordinated parallelism.
- Data and distributed computing: FaaS functions run separately from data, forcing applications to ship state through storage and limiting caching across short-lived, non-addressable invocations.Weak consistency across replicas further means agreement among ephemeral functions must be added separately.
- Hardware and software innovation: FaaS restricts hardware-accelerated and open-source innovation by offering uniform virtual machines, no custom processors, and at most 3GB of RAM.The paper links these constraints to limited support for large in-memory data structures and scalable open-source data systems.
- Case studies: Training the neural network on Lambda took 465 minutes and cost $0.29, while the paper reports Lambda was 21× slower and 7.3× more expensive than EC2.Each iteration spent 2.49 seconds fetching a 100MB batch from S3 and 0.59 seconds computing.
- Case studies: A Lambda batching application averaged 447ms per batch after optimization, compared with 13ms using EC2 with SQS and 2.8ms using direct ZeroMQ messaging.At 1 million messages per second, SQS request costs alone would reach $1,584 per hour, excluding Lambda execution.
4 STEPPING FORWARD TO THE FUTURE
The paper outlines challenges for a truly programmable cloud that can manage compute and data resources dynamically while supporting fluid placement, distributed programming, security, and broader research innovation.
- Cloud programming frameworks should dynamically allocate compute and data resources to meet user-specified performance goals while preserving autoscaling and cost efficiency.
- Fluid Code and Data Placement: Fluid placement should colocate code and data for performance while logically separating them so data can be replicated or repartitioned as workloads change.High-level data-centric DSLs can expose dataflow and expand the infrastructure’s optimization space.
- Disorderly programming: Distributed cloud programs need virtual, dynamically remapped communication endpoints and programming models built from small, movable units of data and computation.Candidate abstractions include actors, tuplespaces, publish/subscribe, DHTs, functional reactive programming, and declarative DSLs.
- Security concerns: Cloud security research should combine provider-managed protection and customer policy specifications with hardware enclaves, auditing, post-hoc analysis, and finer-grained end-user controls.Hardware enclaves can protect running code, and initial work has explored data processing in those settings.
- These challenges appear surmountable: third parties can explore systems issues using cloud features, while program analysis, scheduling, and language design remain open research opportunities.The authors are optimistic that research can help programmers access the cloud’s full potential.