PaperlayerView exact revision on arXiv

Source-linked AI summary

Serverless Computing: A Survey of Opportunities, Challenges and Applications

Hossein Shafiei, Ahmad Khonsari, Payam Mousavi

arXiv:1911.01296v4cs.NI

TL;DR

Serverless computing lacks a formal definition and faces challenges that affect its broader adoption, including security, provider management, and application-domain-specific concerns. This paper surveys opportunities, application domains, reported challenges, existing solutions, limitations, and open problems. It concludes that serverless research requires further investigation across these challenges while documenting concrete approaches and opportunities.

  • Problem

    Serverless computing faces reported challenges toward broad adoption, while no formal definition exists and some challenges have received insufficient prior discussion.

  • Method

    The paper surveys application domains, categorizes their migration objectives and challenges, assesses serverless aptness, and reviews solutions, limitations, and open problems.

  • Results

    The survey identifies opportunities, categorizes serverless applications, evaluates their aptness, and reports challenges, solutions, research needs, and open problems.

  • Takeaways & Limitations

    The paper presents serverless opportunities and identifies areas requiring further research to support broader adoption.

  • Takeaways & Limitations

    Provider management can require heavy online information overhead for precise decisions, while partial information may produce imprecise controller decisions.

Abstract

from arXiv · show

The topic of serverless computing has proved to be a controversial subject both within academic and industrial communities. Many have praised the approach to be a platform for a new era of computing and some have argued that it is in fact a step backward. Though, both sides agree that there exist challenges that must be addressed in order to better utilize its potentials. This paper surveys existing challenges toward vast adoption of serverless services and also explores some of the challenges that have not been thoroughly discussed in the previous studies. Each challenge is discussed thoroughly and a number of possible directions for future studies is proposed. Moreover, the paper reviews some of the unique opportunities and potentials that the serverless computing presents.

1 INTRODUCTION

Serverless computing hides infrastructure and platform management from customers while pursuing pay-as-you-go billing and automatic scaling. This survey examines its applications, opportunities, and adoption challenges, including domain-specific issues and emerging function marketplaces.

  • Serverless computing hides infrastructure and platforms from customers, who focus on application functionality while providers handle the rest.
  • The model aims to relieve infrastructure management, use pay-as-you-go billing, and automatically scale services with customer demand.
  • The survey categorizes real-world serverless applications into eight domains and assesses migration objectives and paradigm aptness.
  • The paper analyzes challenges reported across application domains, categorizes existing solutions, identifies limitations, and highlights open research problems.
  • Serverless opportunities include customer-friendly deployment, affordability in some scenarios, and emerging marketplaces for reusable functions.

2 DEFINITION AND CHARACTERISTICS

Serverless computing lacks a formal definition, but commonly described services hide execution infrastructure, auto-scale resources, and charge according to actual use. Functions are the basic execution entities, with providers storing, invoking, and monitoring them.

  • 2.1 Definitions: FaaS lets customers develop, run, and manage application functionalities without building or maintaining infrastructure.
  • 2.1 Definitions: BaaS provides complete online cloud services, whereas FaaS executes user functions; both avoid customer resource management.
  • 2.1.3 Serverless service: A serverless service generalizes FaaS and BaaS through hidden execution environments, automatic scaling, pay-as-you-go billing, bounded execution, and function-based operation.
  • 2.1.3 Serverless service: A serverless application typically includes a client and registered provider-hosted functions, although clients are not essential in every scenario.
  • 2.1.3 Serverless service: Function invocation can form sequences such as F2 invoking F3, and these execution chains matter for performance optimization.
  • 2.1.3 Serverless service: Providers store functions, assign invocations to computation nodes, return results to clients, and use execution logs for improvement.

3 OPPORTUNITIES

