Status of Serverless Computing and Function-as-a-Service(FaaS) in Industry and Research

1 Introduction

• Panel presentations were invited on the field’s state and adoption, whether serverless is new or fundamentally different, and real-world research challenges.Other suggested topics included platform scope, benchmarking, and a technology-and-adoption timeline.Source: §1 · pp. 1–2
• Suggested panel topics also included defining serverless platforms, proposing a comparison benchmark, and outlining technology and adoption evolution.Source: §1 · pp. 1–2
• The whitepaper emphasizes workshop and panel themes rather than reproducing the detailed notes, which are available in a separate document.Source: §1 · p. 2
• The authors describe serverless computing [11] as a platform for research and academic use, noting Spark and direct analytics-runtime experiments [13].Source: §1 · p. 2

2 Basic Definition of Serverless and FaaS

• Serverless is described as having evolved over time, with the evolution illustrated in a figure.Source: §2 · p. 2

1. The beginning of usage of the term

• The section characterizes serverless as related but distinct concepts, with definitions ranging from hiding servers to on-demand scaling.Source: §1 · pp. 2–3
• The term covers functions hosted within a service as well as independent Function-as-a-Service offerings.Source: §1 · p. 3
• Serverless workloads run on demand, unlike SaaS or PaaS workloads that are always running but scale on demand.Source: §1 · p. 3
• Serverless is presented as potentially useful in areas summarized as strengths or limitations, though the discussion says that characterization could change.Source: §1 · p. 4
• The discussion treats event-driven computing, FaaS, statelessness, and short-running execution as associated ideas that may evolve independently.It gives event-driven FaaS supporting long-running jobs and serverless deployment across cloud scenarios as examples.Source: §1 · p. 4
• The section cites PyWren’s MapReduce based on FaaS [13] and event-driven computing’s importance to edge computing as examples of serverless breadth.Source: §1 · pp. 4–5

3.1 The definition compared to current practice in serviceless and FaaS

• The discussion contrasts a broad keynote definition with the IBM tutorial’s definition of serverless as Small Stateless Functions as a Service.Statelessness is described as not essential to the broader definition, but as a common feature.Source: §3.1 · p. 5
• Small, short-running functions are described as enabling lower FaaS costs by filling load between larger cloud jobs, though this may become one of several serverless offerings.Source: §3.1 · pp. 5–6
• The discussion leaves open how FaaS relates to dataflow systems, SaaS, traditional serverless, and event-driven computing, including whether FaaS is limited to event-driven computing.Source: §3.1 · p. 6
• The discussion notes that the nested classifications in Figs. 6 and 7 are inconsistent, reflecting confusion in an emerging field.Source: §3.1 · p. 6

3.2 What is new about Serverless?

• The FCC website’s collapse under comment traffic illustrates a possible serverless advantage for handling scale, while the discussion says scheduling technology needs improvement for elasticity and cloud bursting.Source: §3.2 · p. 7
• Integrated supporting services may create application dependence on the cloud provider and vendor lock-in, while the discussion asks what serverless adds and what it really costs.Source: §3.2 · p. 7

3.3 Is Serverless Necessarily Stateless?

• External state can support applications and let large datasets trigger multiple microservice-based FaaS invocations.The discussion points to AWS Step Functions for workflow orchestration and Spark RDDs with external in-memory databases for state access.Source: §3.3 · p. 8

3.4 Provider Side view of Serverless

• Better resource matching can address providers’ efficiency pressures and customers’ efforts to reduce resource waste, while network delay can still bill for unused time.The discussion also notes that time spent waiting on the network is wasted by both provider and customer.Source: §3.4 · p. 8

3.5 Can serverless work for longer running tasks?

• Long-running tasks reduce provider scheduling flexibility and make cost-effective SLAs more difficult; handing jobs to another container service or using Step Functions are proposed options.The discussion contrasts these with today’s very short-lived serverless workloads.Source: §3.5 · p. 9

3.6 Standards

• There are no directly applicable standards yet for a capability still being defined, although standards could ease movement of business logic and prevent vendor lock-in.The discussion notes AWS’s market leadership and that its technology could serve as a de facto standard; it also points to OpenWhisk’s community and CNCF’s working group as possible standards settings.Source: §3.6 · p. 9

3.7 Programming models

• Reactive, logic, and functional programming models are among the possibilities discussed for FaaS, including the challenge of moving compute around.The discussion describes programming languages and runtimes as opportunities for innovation at this early stage.Source: §3.7 · p. 10

3.8 Are there any cons to Serverless and FaaS?

• Concerns include vendor lock-in, inadequate SLAs for latency-sensitive uses, and significant challenges running OpenStack and Docker at scale.The discussion also raises whether serverless pricing can remain attractive as applications grow more complex.Source: §3.8 · p. 10

3.9 Current Serverless Systems

• The workshop discussion says current serverless performance results seemed quite erratic in this early stage.It also identifies defining a benchmark and building community around it as needs.Source: §3.9 · p. 11
• Google Firebase was highlighted as a valuable serverless IoT tool.The systems discussion also covered AWS technologies and OpenWhisk, among others.Source: §3.9 · p. 11

4 Use Cases for Serverless and FaaS

• The breadth of use cases is described as driving current interest in serverless, with cloud monitoring and customer triggers supporting richer declarative policies.The discussion also mentions chatbots and established distributed-computing approaches as context for event-based applications.Source: §4 · p. 12

4.1 What are established use cases for serverless?

