Serverless Computing: One Step Forward, Two Steps Back

1 INTRODUCTION

• Despite the cloud’s vast data and compute capacity, it is largely used for standard enterprise services, and developers lack frameworks to exploit its power.The paper notes that many cloud services are easier-to-administer, multitenant versions of legacy data services.Source: §1 · p. 1

1.1 “Serverless” goes FaaS

• FaaS lets developers register functions triggered by events; the provider allocates a runtime, executes each function, persists results, and bills for invocation compute.Because executions are isolated and ephemeral, applications also need persistent and temporary storage, plus mechanisms to trigger and scale execution.Source: §1.1 · p. 1

1.2 Forward, but also Backward

• FaaS takes a step forward with autoscaling, but current offerings neglect efficient data processing and hinder distributed systems development.The paper frames these shortcomings against the centrality of data-driven, distributed computing to modern innovation.Source: §1.2 · p. 2

• Patterns that combine FaaS with non-autoscaling services are outside the discussion’s scope and may be anti-patterns because those services do not autoscale.Source: §2 · p. 2
• Independent Lambda invocations scale on demand when tasks need no communication and little computation, while orchestration functions delegate data-heavy work to autoscaling services such as Athena.The section also describes orchestration of analytics queries and event-stream preprocessing through Athena and S3.Source: §2 · p. 2
• Composed, stateful event-driven functions pass data through queues or stores; Autodesk’s account-creation path averaged ten-minute end-to-end sign-ups, partly attributed to Lambda task-handling and state-management overhead.Source: §2 · p. 2
• Current FaaS suits independent tasks or work delegated to proprietary autoscaling services, but stateful workflows can incur surprisingly high latency and constrain third-party applications.The paper says these limitations discourage new third-party programs beyond vendors’ proprietary offerings.Source: §2 · pp. 2–3

3 WHY SERVERLESS TODAY IS TOO LESS

• FaaS limits stateful and distributed workloads: one Lambda averaged 538Mbps network bandwidth, falling to 28.7Mbps with 20 functions (2.5 orders of magnitude slower than a single SSD), while state cannot be ensured across invocations.Source: §3 · p. 3
• Because functions are isolated from data and communicate through storage, current FaaS ships data to code and largely confines cloud-scale work to uncoordinated parallelism.The authors argue this architecture impedes fine-grained distributed protocols and makes event-driven agreement require additional storage I/O.Source: §3 · p. 3

3.1 Case Studies

• 21× slower and 7.3× more expensive than EC2, Lambda took 465 minutes and cost $0.29 to train the model.The same training process on EC2 took about 1,300 seconds and cost $0.04; Lambda spent 2.49 seconds of each 3.08-second iteration fetching a 100MB batch from S3.Source: §3.1 · p. 4
• 27× faster on m5.large EC2 than optimized Lambda, while direct ZeroMQ messaging was 127× faster and saved 57× in projected cost.The optimized Lambda batch latency was 447ms, versus 13ms using EC2 with SQS and 2.8ms using EC2 with ZeroMQ; the projected cost at one million messages per second was $1,584/hour for SQS alone versus $27.84/hour for 290 EC2 instances.Source: §3.1 · p. 4
• Storage-mediated communication was at least an order of magnitude too slow; DynamoDB-based leader election took 16.7 seconds per round and cost at least $450/hour for 1,000 nodes.The communication study compared 1KB exchanges through Lambda, S3, DynamoDB, and direct ZeroMQ messaging; the authors conclude cloud storage is not a reasonable replacement for direct networking.Source: §3.1 · p. 5, Table 1 · p. 5

3.2 Can Limitations Set Us Free?

• FaaS constraints may encourage loosely consistent, asynchronous programming and foster platform development, but the scalable end-state remains unsettled and some constraints may be overcome while retaining autoscaling.The authors compare the potential community effect to MapReduce’s influence on later SQL and dataframe interfaces.Source: §3.2 · pp. 5–6

3.3 Early Objections

• Faster networks and logical separation of compute and storage do not remove the need for physical co-location options, and current FaaS may favor narrow applications while deterring open-source stateful services.The authors acknowledge the economic appeal of autoscaling for narrow applications, but argue it does not enable general-purpose cloud programming or the broader innovation they seek.Source: §3.3 · p. 6
• They urge moving beyond debates over what serverless is or whether it will win toward rethinking infrastructure and programming models for data-rich, cloud-scale innovation.Source: §3.3 · p. 6
• The authors see cloud programming’s future as far brighter than today’s serverless FaaS offerings.Source: §3.3 · p. 7
• Realizing that future requires revisiting the designs and limitations of what is called serverless computing today.Source: §3.3 · p. 7

Fluid Code and Data Placement

• Cloud infrastructure should colocate code with data for performance while keeping them logically separate for elastic placement, replication, and repartitioning.High-level, data-centric DSLs can expose data flow and expand the infrastructure’s optimization space.Source: §4 · p. 7

Heterogeneous Hardware Support

• Cloud platforms should dynamically assign applications to cost-effective specialized hardware according to logical performance requirements, enabling both DSL compilation and hardware/software co-design.These specifications can support heterogeneity-aware resource space-time multiplexing.Source: §4 · p. 7

Long-Running, Addressable Virtual Agents

• Programmers need persistent, addressable virtual agents that recoup code, data, or hardware affinity costs across requests while dynamically remapping across physical resources.Virtual endpoints should approach standard-network performance and add minimal overhead to raw networking.Source: §4 · p. 7

Service-level objectives & guarantees

• Programmers need upfront SLOs priced accordingly, while predictable guarantees require a smooth optimization cost surface.The authors note that major FaaS offerings lack SLO APIs and price by resource size and runtime.Source: §4 · p. 7

Disorderly programming

• Cloud languages should replace sequential programming with granular, movable units of computation and data suited to distributed elastic execution.A key challenge is reasoning about distributed-data consistency semantics alongside asynchronous and declarative programming metaphors,,, [9],,.Source: §4 · p. 7

Flexible Programming, Common IR

• A common cloud-execution IR could let diverse languages target shared optimizations while supporting pluggable code such as UDFs or FaaS functions.Without a common IR, each language stack must implement the relevant optimizations independently.Source: §4 · p. 7

Security concerns

• Higher-level abstractions and provider-managed infrastructure may improve security, but fluid code movement toward shared data complicates multitenancy protection and requires auditing, post-hoc analysis, and finer-grained user policy controls.Hardware enclaves may help protect running code; initial data-processing work in those settings is cited as.Source: §4 · pp. 7–8

Future research

• The authors see these challenges as surmountable and expect third-party systems, formal research, and language design to help unlock the cloud’s potential.They note that systems work can use features such as container orchestration despite providers’ FaaS platforms not being fully open source.Source: §4 · p. 8