Serverless computing offers reduced deployment complexity, automatic scalability, usage-dependent economics, and function marketplaces. These benefits depend on workload and usage conditions rather than applying uniformly.

  • 3.1 No deployment and maintenance complexity: Users can register functions and invoke them without managing infrastructure, packages, libraries, or platform configuration.
  • 3.2 Affordable scalability: Automatic scaling invokes a function copy per request and assigns each invocation to a feasible available resource.
  • 3.2 Affordable scalability: Resource multiplexing and infrastructure heterogeneity reduce provider costs and support serverless affordability.
  • 3.2 Affordable scalability: Serverless pay-as-you-go pricing is not always cheaper than renting a virtual machine; affordability depends on the usage scenario.
  • 3.3 New market places: Function marketplaces let developers sell reusable generalized or domain-specific functions, such as geospatial functions, to other users.
  • 3.3 New market places: Market competition may encourage function quality in code efficiency, cleanliness, documentation, and resource usage while enabling price-based choice.

4 APPLICATIONS

The survey categorizes real-world serverless applications across domains and assesses where serverless fits, emphasizing auto-scaling, pay-as-you-go pricing, and workload characteristics.

  • Serverless applications are categorized into eight domains, with migration reasons and aptitude assessed from authors’ arguments, results, and reported challenges.
  • Real-time collaboration and analytics: Statelessness makes serverless attractive for real-time collaboration tools, including instant messaging, chatbots, and GPS tracking.
  • Real-time collaboration and analytics: Auto-scaling enables data analytics services to handle concurrent massive data streams.
  • Urban and industrial management systems: Pay-as-you-go pricing supports budget-restricted urban and industrial management systems.
  • Scientific computing: Scientific applications with extensive fine-grained communication are difficult to support, whereas limited or coarse-grained communication is better suited.
  • Internet of Things (IoT): Serverless services suit IoT back-ends with infrequent, sporadic requests and can rapidly handle unpredictable surges through auto-scaling.

5 CHALLENGES

The survey organizes application-domain challenges and existing solutions, covering development tooling, pricing, cost prediction, and unresolved research needs.

  • The paper categorizes challenges into nine topics, surveys solutions, and identifies areas needing further research.
  • Programming, modeling, testing, and debugging: Insufficient development tools, concepts, and models hinder developers and contribute to non-unified approaches that can reduce code quality and complicate collaboration.
  • Programming, modeling, testing, and debugging: New programming frameworks or legacy-code ports are needed to support adoption of the serverless paradigm.
  • Programming, modeling, testing, and debugging: Serverless benchmarking and simulation tools target metrics such as communication efficiency, startup latency, and performance prediction.
  • Pricing and cost prediction: Multiple providers expose differing specifications and prices, while peak-demand electricity prices can reach 200-400 times nominal rates.
  • Pricing and cost prediction: Predicting serverless resource usage appears tractable: reported approaches achieve up to 96.1% and 98% accuracy, while another has error below 4%.

5.3 Scheduling

Serverless schedulers must place and time function executions to meet predefined deadlines while accounting for energy, resource, data, package, and workflow constraints. The surveyed directions include specialized schedulers and hybrid VM/serverless designs, with several opportunities for further study.

  • Schedulers place and time function executions to satisfy predefined deadlines while considering criteria such as energy consumption and resource utilization.These constraints are especially important for real-time, latency-sensitive, and safety-critical applications.
  • Energy-aware scheduling: Energy-aware scheduling reduces consumption by hibernating inactive execution environments, but cold-state transitions can delay functions beyond customer deadlines.Laboratory OpenWhisk estimates place cold-start latency at 2 to 6 seconds, compared with millisecond-scale real-world open-source executions.
  • Energy-aware scheduling: Scheduling mixed latency-sensitive and non-latency-sensitive functions could reduce energy by delaying background or maintenance tasks.The passage identifies this mixture as a direction for future research.
  • Resource-aware scheduling: Resource-aware schedulers account for heterogeneous CPU, memory, disk, and network demands because co-locating similar intensive functions can cause contention and execution delays.Scientific computing functions are described as typically CPU-intensive, whereas analytic applications are often memory-intensive.
  • Dataflow-, package-, workflow-, and hybrid-aware scheduling incorporate dependencies, package-installation delays, invocation chains, or placement across private VMs and serverless providers.Workflow speculation can prepare warm containers and has reduced overheads and delays by up to 10 times compared with OpenWhisk; proposed directions include probabilistic serverless DAGs and machine-learning-based library prediction.