• User convenience and automatic elastic scaling are identified as established motivations, including for e-commerce demand surges.The keynote grouped use cases into web applications, backends including IoT, Big Data, chatbots, Alexa, and IT automation.Source: §4.1 · p. 12
• Thomson Reuters processes 4,000 requests per second and Expedia 1.2 billion requests per month on Lambda; Vevo handles spikes of a factor 80 using serverless.These examples were presented alongside use cases such as media analysis, ETL, recommendations, and financial monitoring.Source: §4.1 · pp. 12–13

4.2 Can serverless help with scientific research?

• Scientific instruments and laboratory management systems are presented as potential settings where FaaS could unify data workflows.Science experiments may involve events, such as huge images, larger than those seen commercially.Source: §4.2 · p. 13
• A science data-management example monitors an HPC storage workload with over 3 million events per day using Ripple, with AWS Lambda handling the “that” actions.The passage describes file-system event detection with Python Watchdog and the Globus Transfer API; reproducibility, scalability, and cost remain to be explored for science use cases.Source: §4.2 · p. 13

5 Edge Computing: A Key Driver for Serverless and FaaS

• The workshop’s key takeaway is the connection between serverless and edge computing, with events shared across device, fog, and cloud environments.The discussion frames edge-cloud integration as the relevant link.Source: §5 · p. 14
• The proposed approach is to integrate the edge with the cloud rather than move computing to the edge.The passage notes that data centers are getting larger, not smaller, and that links between data centers and edge activities are the exception to its broader model.Source: §5 · p. 14
• Examples discussed include iRobot using Lambda and Step Functions for image recognition, AWS Greengrass extending Lambda to cloud-device environments, and Snowball Edge running Lambda@Edge software.Google Firebase is also identified as a related product.Source: §5 · p. 14

Future applications

• FaaS was optimistically forecast to support general-purpose computing, while its five-minute kill limit was expected to disappear and end developers to avoid managing scaling and distributed computing.The section also anticipates use in batch processing and reaching exascale on supercomputers.Source: §6 · p. 14
• Parallel programming was identified as a hot research topic, including extending FaaS beyond MapReduce toward batch processing and exascale supercomputing.Scientific notebooks also need integration with computing.Source: §6 · pp. 14–15

Libraries and runtime research

• FaaS could make libraries easier to invoke, while its fine-grained execution may permit new optimizations and a common runtime for multiple programming models.The section calls for research on those optimizations and points to next-generation FaaS compatible with Spark and Flink.Source: §6 · pp. 15–16

Debugging

• Near-term debugging work should support local testing followed by edge or cloud deployment, with a serverless debugger offering live breakpoints and replay.The discussion also proposed test-driven development with unit tests.Source: §6 · p. 15

Evaluation

• Performance and usability both matter, but evaluation metrics and needed service-level agreements remain to be defined; the technologies and their evaluation are immature.The discussion calls for benchmarks covering edge computing and other use cases.Source: §6 · pp. 15–16

Security

• Security remains an open concern, including whether a function needs more than a container and how events should be secured; unikernels were considered attractive.Source: §6 · p. 15

Billing and composition

• Research should determine which billing delays and overheads are inevitable and study common FaaS patterns, function compositions, and where a composition’s main program runs.AWS Step Functions was noted to separate function billing from composition coordination.Source: §6 · p. 15

Programming model and runtime

• Runtime research should address load balancing, scheduling, and data locality while supporting event-driven execution, hidden servers, fine-grained billing, implicit distribution, and low latency.The section distinguishes the provider-facing runtime from the user-facing programming model.Source: §6 · p. 15

• The conclusion treats edge and centralized computing as intrinsically intertwined rather than alternatives, with serverless supporting a common event-driven programming model across them.Source: §7 · p. 16
• The white paper aims to capture the current state of serverless and FaaS and inspire a broader community to become involved.Source: §7 · p. 16

Platforms and projects

• Open-source serverless platforms and projects include OpenWhisk, Funktion, Kubeless, Fission, OpenLambda, and Pipsqueak.OpenWhisk executes event-triggered functions; Funktion and the Kubernetes projects provide serverless functions, while OpenLambda is a serverless platform and Pipsqueak supports packages.Source: §8 · pp. 16–18

Cloud concepts

• Cloud and networking terms include CDN, edge computing, FaaS, IaaS, PaaS, and serverless.The glossary describes CDNs as geographically distributed proxy networks, edge computing as local resources supporting IoT, and serverless as hidden-server execution with dynamically managed resources and use-based billing.Source: §8 · pp. 17–18

Data and computing systems

• Streaming and data-computing entries include Storm and Heron, Kinesis, PyWren, Ripple, GridSolve, and dataflow.Their glossary descriptions cover streaming, Python MapReduce on Lambda, science event-based data management, remote computing functions, and execution graphs connecting nodes by data flow.Source: §8 · pp. 16–18

Infrastructure and software

• Other entries define Docker, Kubernetes, microservices, SaaS, unikernels, and high-performance computing.The glossary describes containers, container-cluster operations, loosely coupled services, cloud-operated applications, specialized single-address-space machine images, and large-scale computational science.Source: §8 · pp. 17–18

Related tools and approaches

• The glossary also covers Globus Transfer, Azure Functions, Cloud Native applications, and visual workflow tools such as Microsoft Logic Apps.Their entries describe secure high-performance data transfer, Azure’s FaaS implementation, cloud-oriented application design, and visual specification of connected-app workflows and triggers.Source: §8 · pp. 17–18

Cloud services

• The glossary lists cloud services spanning mobile development, event-based functions, edge compute, and Lambda orchestration and debugging.Firebase links mobile development to cloud event processing; Greengrass supports local device compute, messaging, caching, and sync; Step Functions orchestrates Lambda functions, and X-Ray analyzes and debugs distributed applications.Source: §8 · pp. 16–17