5.4 Networking, sharing and intra-communications

Serverless applications require networking and communication mechanisms that accommodate dynamic, short-lived, globally replicated functions. Existing approaches trade generality, coordination overhead, latency, and runtime performance.

  • Addressing: Auto-scaling creates multiple concurrent invocations, while short function lifetimes make name-, location-, and state-based addressing difficult.Addressing must track rapid system-wide changes and accommodate the distributed nature of function instances.
  • Communication approaches: Even with addressing, functions can communicate through brokers, data exchange, APIs, or direct TCP/IP sockets.The surveyed approaches include coordinators, cloud storage or message queues, stateless protocols such as REST or SOAP, and direct sockets.
  • Communication approaches: Broker-based coordination may impose substantial infrastructure overhead, motivating performance evaluation and optimization.The paper identifies bottleneck analysis and optimization of contributing factors as directions for further research.
  • Communication approaches: Data-exchange communication can impose an order of magnitude higher latency than point-to-point communication.This motivates faster protocols and data-exchange methods designed specifically for function communication.
  • Communication approaches: Generalized networking over TCP/IP achieved 621 Mbit/s sustained throughput and less than 1 ms round-trip latency, while Particle improved application runtime by up to 3 times.These results illustrate potential benefits from networking designed for serverless settings.

5.5 Serverless workflows

Serverless workflows coordinate the interdependent functions composing most applications and can be represented as directed task graphs. Developers can define workflows explicitly, or providers can infer them from application behavior.

  • Workflow structure: Serverless applications usually comprise interdependent functions that execute in multiple possible sequences.Different user actions can produce different chains of function execution within the same application.
  • Workflow structure: A directed task graph represents functions as nodes and execution dependencies or precedence relationships as edges.The example includes parallel execution, branches, self-loops, and cycles across eight functions.
  • Workflow approaches: Two main workflow approaches are identified: developer-specified workflows and provider-generated workflow graphs.The first requires a workflow file or interface definition, whereas the second derives execution chains from application behavior.
  • Workflow approaches: Existing providers use different workflow specification mechanisms, including state-machine languages and general-purpose programming languages.Examples include Amazon States Language, Azure programming languages, and Python for Google Composer; platform-independent languages remain an area of interest.
  • Evaluation: Empirical studies have examined the characteristics and performance of serverless workflow services using real-world workloads.The literature also includes studies of sequential workflows and domain-specific workflow systems.

5.6 Packing

Data movement and placement strongly affect serverless performance because functions may depend on remote data sources. Packing functions with data can reduce traffic, but placement decisions must balance locality, cost, resource utilization, and application behavior.

  • Motivation: Remote data dependencies can make function execution orders of magnitude slower because provider-internal traffic increases latency.This motivates placing functions as near as possible to the data they access.
  • Systems: Shredder executes serverless functions within storage nodes, whereas Lambda-KV aggregates compute and storage to enable data locality.Co-locating storage and compute complicates provisioning and utilization, while Lambda-KV is unsuitable for highly dynamic data such as some IoT readings.
  • Placement decisions: Kayak adaptively chooses whether to move data to functions or functions to data while maximizing throughput subject to application latency requirements.The preferred direction depends strongly on the application domain.
  • Placement decisions: Multiple data sources, storage constraints, data chunking, and incremental movement complicate packing decisions.Incremental movement may produce data inconsistency, while packing only relevant chunks can avoid moving an entire database.
  • Packing strategies: Function-data packing can occur before, during, or after a function’s first execution.Pre-execution packing uses declared data dependencies; later approaches can use execution logs, optimization, and machine learning.
  • Packing trade-offs: Packing may undermine statistical multiplexing, causing queuing delays and inefficient resource utilization.The paper identifies this trade-off as a direction for future research.

5.7 Data caching

Caching can reduce persistent-storage bottlenecks in serverless systems, but infrastructure independence complicates cache placement and design. Effective strategies depend on data locality, workflow sequences, and the costs of distributed routing.

  • Caching challenges: Serverless caching is challenging because independently executed functions do not directly control the infrastructure hosting their cached data.Caching user data can serve later requests, but placement must account for where subsequent functions execute.
  • Cache placement: Packing functions near data can simplify caching by enabling efficient local caches around computation nodes.This shifts attention from system-wide caching toward locality-aware mechanisms.
  • Cache placement: Sequential workflow chains can improve caching effectiveness because consecutive functions are likely to share data dependencies.Local caching strategies should therefore consider execution chains.
  • Distributed caching: Distributed caching is useful when functions cannot be placed near their data, typically locating cached data through distributed hash functions.The requester retrieves and caches source data when it is absent from the distributed cache.
  • Distributed caching: Distributed caching may cost more than retrieving data directly when routing cached data to functions exceeds source-extraction cost.This cost comparison must be considered in serverless cache design.

5.8 Provider Management

Provider management coordinates function registration, invocation, execution, and monitoring while maintaining an online view of distributed infrastructure state. Centralized controllers are simpler and more efficient but risk overload and single-point failure, whereas distributed monitoring is harder to implement.

  • Controller responsibilities: The provider manages function registration, invocation, placement, scheduling, packing, caching, and execution-node assignment.Registration returns invocation credentials; invocation checks credentials and assigns functions to feasible computation nodes.
  • Initialization and Execution: Sandbox execution environments isolate function instances, with containers, Catalyzer, MicroVMs, and unikernels offering different isolation and startup trade-offs.Catalyzer provides sub-millisecond startup; FireCracker provides less than 5MB memory overhead and millisecond-scale boot time.
  • Monitoring: Monitoring collects execution logs to detect errors, analyze execution footprints, and improve future invocations, although commercial tools often provide only basic metrics.Examples include Epsagon, Datadog, and Dynatrace.
  • Controller architecture: Centralized control is more straightforward and efficient but can face extreme loads and become a single point of failure, while distributed monitoring is complex.The choice therefore involves operational simplicity versus resilience and implementation difficulty.
  • System state: An online controller view combines function, infrastructure, data-source, and local-cache state, but maintaining complete information creates heavy overhead.Partial information may instead lead to imprecise controller decisions.

5.9 Security and Privacy

Serverless security and privacy challenges span authentication, authorization, shared execution environments, resource exhaustion, and inference from contextual data. The surveyed responses include stronger protocols, workflow-level access control, isolated runtimes, and anonymity mechanisms.

  • Authentication: Authentication must ensure that only legitimate applications use available functions, but bearer tokens require protected channels and lightweight alternatives may suit constrained devices.Request signing is proposed for low-power IoT and embedded hardware where public-key protocols may exceed capabilities.
  • Authentication and authorization: Authorization controls which users or functions may invoke another function, and function-level role-based access control does not cover workflow-level access.WillIam is proposed to provide identity and access control for serverless workflows.
  • Execution isolation: Shared execution environments heighten vulnerability to cross-function attacks such as Meltdown and Spectre, motivating secure enclaves and customized runtime monitoring.SecLambda intercepts HTTP requests and I/O operations against predefined security policies.
  • Resource exhaustion: Resource-exhaustion attacks can disrupt services or impose excessive costs on customers and providers, including by exploiting provider optimization mechanisms.Attackers may inject dependencies that prevent placement near data sources and increase internal network traffic.
  • Privacy: Privacy attacks infer information from limited data, including invoked functions, invocation sequences, and invocation time or location.The paper calls for anonymity and disguise methods to prevent privacy breaches in serverless services.

6 CONCLUSION

The paper surveys serverless opportunities and application domains, assesses their aptness, and organizes domain-specific challenges and solutions. It also identifies limitations, open problems, and areas requiring further research.

  • Conclusion: The survey categorizes serverless application domains, summarizes migration objectives, and assesses paradigm aptness using authors’ arguments and obtained results.It also surveys opportunities presented by broad adoption of serverless computing.
  • Conclusion: The paper categorizes challenges reported across application domains, discusses existing solutions and their limitations, and identifies open research problems.The conclusion frames these areas as priorities for further research investigation.
Loading 1911.01296v4…