{"id":13772270,"url":"https://github.com/penghuima/awesome-serverless-papers","last_synced_at":"2025-12-25T08:37:20.774Z","repository":{"id":45775968,"uuid":"399335846","full_name":"penghuima/awesome-serverless-papers","owner":"penghuima","description":"Collect papers about serverless computing research","archived":false,"fork":false,"pushed_at":"2024-01-15T12:39:59.000Z","size":458,"stargazers_count":216,"open_issues_count":15,"forks_count":28,"subscribers_count":8,"default_branch":"main","last_synced_at":"2025-05-08T00:02:05.323Z","etag":null,"topics":["baas","backend-as-a-service","cloud-computing","edge-comupting","faas","function-as-a-service","serverless"],"latest_commit_sha":null,"homepage":"","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"gpl-3.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/penghuima.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"CONTRIBUTING.md","funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null}},"created_at":"2021-08-24T04:37:59.000Z","updated_at":"2025-05-02T15:11:56.000Z","dependencies_parsed_at":"2023-12-08T11:29:46.742Z","dependency_job_id":"46ae0918-1f70-44f4-98df-af3017f50445","html_url":"https://github.com/penghuima/awesome-serverless-papers","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/penghuima%2Fawesome-serverless-papers","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/penghuima%2Fawesome-serverless-papers/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/penghuima%2Fawesome-serverless-papers/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/penghuima%2Fawesome-serverless-papers/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/penghuima","download_url":"https://codeload.github.com/penghuima/awesome-serverless-papers/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":253518941,"owners_count":21921074,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["baas","backend-as-a-service","cloud-computing","edge-comupting","faas","function-as-a-service","serverless"],"created_at":"2024-08-03T17:01:02.050Z","updated_at":"2025-12-25T08:37:20.710Z","avatar_url":"https://github.com/penghuima.png","language":null,"funding_links":[],"categories":["Serverless"],"sub_categories":[],"readme":"- [CCFA](#ccfa)\n  - [Conference](#conference)\n    - [ASPLOS](#asplos)\n      - [2023](#2023)\n        - [1.AQUATOPE: QoS-and-Uncertainty-Aware Resource Management for Multi-stage Serverless Workflows](#1aquatope-qos-and-uncertainty-aware-resource-management-for-multi-stage-serverless-workflows)\n        - [2.BeeHive: Sub-second Elasticity for Web Services with Semi-FaaS Execution](#2beehive-sub-second-elasticity-for-web-services-with-semi-faas-execution)\n        - [3.ElasticFlow: An Elastic Serverless Training Platform for Distributed Deep Learning](#3elasticflow-an-elastic-serverless-training-platform-for-distributed-deep-learning)\n      - [2022](#2022)\n        - [1.IceBreaker: Warming Serverless Functions Better with Heterogeneity](#1icebreaker-warming-serverless-functions-better-with-heterogeneity)\n        - [2.INFless: a native serverless system for low-latency, high-throughput inference](#2infless-a-native-serverless-system-for-low-latency-high-throughput-inference)\n        - [3.FaaSFlow: enable efficient workflow execution for function-as-a-service](#3faasflow-enable-efficient-workflow-execution-for-function-as-a-service)\n        - [4.Serverless computing on heterogeneous computers](#4serverless-computing-on-heterogeneous-computers)\n      - [2021](#2021)\n        - [1.Nightcore: efficient and scalable serverless computing for latency-sensitive, interactive microservices](#1nightcore-efficient-and-scalable-serverless-computing-for-latency-sensitive-interactive-microservices)\n        - [2.FaasCache: keeping serverless computing alive with greedy-dual caching](#2faascache-keeping-serverless-computing-alive-with-greedy-dual-caching)\n        - [3.Benchmarking, analysis, and optimization of serverless function snapshots](#3benchmarking-analysis-and-optimization-of-serverless-function-snapshots)\n      - [2020](#2020)\n        - [1.Catalyzer: Sub-millisecond Startup for Serverless Computing with Initialization-less Booting](#1catalyzer-sub-millisecond-startup-for-serverless-computing-with-initialization-less-booting)\n    - [USENIX ATC](#usenix-atc)\n      - [2023](#2023-1)\n        - [1.Sponge: Fast Reactive Scaling for Stream Processing with Serverless Frameworks](#1sponge-fast-reactive-scaling-for-stream-processing-with-serverless-frameworks)\n        - [2.On-demand Container Loading in AWS Lambda](#2on-demand-container-loading-in-aws-lambda)\n        - [3.Decentralized and Stateful Serverless Computing on the Internet Computer Blockchain](#3decentralized-and-stateful-serverless-computing-on-the-internet-computer-blockchain)\n      - [2022](#2022-1)\n        - [1.RunD: A Lightweight Secure Container Runtime for High-density Deployment and High-concurrency Startup in Serverless Computing](#1rund-a-lightweight-secure-container-runtime-for-high-density-deployment-and-high-concurrency-startup-in-serverless-computing)\n        - [2.Help Rather Than Recycle: Alleviating Cold Startup in Serverless Computing Through Inter-Function Container Sharing](#2help-rather-than-recycle-alleviating-cold-startup-in-serverless-computing-through-inter-function-container-sharing)\n        - [3.Tetris: Memory-efficient Serverless Inference through Tensor Sharing](#3tetris-memory-efficient-serverless-inference-through-tensor-sharing)\n      - [2021](#2021-1)\n        - [1.SONIC: Application-aware Data Passing for Chained Serverless Applications](#1sonic-application-aware-data-passing-for-chained-serverless-applications)\n        - [2.FaaSNet: Scalable and Fast Provisioning of Custom Serverless Container Runtimes at Alibaba Cloud Function Compute](#2faasnet-scalable-and-fast-provisioning-of-custom-serverless-container-runtimes-at-alibaba-cloud-function-compute)\n        - [3.Faastlane: Accelerating Function-as-a-Service Workflows](#3faastlane-accelerating-function-as-a-service-workflows)\n      - [2020](#2020-1)\n        - [1.Serverless in the Wild: Characterizing and Optimizing the Serverless Workload at a Large Cloud Provider](#1serverless-in-the-wild-characterizing-and-optimizing-the-serverless-workload-at-a-large-cloud-provider)\n        - [2.Faasm: Lightweight Isolation for Efficient Stateful Serverless Computing](#2faasm-lightweight-isolation-for-efficient-stateful-serverless-computing)\n      - [2018](#2018)\n        - [1.SOCK: Rapid Task Provisioning with Serverless-Optimized Containers](#1sock-rapid-task-provisioning-with-serverless-optimized-containers)\n        - [2.Peeking Behind the Curtains of Serverless Platforms](#2peeking-behind-the-curtains-of-serverless-platforms)\n        - [3.Understanding Ephemeral Storage for Serverless Analytics](#3understanding-ephemeral-storage-for-serverless-analytics)\n        - [4.SAND: Towards High-Performance Serverless Computing](#4sand-towards-high-performance-serverless-computing)\n    - [ISCA](#isca)\n      - [2023](#2023-2)\n        - [1.MXFaaS: Resource Sharing in Serverless Environments for Parallelism and Efficiency](#1mxfaas-resource-sharing-in-serverless-environments-for-parallelism-and-efficiency)\n      - [2021](#2021-2)\n        - [1.Confidential Serverless Made Efficient with Plug-In Enclaves](#1confidential-serverless-made-efficient-with-plug-in-enclaves)\n    - [FAST](#fast)\n      - [2020](#2020-2)\n        - [1.InfiniCache: Exploiting Ephemeral Serverless Functions to Build a Cost-Effective Memory Cache](#1infinicache-exploiting-ephemeral-serverless-functions-to-build-a-cost-effective-memory-cache)\n    - [FSE/ESEC](#fseesec)\n      - [2021](#2021-3)\n        - [1.An empirical study on challenges of application development in serverless computing](#1an-empirical-study-on-challenges-of-application-development-in-serverless-computing)\n        - [2.Automating serverless deployments for DevOps organizations](#2automating-serverless-deployments-for-devops-organizations)\n    - [SOSP](#sosp)\n      - [2023](#2023-3)\n        - [1.XFaaS: Hyperscale and Low Cost Serverless Functions at Meta](#1xfaas-hyperscale-and-low-cost-serverless-functions-at-meta)\n      - [2021](#2021-4)\n        - [1.Boki: Stateful Serverless Computing with Shared Logs](#1boki-stateful-serverless-computing-with-shared-logs)\n        - [2.Faster and Cheaper Serverless Computing on Harvested Resources](#2faster-and-cheaper-serverless-computing-on-harvested-resources)\n        - [3.FlashCube: Fast Provisioning of Serverless Functions with Streamlined Container Runtimes](#3flashcube-fast-provisioning-of-serverless-functions-with-streamlined-container-runtimes)\n    - [OSDI](#osdi)\n      - [2023](#2023-4)\n        - [1.Automated Verification of Idempotence for Stateful Serverless Applications](#1automated-verification-of-idempotence-for-stateful-serverless-applications)\n      - [2021](#2021-5)\n        - [1.Dorylus: Affordable, Scalable, and Accurate GNN Training with Distributed CPU Servers and Serverless Threads](#1dorylus-affordable-scalable-and-accurate-gnn-training-with-distributed-cpu-servers-and-serverless-threads)\n      - [2020](#2020-3)\n        - [1.Fault-tolerant and transactional stateful serverless workflows](#1fault-tolerant-and-transactional-stateful-serverless-workflows)\n      - [2018](#2018-1)\n        - [1.Pocket: Elastic Ephemeral Storage for Serverless Analytics](#1pocket-elastic-ephemeral-storage-for-serverless-analytics)\n    - [NSDI](#nsdi)\n      - [2021](#2021-6)\n        - [1.Caerus: NIMBLE Task Scheduling for Serverless Analytics](#1caerus-nimble-task-scheduling-for-serverless-analytics)\n      - [2020](#2020-4)\n        - [1.Firecracker: Lightweight Virtualization for Serverless Applications](#1firecracker-lightweight-virtualization-for-serverless-applications)\n      - [2019](#2019)\n        - [1.Shuffling, Fast and Slow: Scalable Analytics on Serverless Infrastructure](#1shuffling-fast-and-slow-scalable-analytics-on-serverless-infrastructure)\n    - [VLDB](#vldb)\n      - [2020](#2020-5)\n        - [1.Cloudburst: Stateful Functions-as-a-Service](#1cloudburst-stateful-functions-as-a-service)\n      - [2019](#2019-1)\n        - [1.Stateful Functions as a Service in Action](#1stateful-functions-as-a-service-in-action)\n    - [INFOCOM](#infocom)\n      - [2022](#2022-2)\n        - [1.StepConf: SLO-Aware Dynamic Resource Configuration for Serverless Function Workflows](#1stepconf-slo-aware-dynamic-resource-configuration-for-serverless-function-workflows)\n        - [2.Retention-Aware Container Caching for Serverless Edge Computing](#2retention-aware-container-caching-for-serverless-edge-computing)\n    - [EuroSys](#eurosys)\n      - [2023](#2023-5)\n        - [1.Palette Load Balancing: Locality Hints for Serverless Functions](#1palette-load-balancing-locality-hints-for-serverless-functions)\n        - [2.With Great Freedom Comes Great Opportunity: Rethinking Resource Allocation for Serverless Functions](#2with-great-freedom-comes-great-opportunity-rethinking-resource-allocation-for-serverless-functions)\n        - [3.Groundhog: Efficient Request Isolation in FaaS](#3groundhog-efficient-request-isolation-in-faas)\n      - [2022](#2022-3)\n        - [1.Fireworks: a fast, efficient, and safe serverless framework using VM-level post-JIT snapshot](#1fireworks-a-fast-efficient-and-safe-serverless-framework-using-vm-level-post-jit-snapshot)\n        - [2.Jiffy: elastic far-memory for stateful serverless analytics](#2jiffy-elastic-far-memory-for-stateful-serverless-analytics)\n        - [3.FaaSnap: FaaS made fast using snapshot-based VMs](#3faasnap-faas-made-fast-using-snapshot-based-vms)\n      - [2021](#2021-7)\n        - [1.OFC: an opportunistic caching system for FaaS platforms](#1ofc-an-opportunistic-caching-system-for-faas-platforms)\n      - [2020](#2020-6)\n        - [1.A fault-tolerance shim for serverless computing](#1a-fault-tolerance-shim-for-serverless-computing)\n        - [2.SEUSS: skip redundant paths to make serverless fast](#2seuss-skip-redundant-paths-to-make-serverless-fast)\n    - [ASE](#ase)\n      - [2021](#2021-8)\n        - [1.Towards a Serverless Java Runtime](#1towards-a-serverless-java-runtime)\n  - [Journal](#journal)\n    - [TC](#tc)\n      - [2022](#2022-4)\n        - [1.λDNN: Achieving Predictable Distributed DNN Training With Serverless Architectures](#1λdnn-achieving-predictable-distributed-dnn-training-with-serverless-architectures)\n    - [TPDS](#tpds)\n      - [2022](#2022-5)\n        - [1.Astrea: Auto-Serverless Analytics towards Cost-Efficiency and QoS-Awareness](#1astrea-auto-serverless-analytics-towards-cost-efficiency-and-qos-awareness)\n      - [2021](#2021-9)\n        - [1.Modeling and Optimization of Performance and Cost of Serverless Applications](#1modeling-and-optimization-of-performance-and-cost-of-serverless-applications)\n      - [2020](#2020-7)\n        - [1.Automated Fine-Grained CPU Cap Control in Serverless Computing Platform](#1automated-fine-grained-cpu-cap-control-in-serverless-computing-platform)\n        - [2.An Event-Driven Approach to Serverless Seismic Imaging in the Cloud](#2an-event-driven-approach-to-serverless-seismic-imaging-in-the-cloud)\n    - [TON](#ton)\n      - [2022](#2022-6)\n        - [1.CharmSeeker: Automated Pipeline Configuration for Serverless Video Processing](#1charmseeker-automated-pipeline-configuration-for-serverless-video-processing)\n    - [TSE](#tse)\n      - [2021](#2021-10)\n        - [1.The State of Serverless Applications: Collection, Characterization, and Community Consensus](#1the-state-of-serverless-applications-collection-characterization-and-community-consensus)\n- [CCFB](#ccfb)\n  - [Conference](#conference-1)\n    - [SoCC](#socc)\n      - [2023](#2023-6)\n        - [1.Golgi: Performance-Aware, Resource-Efficient Function Scheduling for Serverless Computing](#1golgi-performance-aware-resource-efficient-function-scheduling-for-serverless-computing)\n        - [2.Function as a Function](#2function-as-a-function)\n        - [3.Parrotfish: Parametric Regression for Optimizing Serverless Functions](#3parrotfish-parametric-regression-for-optimizing-serverless-functions)\n        - [4.AsyFunc: A High-Performance and Resource-Efficient Serverless Inference System via Asymmetric Functions](#4asyfunc-a-high-performance-and-resource-efficient-serverless-inference-system-via-asymmetric-functions)\n        - [5.How Does It Function? Characterizing Long-term Trends in Production Serverless Workloads](#5how-does-it-function-characterizing-long-term-trends-in-production-serverless-workloads)\n        - [6.The Gap Between Serverless Research and Real-world Systems](#6the-gap-between-serverless-research-and-real-world-systems)\n        - [7.Chitu: Accelerating Serverless Workflows with Asynchronous State Replication Pipelines](#7chitu-accelerating-serverless-workflows-with-asynchronous-state-replication-pipelines)\n      - [2022](#2022-7)\n        - [1.Owl: performance-aware scheduling for resource-efficient function-as-a-service cloud](#1owl-performance-aware-scheduling-for-resource-efficient-function-as-a-service-cloud)\n        - [2.QFaaS: accelerating and securing serverless cloud networks with QUIC](#2qfaas-accelerating-and-securing-serverless-cloud-networks-with-quic)\n        - [3.Cypress: input size-sensitive container provisioning and request scheduling for serverless platforms](#3cypress-input-size-sensitive-container-provisioning-and-request-scheduling-for-serverless-platforms)\n        - [4.Hermod: principled and practical scheduling for serverless functions](#4hermod-principled-and-practical-scheduling-for-serverless-functions)\n        - [5.SIMPPO: a scalable and incremental online learning framework for serverless resource management](#5simppo-a-scalable-and-incremental-online-learning-framework-for-serverless-resource-management)\n        - [6.SimLess: simulate serverless workflows and their twins and siblings in federated FaaS](#6simless-simulate-serverless-workflows-and-their-twins-and-siblings-in-federated-faas)\n      - [2021](#2021-11)\n        - [1.Faa$T: A Transparent Auto-Scaling Cache for Serverless Applications](#1faat-a-transparent-auto-scaling-cache-for-serverless-applications)\n        - [2.Atoll: A Scalable Low-Latency Serverless Platform](#2atoll-a-scalable-low-latency-serverless-platform)\n        - [3.Kraken: Adaptive Container Provisioning for Deploying Dynamic DAGs in Serverless Platforms](#3kraken-adaptive-container-provisioning-for-deploying-dynamic-dags-in-serverless-platforms)\n        - [4.Mu: An Efficient, Fair and Responsive Serverless Framework for Resource-Constrained Edge Clouds](#4mu-an-efficient-fair-and-responsive-serverless-framework-for-resource-constrained-edge-clouds)\n        - [5.Mind the Gap: Broken Promises of CPU Reservations in Containerized Multi-tenant Clouds](#5mind-the-gap-broken-promises-of-cpu-reservations-in-containerized-multi-tenant-clouds)\n        - [6.Characterizing Microservice Dependency and Performance: Alibaba Trace Analysis](#6characterizing-microservice-dependency-and-performance-alibaba-trace-analysis)\n        - [7.ServerMore: Opportunistic Execution of Serverless Functions in the Cloud](#7servermore-opportunistic-execution-of-serverless-functions-in-the-cloud)\n        - [8.On Merits and Viability of Multi-Cloud Serverless](#8on-merits-and-viability-of-multi-cloud-serverless)\n        - [9.Speedo: Fast dispatch and orchestration of serverless workflows](#9speedo-fast-dispatch-and-orchestration-of-serverless-workflows)\n        - [10.Cloud-Scale Runtime Verification of Serverless Applications](#10cloud-scale-runtime-verification-of-serverless-applications)\n      - [2020](#2020-8)\n        - [1.Wukong: a scalable and locality-enhanced framework for serverless parallel computing](#1wukong-a-scalable-and-locality-enhanced-framework-for-serverless-parallel-computing)\n        - [2.Characterizing serverless platforms with serverlessbench](#2characterizing-serverless-platforms-with-serverlessbench)\n        - [3.Photons: lambdas on a diet](#3photons-lambdas-on-a-diet)\n        - [4.Serverless linear algebra](#4serverless-linear-algebra)\n        - [5.Kappa: a programming framework for serverless computing](#5kappa-a-programming-framework-for-serverless-computing)\n        - [6.Sequoia: enabling quality-of-service in serverless computing](#6sequoia-enabling-quality-of-service-in-serverless-computing)\n        - [7.Particle: ephemeral endpoints for serverless networking](#7particle-ephemeral-endpoints-for-serverless-networking)\n      - [2019](#2019-2)\n        - [1.Narrowing the Gap Between Serverless and its State with Storage Functions](#1narrowing-the-gap-between-serverless-and-its-state-with-storage-functions)\n        - [2.Cirrus: a Serverless Framework for End-to-end ML Workflows](#2cirrus-a-serverless-framework-for-end-to-end-ml-workflows)\n        - [3.Practical Cloud Workloads for Serverless FaaS](#3practical-cloud-workloads-for-serverless-faas)\n    - [CLUSTER](#cluster)\n      - [2021](#2021-12)\n        - [1.Tackling Cold Start of Serverless Applications by Efficient and Adaptive Container Runtime Reusing](#1tackling-cold-start-of-serverless-applications-by-efficient-and-adaptive-container-runtime-reusing)\n        - [2.Supporting Elastic Compaction of LSM-tree with a FaaS Cluster](#2supporting-elastic-compaction-of-lsm-tree-with-a-faas-cluster)\n    - [ICDCS](#icdcs)\n      - [2023](#2023-7)\n        - [1.EdgeOrcher: Predictive Function Orchestration for Serverless-Based Edge Native Applications](#1edgeorcher-predictive-function-orchestration-for-serverless-based-edge-native-applications)\n        - [2.Edge-Assisted Adaptive Configuration for Serverless-Based Video Analytics](#2edge-assisted-adaptive-configuration-for-serverless-based-video-analytics)\n        - [3.Servo: Increasing the Scalability of Modifiable Virtual Environments Using Serverless Computing](#3servo-increasing-the-scalability-of-modifiable-virtual-environments-using-serverless-computing)\n      - [2022](#2022-8)\n        - [1.Escra: Event-driven, Sub-second Container Resource Allocation](#1escra-event-driven-sub-second-container-resource-allocation)\n      - [2021](#2021-13)\n        - [1.Defuse: A Dependency-Guided Function Scheduler to Mitigate Cold Starts on FaaS Platforms](#1defuse-a-dependency-guided-function-scheduler-to-mitigate-cold-starts-on-faas-platforms)\n        - [2.Gillis: Serving Large Neural Networks in Serverless Functions with Automatic Model Partitioning](#2gillis-serving-large-neural-networks-in-serverless-functions-with-automatic-model-partitioning)\n        - [3.Poster: Function Delivery Network: Extending Serverless to Heterogeneous Computing](#3poster-function-delivery-network-extending-serverless-to-heterogeneous-computing)\n        - [4.A Multi-Tenant Framework for Cloud Container Services](#4a-multi-tenant-framework-for-cloud-container-services)\n      - [2020](#2020-9)\n        - [1.λ-NIC: Interactive Serverless Compute on Programmable SmartNICs](#1λ-nic-interactive-serverless-compute-on-programmable-smartnics)\n        - [2.Serverless Straggler Mitigation using Error-Correcting Codes](#2serverless-straggler-mitigation-using-error-correcting-codes)\n        - [3.Characterizing Bottlenecks in Scheduling Microservices on Serverless Platforms](#3characterizing-bottlenecks-in-scheduling-microservices-on-serverless-platforms)\n    - [ICPP](#icpp)\n      - [2021](#2021-14)\n        - [1.AMPS-Inf: Automatic Model Partitioning for Serverless Inference with Cost Efficiency](#1amps-inf-automatic-model-partitioning-for-serverless-inference-with-cost-efficiency)\n    - [IPDPS](#ipdps)\n      - [2021](#2021-15)\n        - [1.Astra: Autonomous Serverless Analytics with Cost-Efficiency and QoS-Awareness.](#1astra-autonomous-serverless-analytics-with-cost-efficiency-and-qos-awareness)\n      - [2020](#2020-10)\n        - [1.Amoeba: QoS-Awareness and Reduced Resource Usage of Microservices with Serverless Computing](#1amoeba-qos-awareness-and-reduced-resource-usage-of-microservices-with-serverless-computing)\n    - [HPDC](#hpdc)\n      - [2022](#2022-9)\n        - [1.Benchmarking the Data Layer Across Serverless Platforms](#1benchmarking-the-data-layer-across-serverless-platforms)\n      - [2021](#2021-16)\n        - [1.A Serverless Framework for Distributed Bulk Metadata Extraction](#1a-serverless-framework-for-distributed-bulk-metadata-extraction)\n        - [2.LaSS: Running Latency Sensitive Serverless Computations at the Edge](#2lass-running-latency-sensitive-serverless-computations-at-the-edge)\n    - [ICWS](#icws)\n      - [2021](#2021-17)\n        - [1.A Measurement Study on Serverless Workflow Services](#1a-measurement-study-on-serverless-workflow-services)\n    - [Middleware](#middleware)\n      - [2021](#2021-18)\n        - [1.SeBS: a serverless benchmark suite for function-as-a-service computing](#1sebs-a-serverless-benchmark-suite-for-function-as-a-service-computing)\n        - [2.FaaSTCC: efficient transactional causal consistency for serverless computing](#2faastcc-efficient-transactional-causal-consistency-for-serverless-computing)\n      - [2020](#2020-11)\n        - [1.Prebaking Functions to Warm the Serverless Cold Start](#1prebaking-functions-to-warm-the-serverless-cold-start)\n        - [2.SplitServe: Efficiently Splitting Apache Spark Jobs Across FaaS and IaaS](#2splitserve-efficiently-splitting-apache-spark-jobs-across-faas-and-iaas)\n        - [3.Sledge: a Serverless-first, Light-weight Wasm Runtime for the Edge](#3sledge-a-serverless-first-light-weight-wasm-runtime-for-the-edge)\n        - [4.Fifer: Tackling Resource Underutilization in the Serverless Era](#4fifer-tackling-resource-underutilization-in-the-serverless-era)\n        - [5.Xanadu: Mitigating cascading cold starts in serverless function chain deployments](#5xanadu-mitigating-cascading-cold-starts-in-serverless-function-chain-deployments)\n      - [2019](#2019-3)\n        - [1.On the FaaS Track: Building Stateful Distributed Applications with Serverless Architectures](#1on-the-faas-track-building-stateful-distributed-applications-with-serverless-architectures)\n    - [HOTOS](#hotos)\n      - [2021](#2021-19)\n        - [1.From warm to hot starts: leveraging runtimes for the serverless era](#1from-warm-to-hot-starts-leveraging-runtimes-for-the-serverless-era)\n        - [2.From cloud computing to sky computing](#2from-cloud-computing-to-sky-computing)\n        - [3.The RESTless cloud](#3the-restless-cloud)\n      - [2017](#2017)\n        - [1.Will Serverless End the Dominance of Linux in the Cloud?](#1will-serverless-end-the-dominance-of-linux-in-the-cloud)\n    - [CRDI](#crdi)\n      - [2021](#2021-20)\n        - [1.Boxer: Data Analytics on Network-enabled Serverless Platforms](#1boxer-data-analytics-on-network-enabled-serverless-platforms)\n      - [2019](#2019-4)\n        - [1.Serverless Computing: One Step Forward, Two Steps Back](#1serverless-computing-one-step-forward-two-steps-back)\n  - [Journal](#journal-1)\n    - [SPE](#spe)\n      - [2022](#2022-10)\n        - [1.Container lifecycle-aware scheduling for serverless computing](#1container-lifecycle-aware-scheduling-for-serverless-computing)\n        - [2.AuctionWhisk: Using an auction-inspired approach for function placement in serverless fog platforms](#2auctionwhisk-using-an-auction-inspired-approach-for-function-placement-in-serverless-fog-platforms)\n        - [3.Standards-based modeling and deployment of serverless function orchestrations using BPMN and TOSCA](#3standards-based-modeling-and-deployment-of-serverless-function-orchestrations-using-bpmn-and-tosca)\n      - [2021](#2021-21)\n        - [1.Edge-adaptable serverless acceleration for machine learning Internet of Things applications](#1edge-adaptable-serverless-acceleration-for-machine-learning-internet-of-things-applications)\n        - [2.Function delivery network: Extending serverless computing for heterogeneous platforms](#2function-delivery-network-extending-serverless-computing-for-heterogeneous-platforms)\n    - [JSS](#jss)\n      - [2020](#2020-12)\n        - [1.Function-as-a-Service Performance Evaluation: A Multivocal Literature Review](#1function-as-a-service-performance-evaluation-a-multivocal-literature-review)\n      - [2019](#2019-5)\n        - [1.A Mixed-Method Empirical Study of Function-as-a-Service Software Development in Industrial Practice](#1a-mixed-method-empirical-study-of-function-as-a-service-software-development-in-industrial-practice)\n    - [TSC](#tsc)\n      - [2022](#2022-11)\n        - [1.Serverless Computing: State-of-the-Art, Challenges and Opportunities](#1serverless-computing-state-of-the-art-challenges-and-opportunities)\n    - [IS](#is)\n      - [2022](#2022-12)\n        - [1.Transactions across serverless functions leveraging stateful dataflows](#1transactions-across-serverless-functions-leveraging-stateful-dataflows)\n- [CCFC](#ccfc)\n  - [Conference](#conference-2)\n    - [HPCC](#hpcc)\n      - [2021](#2021-22)\n        - [1.Descriptive and Predictive Analysis of Aggregating Functions in Serverless Clouds: the Case of Video Streaming](#1descriptive-and-predictive-analysis-of-aggregating-functions-in-serverless-clouds-the-case-of-video-streaming)\n    - [HiPC](#hipc)\n      - [2021](#2021-23)\n        - [1.FaaSter: Accelerated Functions-as-a-Service with Heterogeneous GPUs](#1faaster-accelerated-functions-as-a-service-with-heterogeneous-gpus)\n    - [CCGRID](#ccgrid)\n      - [2022](#2022-13)\n        - [1.Pushing Serverless to the Edge with WebAssembly Runtimes](#1pushing-serverless-to-the-edge-with-webassembly-runtimes)\n        - [2.Tiny Autoscalers for Tiny Workloads: Dynamic CPU Allocation for Serverless Functions](#2tiny-autoscalers-for-tiny-workloads-dynamic-cpu-allocation-for-serverless-functions)\n        - [3.KneeScale: Efficient Resource Scaling for Serverless Computing at the Edge](#3kneescale-efficient-resource-scaling-for-serverless-computing-at-the-edge)\n        - [4.Energy-Aware Resource Scheduling for Serverless Edge Computing](#4energy-aware-resource-scheduling-for-serverless-edge-computing)\n        - [5.On Realizing Efficient Deep Learning Using Serverless Computing](#5on-realizing-efficient-deep-learning-using-serverless-computing)\n        - [6.A Serverless Engine for High Energy Physics Distributed Analysis](#6a-serverless-engine-for-high-energy-physics-distributed-analysis)\n        - [7.Towards a Model-Based Serverless Platform for the Cloud-Edge-IoT Continuum](#7towards-a-model-based-serverless-platform-for-the-cloud-edge-iot-continuum)\n        - [8.LatEst: Vertical elasticity for millisecond serverless execution](#8latest-vertical-elasticity-for-millisecond-serverless-execution)\n        - [9.AIBLOCK: Blockchain based Lightweight Framework for Serverless Computing using AI](#9aiblock-blockchain-based-lightweight-framework-for-serverless-computing-using-ai)\n        - [10.CASY: A CPU Cache Allocation System for FaaS Platform](#10casy-a-cpu-cache-allocation-system-for-faas-platform)\n        - [11.Type, pad, and place: Avoiding data leaks in Cloud-IoT FaaS orchestrations](#11type-pad-and-place-avoiding-data-leaks-in-cloud-iot-faas-orchestrations)\n      - [2021](#2021-24)\n        - [1.Data-driven scheduling in serverless computing to reduce response time](#1data-driven-scheduling-in-serverless-computing-to-reduce-response-time)\n        - [2.Deadline-aware Dynamic Resource Management in Serverless Computing Environments](#2deadline-aware-dynamic-resource-management-in-serverless-computing-environments)\n        - [3.Benchmarking Serverless Workloads on Kubernetes](#3benchmarking-serverless-workloads-on-kubernetes)\n        - [4.Algorithms for scheduling scientific workflows on serverless architecture](#4algorithms-for-scheduling-scientific-workflows-on-serverless-architecture)\n        - [5.High Performance Serverless Architecture for Deep Learning Workflows](#5high-performance-serverless-architecture-for-deep-learning-workflows)\n        - [6.A Reinforcement Learning Approach to Reduce Serverless Function Cold Start Frequency](#6a-reinforcement-learning-approach-to-reduce-serverless-function-cold-start-frequency)\n        - [7.AI-based Resource Allocation: Reinforcement Learning for Adaptive Auto-scaling in Serverless Environments](#7ai-based-resource-allocation-reinforcement-learning-for-adaptive-auto-scaling-in-serverless-environments)\n        - [8.Scheduling Containers Rather Than Functions for Function-as-a-Service](#8scheduling-containers-rather-than-functions-for-function-as-a-service)\n        - [9.Virtual Device Model extending NGSI-LD for FaaS at the Edge](#9virtual-device-model-extending-ngsi-ld-for-faas-at-the-edge)\n        - [10.QoS aware FaaS platform](#10qos-aware-faas-platform)\n      - [2020](#2020-13)\n        - [1.Performance Optimization for Edge-Cloud Serverless Platforms via Dynamic Task Placement](#1performance-optimization-for-edge-cloud-serverless-platforms-via-dynamic-task-placement)\n        - [2.Cost-Effective Malware Detection as a Service Over Serverless Cloud Using Deep Reinforcement Learning](#2cost-effective-malware-detection-as-a-service-over-serverless-cloud-using-deep-reinforcement-learning)\n      - [2019](#2019-6)\n        - [1.Beyond Load Balancing: Package-Aware Scheduling for Serverless Platforms](#1beyond-load-balancing-package-aware-scheduling-for-serverless-platforms)\n    - [ICPADS](#icpads)\n      - [2019](#2019-7)\n        - [1.Adaptive Function Launching Acceleration in Serverless Computing Platforms](#1adaptive-function-launching-acceleration-in-serverless-computing-platforms)\n  - [Journal](#journal-2)\n    - [JGC](#jgc)\n      - [2021](#2021-25)\n        - [1.Deployment Management and Topology Discovery of Microservice Applications in the Multicloud Environment](#1deployment-management-and-topology-discovery-of-microservice-applications-in-the-multicloud-environment)\n        - [2.Serverless Workflows for Containerised Applications in the Cloud Continuum](#2serverless-workflows-for-containerised-applications-in-the-cloud-continuum)\n        - [3.Highly Complex Resource Scheduling for Stochastic Demands in Heterogeneous Clouds](#3highly-complex-resource-scheduling-for-stochastic-demands-in-heterogeneous-clouds)\n- [Others](#others)\n  - [arXiv](#arxiv)\n      - [2022](#2022-14)\n        - [1.MLLess: Achieving Cost Efficiency in Serverless Machine Learning Training](#1mlless-achieving-cost-efficiency-in-serverless-machine-learning-training)\n        - [2.Topology-aware Serverless Function-Execution Scheduling](#2topology-aware-serverless-function-execution-scheduling)\n      - [2019](#2019-8)\n        - [1.Cloud Programming Simplified: A Berkeley View on Serverless Computing](#1cloud-programming-simplified-a-berkeley-view-on-serverless-computing)\n  - [Conference](#conference-3)\n    - [IEEE International Conference on Fog and Edge Computing (ICFEC)](#ieee-international-conference-on-fog-and-edge-computing-icfec)\n      - [2022](#2022-15)\n        - [1.FaDO: FaaS Functions and Data Orchestrator for Multiple Serverless Edge-Cloud Clusters](#1fado-faas-functions-and-data-orchestrator-for-multiple-serverless-edge-cloud-clusters)\n    - [IEEE Cloud Summit](#ieee-cloud-summit)\n      - [2020](#2020-14)\n        - [1.FaaS2F: A Framework for Defining Execution-SLA in Serverless Computing](#1faas2f-a-framework-for-defining-execution-sla-in-serverless-computing)\n    - [Conference on Machine Learning and Systems(MLSys)](#conference-on-machine-learning-and-systemsmlsys)\n      - [2021](#2021-26)\n        - [1. FirePlace: Placing FireCracker virtual machines with hindsight imitation](#1-fireplace-placing-firecracker-virtual-machines-with-hindsight-imitation)\n  - [Journal](#journal-3)\n    - [Proceedings of the ACM on Measurement and Analysis of Computing Systems](#proceedings-of-the-acm-on-measurement-and-analysis-of-computing-systems)\n      - [2022](#2022-16)\n        - [1.WISEFUSE: Workload Characterization and DAG Transformation for Serverless Workflows](#1wisefuse-workload-characterization-and-dag-transformation-for-serverless-workflows)\n    - [Proceedings of the VLDB Endowment](#proceedings-of-the-vldb-endowment)\n      - [2022](#2022-17)\n        - [1.Netherite: efficient execution of serverless workflows](#1netherite-efficient-execution-of-serverless-workflows)\n    - [ACM Computing Surveys](#acm-computing-surveys)\n      - [2022](#2022-18)\n        - [1.A Holistic View on Resource Management in Serverless Computing Environments: Taxonomy and Future Directions](#1a-holistic-view-on-resource-management-in-serverless-computing-environments-taxonomy-and-future-directions)\n\n# CCFA\n\n## Conference\n\n### ASPLOS\n\n#### 2023\n\n##### 1.AQUATOPE: QoS-and-Uncertainty-Aware Resource Management for Multi-stage Serverless Workflows\n\n**摘要：**\n\n多阶段无服务器应用程序，即具有**多个计算和 I/O 阶段的工作流**，正日益成为 FaaS 平台的代表。尽管这些应用在细粒度可扩展性和模块化开发方面具有优势，但与以前的简单无服务器函数相比，它们在更大程度上存在性能不佳、资源效率低下和成本高昂等问题。\n\n我们介绍的Aquatope是一种**用于端到端无服务器工作流的QoS和不确定性感知资源调度器，它考虑到了FaaS平台固有的不确定性，提高了性能可预测性和资源效率**。Aquatope 使用一套可扩展且经过验证的**贝叶斯模型**，在函数调用之前创建预热容器，并在函数粒度上分配适当的资源，以**满足复杂工作流的端到端 QoS，同时最大限度地降低资源成本**。在各种分析和交互式多阶段无服务器工作负载中，Aquatope 的性能明显优于先前的系统，与其他满足 QoS 的方法相比，QoS 违反率降低了 5 倍，成本平均降低了 34%，最高降低了 52%。\n\n##### 2.BeeHive: Sub-second Elasticity for Web Services with Semi-FaaS Execution\n\n**摘要：**\n\n函数即服务（FaaS）是一种新兴的云计算范式，由于其有望快速自动扩展细粒度功能，因此有望提供强大的弹性。虽然 FaaS 对具有良好并行性和动态工作负载的应用很有吸引力，但本文指出，由于现有单体应用（如网络服务）的复杂性，要将其改造成 FaaS 并不容易。 **为了缩小复杂网络服务与 FaaS 之间的差距，本文提出了一种基于运行时的半 FaaS 执行模型，它能动态地从应用程序中提取耗时的代码片段（闭包），并将其卸载到 FaaS 平台上执行。** 它进一步提出了半FaaS卸载框架BeeHive，该框架依靠托管运行时提供基于回退的执行模型，解决了传统FaaS卸载机制的性能问题。同时，BeeHive的运行时系统以用户透明的方式选择卸载候选对象，并支持分布式环境中高效的对象共享、内存管理和故障恢复。使用各种网络应用程序进行的评估表明，BeeHive支持的半FaaS执行可在AWS Lambda等商业化FaaS平台上实现亚秒级资源调配，比云计算领域的其他扩展方法高出两个数量级。\n\n##### 3.ElasticFlow: An Elastic Serverless Training Platform for Distributed Deep Learning\n\n**摘要：**\n\n本文提出了用于分布式深度学习的弹性无服务器训练平台 ElasticFlow。ElasticFlow 提供的无服务器界面有两个显著特点：(i) 用户只需指定作业的深度神经网络（DNN）模型和超参数，而无需指定 GPU 的数量；(ii) 用户只需指定作业的截止日期，而无需指定占用 GPU 的时间。与现有的以服务器为中心的平台相比，**ElasticFlow 在满足截止日期要求方面提供了性能保证，同时减轻了深度学习开发人员繁琐、低级和手动的资源管理工作** 。分布式训练的特点带来了两个挑战。首先，训练吞吐量与 GPU 数量呈非线性关系。其次，扩展效率受工作者位置的影响。为了应对这些挑战，**我们提出了 \"最小满意份额\"（Minimum Satisfactory Share）来捕捉训练作业在截止日期前的资源使用情况**，ElasticFlow 据此执行准入控制。我们**开发了一种贪婪算法，可根据收益递减原则动态分配资源给接纳的作业。我们将 \"好友分配 \"应用于工作布置，以消除拓扑结构的影响**。在 128 个 GPU 集群上进行的评估结果表明，与现有解决方案相比，ElasticFlow 能将满足截止日期要求的作业数量提高 1.46-7.65 倍。\n\n\n#### 2022\n\n\u003e 2022.2.28-3.14\n\u003e\n\u003e 有专门的关于 serverless 的会议主题\n\n##### 1.IceBreaker: Warming Serverless Functions Better with Heterogeneity \n\n**摘要：**\n\n无服务器计算是一种新兴的计算模式，它依赖于在预期执行前的 \"预热 \"函数，以便为用户提供更快、更经济的服务。不幸的是，**预热函数可能是不准确的，并且在预热期间会产生令人望而却步的昂贵成本（即函数保活成本）**。在本文中，**我们介绍了 IceBreaker，这是一种新颖的技术，通过用异构节点（昂贵和便宜）组成系统来减少服务时间和 \"保活 \"成本。IceBreaker 的做法是，根据函数的时间变化概率，动态地确定在具有成本效益类型的节点来预热函数。通过采用异构性，IceBreaker 允许在相同的成本预算下拥有更多数量的节点，因此可以保活更多数量的函数，并减少高负载时的等待时间**。我们的实际系统评估证实，IceBreaker 使用具有代表性的无服务器应用程序和行业级工作负载跟踪，将整体保持不变的成本降低了 45％，执行时间降低了 27％。IceBreaker 是第一个采用并利用昂贵和便宜节点混合的想法来改善无服务器函数的服务时间和保持成本的技术--为研究人员和从业者开辟了一条在异构服务器上进行无服务器计算的新研究途径。\n\n##### 2.INFless: a native serverless system for low-latency, high-throughput inference\n\n**摘要：**\n\n现代网站越来越依赖机器学习（ML）来提高其业务效率。开发和维护 ML 服务会给开发者带来高昂的成本。虽然无服务器系统是一个很有前途的降低成本的解决方案，但我们**发现目前的通用无服务器系统不能满足 ML 服务的低延迟、高吞吐量的需求。**\n\n虽然简单地 \"修补 \"通用无服务器系统并不能完全解决这个问题，但我们建议这样的系统应该将推理的特点与无服务器范式天然地结合起来。我们**提出了 INFless，这是第一个针对 ML 领域的无服务器平台。它在 CPU 和加速器之间提供了一个统一的、异构的资源抽象，并利用内置的批处理和非统一的扩展机制实现了高吞吐量。**它还通过协调管理批处理排队时间、执行时间和**冷启动率**支持低延迟。我们使用本地集群测试平台和大规模模拟来评估 INFless。实验结果表明，INFless 在系统吞吐量上优于最先进的系统 2-5 倍，满足了 ML 服务的延时目标。\n\n##### 3.FaaSFlow: enable efficient workflow execution for function-as-a-service \n\n**摘要：**\n\n无服务器计算（Function-as-a-Service）通过在容器中运行函数（或 Lambda）提供细粒度的资源共享。依赖于数据的函数需要按照预先定义的逻辑进行调用，这就是所谓的**无服务器工作流**。然而，我们的调查显示，传统的基于 master-worker 工作流执行架构在无服务器背景下表现不佳。**master-worker 工作流调度模式导致了一项重大开销，其中函数在主节点中触发并分配给工作节点执行。此外，worker 之间的数据移动也降低了吞吐量。**\n\n为此，我们**提出了一种用于无服务器工作流执行的 worker-side 工作流计划模式**。根据该设计，我们实现了 FaaSFlow，**以便在无服务器环境下实现高效的工作流执行**。**此外，我们提出了一个自适应存储库 FaaStore，它能够在同一节点上的函数之间快速传输数据，而无需通过数据库**。实验结果表明，FaaSFlow 有效地将工作流调度开销平均降低了 74.6%，数据传输开销最多降低了 95%。当网络带宽波动时，FaaSFlow-FaaStore 可以减少 23.0% 的吞吐量下降，并且能够使网络带宽的利用率提高 1.5-4 倍。\n\n##### 4.Serverless computing on heterogeneous computers \n\n**摘要：**\n\n现有的无服务器计算平台是建立在**同构**计算机基础上的，限制了函数密度，并将无服务器计算限制在有限的场景中。我们介绍**Molecule，这是第一个利用异构计算机的无服务器计算系统**。Molecule 使通用设备（如 Nvidia DPU）和特定领域的加速器（如 FPGA 和 GPU）都能用于无服务器应用，从而显著提高函数密度（高出 50%）和应用性能（高达 34.6 倍）。为了实现这些结果，我们首先提出了 XPU-Shim，这是一个分布式的 Shim，用于弥补底层多操作系统（当使用通用设备时）和我们的无服务器运行时间（即 Molecule）之间的差距。我们进一步介绍了矢量化沙箱，这是一种抽象硬件异构性的沙箱抽象（当使用特定领域的加速器时）。此外，我们还**回顾了关于启动和通信延迟的最先进的无服务器优化**，并克服了在异构计算机上实现这些优化的挑战。我们已经在实际平台上用 Nvidia DPU 和 Xilinx FPGA 实现了 Molecule，并使用基准和实际应用对其进行了评估。\n\n\u003e 研讨会\n\u003e\n\u003e [vHive 教程及 serverless 讲解](https://www.youtube.com/playlist?list=PLVdxPJaekjWqBsEUwnrYRQCaMqvcDVsBE)\n\n#### 2021 \n\n\u003e 2021.4.19-4.23\n\n##### 1.Nightcore: efficient and scalable serverless computing for latency-sensitive, interactive microservices \n\n摘要：\n\n微服务架构是一种流行的软件工程方法，用于构建灵活的大规模在线服务。无服务器计算或者函数计算提供了一个简单的无状态函数编程模型，它是实现微服务的无状态 RPC 处理程序的自然基础，是容器化 RPC 服务器的替代方案。但是，**当前的无服务器平台具有毫秒级的运行时开销，使其无法满足现有交互式微服务所需的严格的亚毫秒级延迟目标**。 \n\n我们展示了 **Nightcore，这是一个具有微秒级开销的无服务器函数运行时，可在函数之间提供基于容器的隔离。Nightcore 的设计仔细考虑了具有微秒级开销的各种因素，包括函数请求的调度、通信原语、I/O 的线程模型和并发函数执行。** Nightcore 目前支持用 C/C++、Go、Node.js 和 Python 编写的无服务器函数。我们的评估表明，在运行延迟敏感的交互式微服务时，Nightcore 实现了 1.36–2.93 倍更高的吞吐量和高达 69% 的尾部延迟减少。\n\n##### 2.FaasCache: keeping serverless computing alive with greedy-dual caching \n\n**摘要：**\n\n函数即服务（也称为无服务器计算）有望彻底改变应用程序使用云资源的方式。但是，由于在开始执行之前初始化其代码和数据依赖关系的开销，函数会遇到冷启动问题。**在函数完成执行后保活函数可以减轻冷启动开销**。Keep-alive 策略必须根据函数的资源和使用特性保持函数处于活动状态，**由于 FaaS 工作负载的多样性，这具有挑战性**。\n\n我们的见解是，keep-alive 类似于缓存。与当前方法相比，**我们受缓存启发的 Greedy-Dual keep-alive 策略可以有效地将冷启动开销减少 3 倍以上。重用距离和命中率曲线等缓存概念也可用于自适应的服务器资源配置**，这可以将 FaaS 提供商对现实世界动态工作负载的资源需求降低 30%。我们在基于 OpenWhisk 的 FaasCache 系统中实施基于缓存的保活和资源配置策略。我们希望我们的缓存类比为未来的 FaaS 工作负载和平台打开了更多原则和优化的保活和资源配置技术的大门。\n\n##### 3.Benchmarking, analysis, and optimization of serverless function snapshots \n\n**摘要：**\n\n无服务器计算因其高可扩展性和灵活的即用即付计费模式而被迅速采用。在无服务器中，开发人员将他们的服务构建为一组函数，由各种事件（如点击）零星地调用。函数调用的时间间隔变化很大，致使提供者在每次调用时都要启动新的函数实例，从而导致严重的冷启动延迟，降低了用户体验。**为了减少冷启动延迟，业界已转向快照，即在磁盘上存储一个完全启动的函数的镜像**，与从头开始启动函数相比，调用速度更快。\n\n这项工作引入了 **vHive，这是一个用于无服务器实验的开源框架**，旨在使研究人员能够在整个无服务器堆栈中进行研究和创新。使用 vHive，我们描述了一个最先进的基于快照的无服务器基础设施，它基于业界领先的 Containerd 协调框架和 Firecracker 管理程序技术。**我们发现从快照开始的函数的执行时间平均比同一个函数驻留在内存时高 95%。我们表明高延迟归因于频繁的缺页故障**，因为函数的状态一次一页地从磁盘进入客户内存。我们的分析进一步表明，**在同一函数的不同调用中，函数访问的是相同的稳定工作页面集**。通过利用这一洞察，我们**构建了 REAP，这是一种用于无服务器主机的轻量级软件机制，它可以记录函数的客户内存页的稳定工作集，并主动将其从磁盘预取到内存中。**与基线快照相比，REAP 将冷启动延迟平均减少了 3.7 倍。\n\n#### 2020\n\n\u003e 2020.3.18-3.20\n\n##### 1.Catalyzer: Sub-millisecond Startup for Serverless Computing with Initialization-less Booting\n\n**摘要：**\n\n无服务器计算为高效软件开发提供了成本效益和弹性。要实现这一点，**Serverless 沙箱系统必须解决两个挑战：函数实例之间的强隔离，以及低启动延迟以保证用户体验。**虽然基于虚拟化的沙箱可以提供强隔离，但沙箱和应用程序的初始化会导致不可忽略的启动开销。传统沙箱系统由于其与应用程序无关的特性而在低延迟启动方面存在不足：它们只能通过管理程序和客户内核的定制来减少沙箱初始化的延迟，这是不充分的，不能缓解大部分的启动开销。\n\n本文提出了 **Catalyzer，一种无服务器沙箱系统设计，提供强大的隔离和极快的函数启动**。 **Catalyzer 不是从头开始启动，而是从一个形式良好的检查点镜像中恢复一个基于虚拟化的函数实例，从而跳过关键路径上的初始化（无初始化）**。Catalyzer 通过按需恢复用户级内存状态和系统状态来提高恢复性能。我们还**提出了一个新的 OS 原语 sfork（沙箱分叉），通过直接重用正在运行的沙箱实例的状态来进一步减少启动延迟**。从根本上说，Catalyzer 通过重用状态消除了初始化成本，从而实现了对各种无服务器函数的一般优化。评估表明，Catalyzer 将启动延迟降低了几个数量级，在最佳情况下实现了 \u003c 1ms 的延迟，并显着降低了实际工作负载的端到端延迟。 **Catalyzer 已被蚂蚁金服采用**，我们也分享了产业发展的经验教训。\n\n\u003e 该会议只有 2020 年之后才陆陆续续收录有关 serverless 的文章，之前的年限里是没有这方面的文章的\n\n### USENIX ATC\n\n#### 2023\n\n##### 1.Sponge: Fast Reactive Scaling for Stream Processing with Serverless Frameworks\n\n**摘要：**\n\n流工作负载处理的是实时生成的数据。这些数据通常无法预测，而且数量变化迅速。为了应对这些波动，当前系统的目标是在机器集群中动态地缩放、重新分配和迁移计算任务。虽然之前的许多工作都集中在减少预分配集群资源上的系统重新配置和状态迁移的开销上，但这些方法在以较低的运营成本满足延迟 SLO 方面仍然面临巨大挑战，尤其是在面对不可预测的突发负载时。\n\n在本文中，我们提出了一种新的流处理系统 Sponge，它能利用无服务器框架（SF）实例**对长期运行的流查询进行快速反应式扩展**。利用无服务器框架实例可在几百毫秒内快速启动的优势，Sponge 可以低延迟、低成本地吸收来自现有虚拟机的突发性、不可预测的输入负载增长。**Sponge 可有效跟踪少量指标，快速检测突发负载，并根据这些指标做出快速扩展决策**。此外，通过在编译时纳入优化逻辑，并在**运行时触发快速数据重定向和部分状态合并机制，Sponge 避免了运行时的优化和状态迁移开销**，同时将突发负载从现有虚拟机高效卸载到新的 SF 实例。我们在 AWS EC2 和 Lambda 上使用 NEXMark 基准进行的评估表明，Sponge 能对突发输入负载做出迅速反应，与虚拟机上的其他流查询扩展方法相比，第 99 百分位数尾延迟平均减少了 88%。与过度配置虚拟机以处理不可预测的突发负载的方法相比，Sponge 还将成本降低了 83%。\n\n##### 2.On-demand Container Loading in AWS Lambda\n\n**摘要：**\n\nAWS Lambda 是一种无服务器事件驱动的计算服务，属于有时被称为功能即服务（FaaS）的云计算产品类别。我们首次发布 AWS Lambda 时，功能仅限于 250MB 的代码和依赖项，并打包为一个简单的压缩归档。2020 年，我们发布了对部署大至 10GiB 的容器映像作为 Lambda 功能的支持，使客户能够将更大的代码库和依赖集带到 Lambda。**支持更大的包，同时仍能满足 Lambda 的快速扩展（单个客户每秒可添加多达 15,000 个新容器，总计可添加更多容器）、高请求率（每秒数百万个请求）、高规模（数百万个独特的工作负载）和低启动时间（低至 50 毫秒）等目标，这给我们带来了巨大的挑战** 。\n\n我们将介绍为**按需交付容器镜像而优化构建的存储和缓存系统**，以及我们在设计、构建和大规模运行该系统方面的经验。我们将重点关注安全、效率、延迟和成本方面的挑战，以及我们如何在一个结合了缓存、重复数据删除、聚合加密、擦除编码和块级需求加载的系统中应对这些挑战。\n\n自构建该系统以来，它已为超过 100 万 AWS 客户可靠地处理了数百万亿次 Lambda 调用，并对负载和基础设施故障表现出卓越的恢复能力。\n\n##### 3.Decentralized and Stateful Serverless Computing on the Internet Computer Blockchain\n\n**摘要：**\n\n互联网计算机（IC）是一个基于区块链的快速高效的去中心化平台，用于执行智能合约形式的通用应用程序。换句话说，IC 服务是当前无服务器计算的对立面。与由单一实体运营的短暂、无状态功能不同，IC 通过不受信任的独立数据中心提供去中心化的有状态无服务器计算。开发人员部署有状态的罐子，为终端用户或其他罐子提供调用服务。IC的编程模型与无服务器云类似，应用程序使用 Rust 或 Python 等现代语言编写，但更加简单：状态自动维护，无需开发人员干预。\n\n在本文中，我们确定并解决了实现高效分散式有状态无服务器计算所面临的重大系统挑战：可扩展性、通过正交持久化实现的有状态执行以及确定性调度。我们介绍了IC的设计，并描述了其在过去 1.5 年中收集的运行数据及其性能。\n\n#### 2022\n\n\u003e 2022.7.11-7.13\n\n##### 1.RunD: A Lightweight Secure Container Runtime for High-density Deployment and High-concurrency Startup in Serverless Computing\n\n在微型虚拟机（VM）中承载单个容器的**安全容器**现在被用于无服务器计算，容器是通过微型虚拟机隔离的。由于无服务器平台中的用户函数是细粒度的，因此对高密度的容器部署和高并发的容器启动有很高的要求，以提高资源利用率和用户体验。我们的调查显示，整个软件堆栈，包括**主机操作系统中的 cgroup、来宾操作系统和用于函数工作负载的容器 rootfs，共同导致了低部署密度和高并发时的慢启动性能。**因此，我们提出并实现了一个轻量级的安全容器运行时，命名为 RunD，通过一个整体的 guest-to-host 的解决方案来解决上述问题。通过 RunD，在一秒钟内可以启动超过 200 个安全容器，在一个拥有 384GB 内存的节点上可以部署超过 2500 个安全容器。采用 RunD 作为阿里巴巴无服务器容器运行时，支持高密度部署和高并发的启动。\n\n##### 2.Help Rather Than Recycle: Alleviating Cold Startup in Serverless Computing Through Inter-Function Container Sharing\n\n在无服务器计算中，每个函数的调用都是在容器（或虚拟机）中执行的，而容器的冷启动会导致长时间的响应延迟。我们**观察到，一些函数受到容器冷启动的影响，而其他函数的温暖容器则处于闲置状态。基于这一观察，除了为一个函数从头开始启动一个新的容器外，我们建议通过重新利用另一个函数的温暖但闲置的容器来缓解冷启动的影响。**我们实现了一个容器管理方案，名为 Pagurus，以实现这一目的。Pagurus 包括一个函数内管理器，用于将闲置的热容器替换成其他函数可以使用的容器，而不引入额外的安全问题；一个函数间调度器，用于在函数间调度容器；以及一个集群级的共享感知函数平衡器，用于平衡不同节点的工作负载。使用 Azure 无服务器追踪的实验表明，Pagurus 减轻了 84.6% 的冷启动，如果减轻了冷启动延迟，则从数百毫秒减少到 16 毫秒。\n\n##### 3.Tetris: Memory-efficient Serverless Inference through Tensor Sharing\n\n执行复杂的、内存密集型的深度学习推理服务对无服务器计算框架是一个重大挑战，它将密集地部署和维护推理模型的高吞吐量。我们观察到无服务器推理系统中由于大尺寸模型和高数据冗余而导致的过度内存消耗问题。\n\n我们提出了 Tetris，这是一个迎合推理服务的无服务器平台，它的内存占用率要低一个数量级。Tetris 的设计仔细考虑了运行时和张量的广泛内存共享。它支持通过批处理和并发执行的组合优化来最小化运行时冗余，并使用轻量级和安全的张量映射机制来消除来自相同或不同函数的实例之间的张量冗余。我们的综合评估表明，Tetris 为推理服务节省了高达 93% 的内存占用，并在不影响延迟的情况下将函数密度提高了 30 倍。\n\n#### 2021\n\n\u003e 2021.7.14-7.16\n\n##### 1.SONIC: Application-aware Data Passing for Chained Serverless Applications \n\n**摘要：**\n\n数据分析应用程序越来越多地利用无服务器执行环境，因为它们易于使用，而且随用随付。这类应用的结构通常由多个函数组成，这些函数被串联起来形成一个工作流。**当前在函数之间交换中间（临时）数据的方法是通过远程存储（例如 S3），这会引入显着的性能开销**。我们比较了**三种数据传递方法**，我们称之为 VM-Storage、Direct-Passing 和 state-of-practice Remote-Storage。至关重要的是，我们表明，没有一种单一的数据传递方法在所有场景下都占主导地位，最优选择取决于动态因素，例如输入数据的大小、中间数据的大小、应用程序的并行度和网络带宽。我们提出了 **SONIC，一种优化应用程序性能和成本的数据传递管理器，通过为无服务器工作流 DAG 的每个边缘透明地选择最佳数据传递方法并实现通信感知函数放置。SONIC 监控应用程序参数并使用简单的回归模型来相应地调整其混合数据传递。**我们将 SONIC 与 Open-Lambda 集成，并使用在无服务器环境中流行的三个分析应用程序评估 Amazon EC2 上的系统。与四个基准相比，SONIC 在各种条件下提供更低的延迟（原始性能）和更高的性能/美元：SAND、vanilla OpenLambda、OpenLambda with Pocket 和 AWS Lambda。\n\n【以上三种方法在文件大小，并行度、网络带宽不同的情况下分别是最优方法，优先考虑 VM，不可行或牺牲并行性的情况下考虑另外两种，如果并行度低，网络带宽小考虑直接传输，并行度高、网络带宽大考虑远程调用。】\n\n##### 2.FaaSNet: Scalable and Fast Provisioning of Custom Serverless Container Runtimes at Alibaba Cloud Function Compute \n\n**摘要：**\n\n无服务器计算或函数即服务 (FaaS) 通过允许用户部署细粒度函数，同时提供完全托管的资源配置和自动扩展，实现了一种构建和扩展应用程序的新方式。自定义 FaaS 容器支持越来越受欢迎，因为它可以更好地控制操作系统、版本控制和工具，以实现 FaaS 应用程序的现代化。然而，**提供快速的容器配置给 FaaS 提供商带来了不小的挑战，因为容器配置成本高昂，而且现实世界的 FaaS 工作负载表现出高度动态的模式**。\n\n在本文中，我们设计了 FaaSNet，这是一个用于加速 FaaS 容器配置的高度可扩展的中间件系统。 **FaaSNet 由全球最大的云提供商之一阿里云函数计算的 FaaS 平台的工作负载和基础设施要求驱动**。**FaaSNet 通过轻量级的自适应函数树 (FT) 结构实现可扩展的容器配置。FaaSNet 使用高效的 I/O 按需获取机制来进一步大规模降低配置成本**。我们在阿里云函数计算中实现并集成了 FaaSNet。评估结果表明，FaaSNet：（1）在 8.3 秒内完成在 1000 个虚拟机上配置 2500 个函数容器，（2）扩展速度比阿里云当前的 FaaS 平台和最先进的 P2P 容器注册中心 (Kraken) 快 13.4 倍和 16.3 倍 和 (3) 维持突发工作负载的时间比优化基线少 75.2%。\n\n##### 3.Faastlane: Accelerating Function-as-a-Service Workflows \n\n**摘要：**\n\n在 FaaS 工作流中，一组函数通过相互交互和交换数据来实现应用程序逻辑。现代 FaaS 平台在单独的容器中执行工作流的每个函数。**当工作流中的函数交互时，产生的延迟会减慢执行速度。**\n\n**Faastlane 通过努力将工作流的函数作为线程在容器实例的单一进程中执行，从而最大限度地减少了函数交互延迟，这通过简单的加载/存储指令简化了数据共享**。对于操作**敏感数据的 FaaS 工作流，Faastlane 使用英特尔内存保护密钥（MPK）提供轻量级的线程级隔离域**。虽然线程便于共享，但 Python 和 Node.js 等语言的实现（广泛用于 FaaS 应用程序）不允许线程的并发执行。Faastlane 动态地识别 FaaS 工作流中的并行机会，分叉进程（而不是线程）或产生新的容器实例，以并发执行工作流的并行函数。\n\n我们在 Apache OpenWhisk 上实现了 Faastlane，并表明它将工作流实例的速度提高了 15 倍，与 OpenWhisk 相比，将函数交互延迟降低了 99.95%。\n\n#### 2020\n\n\u003e 2020.7.15-7.17\n\n##### 1.Serverless in the Wild: Characterizing and Optimizing the Serverless Workload at a Large Cloud Provider \n\n**摘要：**\n\n函数即服务（FaaS）作为一种在云中向无服务器后端部署计算的方式，已经越来越受欢迎。这种模式将分配和配置资源的复杂性转移给了云提供商，**云提供商必须以尽可能低的资源成本提供永远可用的资源的假象（即没有冷启动的快速函数调用）**。这样做需要供应商深入了解 FaaS 工作负载的特点。不幸的是，关于这些特征的公开信息几乎没有。因此，在本文中，我们**首先描述了 Azure Functions 的整个生产型 FaaS 工作负载的特点**。我们举例说明，大多数函数被调用的频率很低，但调用频率有 8 个数量级的范围。通过观察我们的特征，我们**提出了一个实用的资源管理策略，该策略可以大大减少函数冷启动的次数，同时花费的资源也比现行的策略少**。\n\n##### 2.Faasm: Lightweight Isolation for Efficient Stateful Serverless Computing \n\n**摘要：**\n\n无服务器计算非常适用于大数据处理，因为它可以快速而廉价地扩展到成千上万的并行函数。**现有的无服务器平台将函数隔离在短暂的、无状态的容器中，防止它们直接共享内存。这迫使用户反复复制和序列化数据，增加了不必要的性能和资源成本**。我们认为需要一种新的轻量级隔离方法，它支持函数之间直接共享内存，并减少资源开销。\n\n我们介绍了**Faaslets，这是一种用于高性能无服务器计算的新隔离抽象。Faaslets 使用 WebAssembly 提供的 \\emph{software-fault isolation} (SFI) 隔离已执行函数的内存，同时允许内存区域在同一地址空间的函数之间共享。因此，当函数在同一台机器上共存时，Faaslets 可以避免昂贵的数据移动。**我们的 Faaslets 的运行时间 Faasm 使用标准的 Linux cgroups 隔离其他资源，例如 CPU 和网络，并为网络、文件系统访问和动态加载提供低级别的 POSIX 主机接口。**为了减少初始化时间，Faasm 从已经初始化的快照中恢复 Faaslets**。我们将 Faasm 与一个标准的基于容器的平台进行了比较，结果表明，在训练机器学习模型时，它实现了 2 倍的加速，同时内存减少了 10 倍；为了服务于机器学习推理，Faasm 将吞吐量翻了一番，并将尾部延迟降低了 90%。\n\n\u003e 原文摘要就是 \\emph{software-fault isolation} (SFI) \n\n#### 2018\n\n\u003e 2019 年没有和 serverless 相关的内容\n\u003e\n\u003e 2018.7.11-7.13\n\n##### 1.SOCK: Rapid Task Provisioning with Serverless-Optimized Containers \n\n无服务器计算承诺为应用程序提供成本节约和极致弹性。不幸的是，缓慢的应用和**容器初始化会损害无服务器平台上的常见延迟**。在这项工作中，我们**分析了 Linux 容器原语，确定了与存储和网络隔离有关的可扩展性瓶颈。我们还分析了 GitHub 上的 Python 应用程序，并表明导入许多流行的库会使启动时间增加约 100ms**。基于这些发现，我们实现了**SOCK，一个为无服务器工作负载优化的容器系统**。小心避免了内核的可扩展性瓶颈，使 SOCK 的速度比 Docker 提高了 18 倍。一个广义的 Zygote 配置策略产生了额外的 3 倍速度。基于 Zygotes 的更复杂的三层缓存策略使 SOCK 的速度比没有 Zygotes 的 SOCK 提高了 45 倍。相对于 AWS Lambda 和 OpenWhisk，在一个图像处理案例研究中，带有 SOCK 的 OpenLambda 分别减少了 2.8 倍和 5.3 倍的平台开销。\n\n##### 2.Peeking Behind the Curtains of Serverless Platforms\n\n无服务器计算是一种新兴的范式，其中应用程序的资源配置和扩展由第三方服务管理。例子包括 AWS Lambda、Azure Functions 和 Google Cloud Functions。**在这些服务易于使用的 API 背后是不透明的、复杂的基础设施和管理生态系统**。我们从无服务器**客户的角度**出发，进行了迄今为止最大规模的测量研究，在这三种服务中启动了超过 5 万个函数实例，以描述其架构、性能和资源管理效率。我们解释了这些平台如何使用虚拟机或容器来隔离不同账户的函数，这具有重要的安全意义。我们**从可扩展性、冷启动延迟和资源效率等方面来描述性能**，重点包括 AWS Lambda 采用类似 bin-packing 的策略来最大化虚拟机的内存利用率，在 AWS 和 Azure 中可能出现函数之间的严重争用，以及谷歌有允许客户免费使用资源的 bug。\n\n##### 3.Understanding Ephemeral Storage for Serverless Analytics \n\n无服务器计算框架允许用户以高弹性和细粒度的资源计费启动数千个并发任务，而无需显式管理计算资源。虽然在物联网和网络微服务方面已经取得了成功，但人们对利用无服务器计算来运行**数据密集型工作**（如交互式分析）的兴趣越来越大。在**无服务器平台上运行分析工作负载的一个关键挑战是使不同执行阶段的任务能够通过共享数据存储在彼此之间有效地交流数据**。在本文中，我们**探讨了不同的云存储服务（如对象存储和分布式缓存）作为无服务器分析的远程存储的适用性**。我们的分析得出了指导无服务器云存储系统设计的关键见解，包括 Flash 存储的性能和成本效益，以满足无服务器应用的要求，以及需要一种按需付费的存储服务，以支持高度并行应用的高吞吐需求。\n\n##### 4.SAND: Towards High-Performance Serverless Computing \n\n无服务器计算已经成为一种新的云计算范式，在这种范式中，一个应用由可以单独管理和执行的各个函数组成。然而，**现有的无服务器平台通常在独立的容器中隔离和执行函数，并不利用函数之间的相互作用来提高性能**。这些做法导致了函数执行的高启动延迟和低效的资源使用。本文介绍了 SAND，一个新的无服务器计算系统，它**比现有的无服务器平台具有更低的延迟、更好的资源效率和更大的弹性**。为了实现这些特性，**SAND 引入了两项关键技术。1）应用层面的沙箱 2）分层的消息总线。**我们已经实现并部署了一个完整的 SAND 系统。我们的结果表明，SAND 的性能明显优于最先进的无服务器平台。例如，在一个常用的图像处理应用中，与 Apache OpenWhisk 相比，SAND 实现了 43% 的速度提升。\n\n### ISCA\n\n#### 2023\n\n##### 1.MXFaaS: Resource Sharing in Serverless Environments for Parallelism and Efficiency\n\n**摘要：**\n\n虽然无服务器计算是一种流行的模式，但目前的无服务器环境开销很大。最近的研究表明，**无服务器工作负载经常出现同一函数的突发调用。目前的平台无法很好地处理这种模式。**有效支持这种模式可以大大加快无服务器的执行速度。\n\n在本文中，我们针对这种主流模式设计了一种名为 MXFaaS 的新型无服务器平台。**MXFaaS 通过在并发执行的同一函数调用之间有效地复用（即共享）处理器周期、I/O 带宽和内存/处理器状态来提高函数性能**。MXFaaS 引入了一种名为 MXContainer 的新容器抽象。为了有效利用处理器周期，MXContainer 会精心帮助调度相同功能的调用，以尽量缩短响应时间。为了有效利用 I/O 带宽，MXContainer 会将远程存储访问和远程函数调用从相同函数调用中合并起来。最后，为了有效利用内存/处理器状态，MXContainer 首先初始化其容器的状态，然后才根据需要为每次函数调用生成一个进程，这样所有调用都能共享未修改的内存状态，从而最大限度地减少内存占用。\n\n我们在两个无服务器平台上实施了MXFaaS，并运行了多种无服务器基准测试。有了MXFaaS，无服务器环境的效率大大提高。与最先进的无服务器环境相比，MXFaaS平均将执行速度提高了5.2倍，将P99尾延迟降低了7.4倍，将吞吐量提高了4.8倍。此外，它还将平均内存使用量降低了 3.4 倍。\n#### 2021\n\n\u003e 2021.6.14-6-18\n\n##### 1.Confidential Serverless Made Efficient with Plug-In Enclaves \n\n**摘要：**\n\n无服务器计算已经成为现代云计算中的一个事实。无服务器函数可能会处理来自客户端的敏感数据。**使用硬件 enclave 保护这样的函数不受不信任的云的影响，对用户的隐私有吸引力**。在这项工作中，我们在 SGX enclave 中运行现有的无服务器应用程序，并观察到**性能下降**可高达 5.6 倍，甚至 422.6 倍。我们的调查发现，这些减速与架构特征有关，主要来自于分页的 enclave 初始化。利用我们对开销分析的洞察力，我们重新审视了 SGX 的硬件设计，并对其 enclave 模型做了最小的修改。我们用一个新的基元 - 区域 - 插件 enclave 来扩展 SGX，这些 enclave 可以被映射到现有的 enclave 中，以重用各函数之间已被证实的共同状态。通过重新映射插件 enclave，enclave 允许就地处理，以避免函数链中昂贵的数据移动。实验表明，我们的设计将飞地函数的延迟降低了 94.74-99.57%，并将自动缩放的吞吐量提高了 19-179 倍。\n\n### FAST\n\n#### 2020\n\n##### 1.InfiniCache: Exploiting Ephemeral Serverless Functions to Build a Cost-Effective Memory Cache\n\n**摘要：**\n\n互联网规模的网络应用正变得越来越存储密集，并在很大程度上依赖于内存中的对象缓存以达到所需的 I/O 性能。我们认为，新兴的无服务器计算范式为对象缓存提供了一个非常合适的、具有成本效益的平台。我们提出了 InfiniCache，这是第一个完全建立并部署在无服务器函数之上的内存中对象缓存系统。InfiniCache 利用并协调了无服务器函数的内存资源，以实现弹性的按使用量付费的缓存。InfiniCache 的设计结合了擦除编码、智能计费持续时间控制和高效的数据备份机制，以最大化数据可用性和成本效益，同时平衡丢失缓存状态和性能的风险。我们在 AWS Lambda 上实现了 InfiniCache，并表明它。(1) 与 AWS ElastiCache 相比，在仅有大对象的生产工作负载中，实现了 31-96 倍的租户方成本节约，(2) 可以有效地在每个一小时的窗口中提供 95.4% 的数据可用性，(3) 实现了典型内存缓存中看到的比较性能。\n\n### FSE/ESEC\n\n#### 2021\n\n\u003e 2021.8.23-28\n\n##### 1.An empirical study on challenges of application development in serverless computing \n\n**摘要：**\n\n无服务器计算是一种新兴的云计算范式，在视频处理和机器学习等广泛的应用中获得了关注。这种新范式可以让开发者在函数的粒度上专注于基于 serverless 计算的应用（简称 serverless-based applications）的逻辑开发，从而将开发者从繁琐且容易出错的基础设施管理中解放出来。同时，也给基于 serverless 的应用的设计、实现和部署带来了新的挑战，目前的 serverless 计算平台还远远不能令人满意。然而，据我们所知，这些挑战尚未得到很好的研究。为了填补这一知识空白，**本文首次全面研究了从开发人员的角度理解开发基于无服务器的应用程序所面临的挑战。我们从 Stack Overflow（开发者热门问答网站）中挖掘和分析了 22,731 个相关问题，展示了无服务器计算的日益流行趋势和开发者的高难度水平。**通过对 619 个抽样问题的人工检查，我们构建了开发人员遇到的挑战的分类，并报告了一系列发现和可操作的含义。包括应用程序开发人员、研究人员和云提供商在内的利益相关者可以利用这些发现和影响来更好地理解和进一步探索无服务器计算范式。\n\n##### 2.Automating serverless deployments for DevOps organizations \n\n**摘要：**\n\nDevOps 在跨职能团队中统一软件开发和运营，以提高软件交付和运营 (SDO) 性能。理想情况下，跨职能的 DevOps 团队独立部署他们的服务，但一个服务的正确运行往往需要其他服务，需要协调以确保正确的部署顺序。此问题目前通过集中部署或跨团队的手动带外通信（例如，通过电话、聊天或电子邮件）来解决。不幸的是，两者都与团队的独立性相矛盾，阻碍了 SDO 的性能——这也是 DevOps 最初被采用的原因。 \n\n在这项工作中，我们对 73 位 IT 专业人员进行了一项研究，结果表明，在实践中，即使他们希望通过完全自动化的方法获得更好的 SDO 性能，他们也会通过手动协调来进行正确的部署。**为了解决这个问题，我们提出了 µs ([mju:z] “muse”)，这是一种新颖的 IaC 系统，以完全去中心化的方式自动化部署协调，与今天的解决方案相比，仍然保持与 DevOps 实践的兼容性。**我们实现了 µs，证明它有效地实现了自动化协调，引入了可忽略的定义开销，没有性能开销，并且广泛适用，如 64 个第三方 IaC 项目的迁移所示。\n\n### SOSP\n\n#### 2023\n\n##### 1.XFaaS: Hyperscale and Low Cost Serverless Functions at Meta\n\n**摘要：**\n\n函数即服务（FaaS）已成为无服务器计算（Serverless Computing）中一种流行的编程范式。随着资源配置的责任从用户转移到云提供商，**FaaS 对用户的易用性可能会以云提供商的额外硬件成本为代价**。目前，还没有关于 FaaS 平台如何应对这一挑战及其实现的硬件利用水平的报告。\n\n本文介绍了 Meta 超大规模私有云中名为 XFaaS 的 FaaS 平台。XFaaS 目前每天在 10 万多台服务器上处理数万亿次函数调用。我们介绍了一系列优化措施，这些措施**帮助 XFaaS 实现了日均 66% 的 CPU 利用率**。根据我们的经验，这一利用率水平可能比典型的 FaaS 平台高出数倍。\n\n具体来说，为了消除函数的冷启动时间，**XFaaS 努力做到每个工作者都能立即执行每个函数。为了在不过度配置资源的情况下处理负载峰值，XFaaS 将延迟容错功能的执行时间推迟到非高峰时段，并在数据中心区域内全局调度功能调用。为防止函数超载下游服务，XFaaS 使用类似 TCP 的拥塞控制机制来加快函数的执行速度。** \n\n#### 2021\n\n\u003e 2021.10.26-29\n\n##### 1.Boki: Stateful Serverless Computing with Shared Logs \n\n**摘要：**\n\n**Boki 是一个新的无服务器运行时，它将共享日志 API 导出到无服务器函数。Boki 共享日志使有状态的无服务器应用程序能够以持久性、一致性和容错性来管理其状态**。Boki 共享日志实现了高吞吐量和低延迟。关键促成因素是 **metalog，这是一种允许 Boki 独立处理排序、一致性和容错的新机制**。metallog 以高吞吐量对共享日志记录进行排序，并提供读取一致性，同时允许服务提供商以不同方式优化共享日志的写入和读取路径。为了展示共享日志对有状态无服务器应用程序的价值，我们构建了 Boki 支持库来实现容错工作流、持久对象存储和消息队列。我们的评估表明，共享日志可以将重要的无服务器工作负载加速高达 4.7 倍。\n\n##### 2.Faster and Cheaper Serverless Computing on Harvested Resources \n\n**摘要：**\n\n无服务器计算因其易于编程、快速弹性和细粒度计费而变得越来越流行。但是，无服务器提供商仍需要为托管其平台的虚拟机 (VM) 配置、管理和支付 IaaS 提供商的费用。这将无服务器平台的成本与底层虚拟机的成本联系在一起。显着降低成本的一种方法是使用备用资源，云供应商以大幅折扣租用这些资源。 **Harvest VM 提供了如此廉价的资源：它们会增长和缩小以获取主机服务器中所有未分配的 CPU 内核，但可能会被驱逐以腾出空间容纳更昂贵的 VM**。因此，使用 Harvest VM 运行无服务器平台会带来两个必须小心管理的主要挑战：VM 驱逐和每个 VM 中动态变化的资源。\n\n在这项工作中，**我们探讨了在 Harvest VM 上托管无服务器（函数即服务或简称 FaaS）平台的挑战和好处。我们描述了 Microsoft Azure 的无服务器工作负载和 Harvest VM，并设计了一个无服务器负载均衡器，它可以感知 Harvest VM 中的驱逐和资源变化。我们修改了广泛使用的开源无服务器平台 OpenWhisk，以监控收获的资源并相应地平衡负载，并对其进行实验评估**。我们的结果表明，采用收获的资源可以提高效率并降低成本。在相同的成本预算下，与使用专用资源相比，在收获的资源上运行无服务器平台可实现 2.2 到 9.0 倍的吞吐量。在使用相同数量的资源时，由于更好的负载平衡，在收获的资源上运行无服务器平台可以节省 48% 到 89% 的成本，同时延迟更低。\n\n##### 3.FlashCube: Fast Provisioning of Serverless Functions with Streamlined Container Runtimes  \n\n**摘要：**\n\n无服务器函数的快速配置对于无服务器平台来说非常重要。**尽管轻量级沙箱（例如容器）仅包含必要的文件和库，但冷启动仍需要最多几秒钟才能完成。这种缓慢的配置会延长无服务器函数的响应时间，并对用户体验产生负面影响**。**本文分析了这种放缓的主要原因，并介绍了一个有效的容器化框架 FlashCube。FlashCube 不是从头开始构建容器，而是通过一组预先创建的通用容器部件（例如，命名空间、cgroup 和语言运行时）快速有效地组装它**。此外，FlashCube 的用户空间实现使其轻松适用于现有的商品无服务器平台。我们的初步评估表明，FlashCube 可以在不到 10 毫秒的时间内快速配置容器化函数（而使用 Docker 容器的时间约为 400 毫秒）。\n\n### OSDI\n\n#### 2023\n\n##### 1.Automated Verification of Idempotence for Stateful Serverless Applications\n\n**摘要：**\n\n无服务器计算已成为一种流行的云计算模式。默认情况下，当一个无服务器函数失败时，无服务器平台会重新执行该函数以容忍失败。然而，**这种基于重试的方法要求函数具有幂等性，这意味着无论重试与否，函数都应暴露相同的行为** 。这一要求对开发人员来说具有挑战性，尤其是当函数是有状态的时候。故障可能会导致函数重复读取和更新共享状态，从而破坏数据的一致性。\n\n本文介绍了 Flux，这是第一个自动验证无服务器应用程序幂等性的工具包。它提出了一个新的正确性定义--empotence一致性，规定无服务器函数的重试对用户是透明的。为了验证幂等一致性，Flux 定义了一种新特性--幂等模拟，它将并发无服务器应用程序的证明分解为单个函数的推理。此外，Flux 还扩展了现有的验证技术，实现了自动推理，使 Flux 能够识别违反幂等性的操作，并通过现有的基于日志的方法修复它们。\n\n我们用 27 个具有代表性的无服务器应用程序演示了 Flux 的功效。Flux 在 12 个应用中成功识别了以前未知的问题。开发人员确认了 8 个问题。与记录所有操作的最先进系统（即 Beldi 和 Boki）相比，Flux 的延迟降低了 6 倍，峰值吞吐量提高了 10 倍，因为它只记录已识别出的违反幂等性的操作。\n\n#### 2021\n\n\u003e 2021.07.14-16\n\n##### 1.Dorylus: Affordable, Scalable, and Accurate GNN Training with Distributed CPU Servers and Serverless Threads \n\n**摘要：**\n\n图神经网络 (GNN) 支持对结构化图数据进行深度学习。有两个主要的 GNN 训练障碍：1）它依赖于具有许多 GPU 的高端服务器，这些 GPU 的购买和维护成本很高，以及 2）GPU 上有限的内存无法扩展到当今的十亿边图。**本文介绍了 Dorylus：一种用于训练 GNN 的分布式系统。独特的是，Dorylus 可以利用无服务器计算以低成本提高可扩展性。 **\n\n指导我们设计的关键见解是**计算分离**。计算分离使得构建一个深度的、有界的异步管道成为可能，其中图和张量并行任务可以完全重叠，有效地隐藏了 Lambdas 引起的网络延迟。在数千个 Lambda 线程的帮助下，Dorylus 将 GNN 训练扩展到十亿边图。目前，**对于大型图，CPU 服务器提供的每美元性能优于 GPU 服务器。与仅使用 CPU 服务器进行训练相比，仅在 CPU 服务器上使用 Lambda 可提供高达 2.75✕ 的每美元性能**。具体来说，对于海量稀疏图，Dorylus 比 GPU 服务器快 1.22✕，便宜 4.83✕。与现有的基于采样的系统相比，Dorylus 的速度提高了 3.8✕，成本降低了 10.7✕。\n\n#### 2020\n\n\u003e 2020.11.04-06\n\n##### 1.Fault-tolerant and transactional stateful serverless workflows \n\n**摘要：**\n\n**本文介绍了 Beldi，这是一个用于编写和组合容错和事务有状态无服务器函数的库和运行时系统。** Beldi \n在现有提供商上运行，允许开发人员编写需要容错和事务语义的复杂有状态应用程序，而无需处理负载\n平衡或维护虚拟机等任务。Beldi 的贡献包括使用新的数据结构、事务协议、函数调用和垃圾收集扩展 \nOlive (OSDI 2016) 中基于日志的容错方法。它们还包括调整生成的框架以在每个无服务器函数对其自己\n的数据拥有主权的联合环境中工作。我们在 Beldi 上实现了三个应用程序，包括电影评论服务、旅行预\n订系统和社交媒体网站。我们对 1,000 个 AWS Lambda 的评估表明，Beldi 的方法有效且经济实惠。\n\n#### 2018\n\n\u003e 2018.10.08-10\n\n##### 1.Pocket: Elastic Ephemeral Storage for Serverless Analytics\n\n**摘要：**\n\n**本文介绍了 Pocket，一个用于在 serverless 场景下存储中间数据的高性能分布式存储系统。**无服务器计算（Serverless computing）正变得越来越受欢迎，它可以让用户快速在云中启动成千上万个短暂任务，具有高度弹性和细粒度计费的特点。这些属性使得无服务器计算在交互式数据分析方面具有吸引力。然而，在分析作业的执行阶段之间交换中间数据是一个关键的挑战，因为无服务器任务之间的直接通信很困难。自然的方法是将这些短暂数据存储在远程数据存储中。然而，现有的存储系统在弹性、性能和成本方面并不适合无服务器应用程序的需求。我们介绍了Pocket，一种弹性分布式数据存储系统，它可以自动缩放以以低成本提供应用所需的性能。Pocket在多个维度（CPU核数、网络带宽、存储容量）上动态地调整资源，并利用多种存储技术来最小化成本，同时确保应用程序在I/O方面不会成为瓶颈。我们展示了Pocket在无服务器数据分析应用程序方面实现了类似于ElastiCache Redis的性能，同时将成本降低了近60%。\n\n### NSDI\n\n#### 2021\n\n##### 1.Caerus: NIMBLE Task Scheduling for Serverless Analytics\n\n**摘要：**\n\n无服务器平台促进了透明的资源弹性和细粒度的计费，使其成为数据分析的一个有吸引力的选择。我们发现，以服务器为中心的分析框架通常通过作业间调度策略来优化作业完成时间（JCT）、资源利用率和隔离度，而**无服务器分析则需要对 JCT 和执行成本进行优化，从而引入了一个新的调度问题**。我们提出了**Caerus，一个用于无服务器分析框架的任务调度器，它采用了细粒度的 NIMBLE 调度算法来解决**这个问题。NIMBLE 在工作中有效地对任务执行进行管道化，使执行成本最小化，同时在任意分析工作的成本和 JCT 之间达到帕累托最优。为此，NIMBLE 建立了广泛的执行参数模型----可管道和不可管道的数据依赖关系、数据生成、消耗和处理率等。--- 以确定理想的任务启动时间。我们的评估结果表明，在实践中，Caerus 能够为各种分析工作负载的查询实现最佳成本和 JCT。\n\n#### 2020\n\n##### 1.Firecracker: Lightweight Virtualization for Serverless Applications\n\n**摘要：**\n\n无服务器容器和函数被广泛用于在云中部署和管理软件。它们的流行是由于降低了运营成本，提高了硬件的利用率，以及比传统部署方法更快的扩展性。无服务器应用的经济性和规模要求来自多个客户的工作负载在同一硬件上运行，开销最小，同时保持强大的安全性和性能隔离。传统观点认为，可以在安全性强、开销大的虚拟化和安全性弱、开销小的容器技术之间做出选择。这种权衡对公共基础设施供应商来说是不可接受的，他们既需要强大的安全性，又需要最小的开销。为了满足这一需求，我们开发了**Firecracker，这是一个新的开源虚拟机监控器（VMM）**，专门用于无服务器工作负载，但在合理的约束条件下，一般对容器、函数和其他计算工作负载有用。我们已经在 AWS 的两个公开的无服务器计算服务（Lambda 和 Fargate）中部署了 Firecracker，它支持数百万的生产工作负载，每月有数万亿的请求。我们描述了无服务器的专业性如何影响了 Firecracker 的设计，以及我们从将 AWS Lambda 客户无缝迁移到 Firecracker 中所学到的东西。\n\n#### 2019\n\n##### 1.Shuffling, Fast and Slow: Scalable Analytics on Serverless Infrastructure\n\n**摘要：**\n\n无服务器计算正准备实现透明弹性和毫秒级定价的长期承诺。为了实现这一目标，服务提供商强加了一个细粒度的计算模型，每个函数都有一个最大的持续时间，有固定的内存量，没有持久的本地存储。我们观察到，**无服务器的细粒度弹性是实现一般计算（如分析工作负载）高利用率的关键，但由于资源限制，这类应用需要在时间上不重叠的函数之间移动大量数据，因此实施起来很有挑战性**。在本文中，我们介绍了 Locus，一个无服务器的分析系统，它将（1）廉价但缓慢的存储与（2）快速但昂贵的存储明智地结合起来，以实现良好的性能，同时保持成本效益。**Locus 应用一个性能模型来指导用户选择存储的类型和数量，以实现理想的成本 - 性能权衡**。我们在一些分析应用上评估了 Locus，包括 TPC-DS、CloudSort、Big Data Benchmark，并表明 Locus 可以驾驭性价比的权衡，与仅有慢速存储的基线相比，性能提高了 4 倍 -500 倍，减少了高达 59% 的资源使用，同时在一个虚拟机集群上实现了相当的性能，与 Redshift 相比，慢了 1.99 倍。\n\n### VLDB\n\n#### 2020\n\n##### 1.Cloudburst: Stateful Functions-as-a-Service\n\n**摘要：**\n\n函数即服务（FaaS）平台和 \"无服务器 \"云计算正变得越来越流行。目前的 FaaS 产品针对的是无状态函数，这些函数做最小的 I/O 和通信。我们认为，无服务器计算的好处可以扩展到更广泛的应用和算法。我们介绍了**Cloudburst 的设计和实现，这是一个有状态的 FaaS 平台**，提供熟悉的 Python 编程，具有低延迟的可变状态和通信，同时保持无服务器计算的自动扩展优势。Cloudburst 通过利用 Anna（一个自动扩展的键值存储）来实现这一目标，该存储用于状态共享和叠加路由，并与函数执行器共同定位的可变缓存来实现数据定位。性能良好的缓存一致性是该架构的一个关键挑战。为此，Cloudburst 为分布式会话一致性提供了格子封装的状态和新的定义及协议的组合。基准测试和各种应用的实证结果表明，Cloudburst 使有状态的函数变得实用，将当前 FaaS 平台的状态管理开销降低了几个数量级，同时也改善了无服务器一致性方面的技术水平。\n\n#### 2019\n\n##### 1.Stateful Functions as a Service in Action\n\n**摘要：**\n\n在无服务器模式中，用户将应用代码上传到云平台，云提供商承担应用的部署、执行和扩展，将用户从所有操作环节中解脱出来。尽管非常流行，但目前的无服务器产品对本地应用状态的管理提供了很差的支持，主要原因是管理状态并在大规模下保持一致是非常具有挑战性的。因此，**无服务器模型对于执行有状态的、延迟敏感的应用来说是不够的**。在本文中，我们提出了一个高层次的编程模型，用于开发有状态的函数并将其部署在云中。我们的编程模型允许函数保留状态以及调用其他函数。为了在云基础设施中部署有状态的函数，我们将函数和它们的数据交换转换为有状态的数据流图。通过这篇论文，我们旨在证明使用一个开源数据流引擎的修改版作为有状态函数的运行时间，我们可以在云中部署可扩展和有状态的服务，并具有令人惊讶的低延迟和高吞吐量。\n\n### INFOCOM\n\n#### 2022\n\n##### 1.StepConf: SLO-Aware Dynamic Resource Configuration for Serverless Function Workflows \n\n**摘要：**\n\n函数即服务 (FaaS) 提供了细粒度的资源供应模型，使开发人员能够构建高度弹性的云应用程序。用户请求由一系列 serverless 函数一步步处理，形成基于函数的工作流。开发人员需要为功能设置适当的资源配置，以满足服务水平目标（SLO）并节省成本。然而，开发资源配置策略具有挑战性。这主要是**因为云函数的执行经常会遇到冷启动和性能波动，这需要动态配置策略来保证 SLO。在本文中，我们介绍了 StepConf，这是一个框架，可在工作流运行时自动执行功能的资源配置。StepConf 优化了工作流中每个函数步骤的内存大小，并考虑了函数间和函数内的并行性。** 我们在 AWS Lambda 上评估 StepConf。与基线相比，实验结果表明 StepConf 在保证 SLO 的同时可以节省高达 40.9% 的成本。\n\n##### 2.Retention-Aware Container Caching for Serverless Edge Computing\n\n无服务器边缘计算采用基于事件的模型——物联网(IoT)服务仅在被请求时才在轻量级容器中执行，这种策略可以有效的提高边缘资源利用率。不幸的是，容器的启动延迟极大地降低了物联网服务的响应能力。为了屏蔽这种延迟，容器cache需要保留资源，但是这会进一步降低资源效率。本文研究了无服务器边缘计算中感知保留的容器缓存问题。我们利用边缘平台的分布式和异构特性，并提出将容器缓存与请求分发一起优化。我们逐步揭示了这个联合优化问题可以映射到经典的滑雪租赁问题。我们首先提出了一种在线竞争算法，用于请求分布和容器缓存是基于一组精心设计的概率分布函数的情景。在此算法的基础上，我们提出了一种适用于一般情况的在线算法O-RDC，该算法通过机会分配请求的方式，将资源容量和网络延迟相结合。我们进行了大量的实验，以检查所提出的算法的性能，包括合成和真实的无服务器计算轨迹。我们的结果表明，就整体系统成本而言，ORDC优于当前无服务器计算平台的现有缓存策略，最高可达94.5%。\n\n### EuroSys\n\n#### 2023\n\n##### 1.Palette Load Balancing: Locality Hints for Serverless Functions\n\n**摘要：**\n\n函数即服务（FaaS）无服务器计算实现了一种简单的编程模型，具有几乎无限的弹性。遗憾的是，**目前的 FaaS 平台实现这种灵活性的代价是，与有服务器部署相比，数据密集型应用的性能较低。让计算靠近数据的能力是一个关键的缺失功能**。我们引入了 Palette 负载均衡，它为 FaaS 应用程序提供了一种简单的机制，通过我们称之为 \"颜色 \"的提示，向平台表达本地性。**Palette 保持了服务的无服务器性质--用户仍然不分配资源--同时允许平台将相互关联的连续调用放在同一个执行节点上。**我们将 Palette 负载均衡器的原型与最先进的本地盲目负载均衡器进行了比较。对于带有本地缓存的无服务器 Web 应用程序，Palette 将命中率提高了 6 倍。对于无服务器版 Dask，Palette 在 Task Bench 和 TPC-H 上的运行时间分别提高了 46% 和 40%。在无服务器版 NumS 上，Palette 将运行时间缩短了 37%。这些改进在很大程度上缩小了相同系统有服务器实施的差距。\n\n##### 2.With Great Freedom Comes Great Opportunity: Rethinking Resource Allocation for Serverless Functions\n\n**摘要：**\n\n当前的无服务器产品为用户配置分配给其函数调用的资源提供了有限的灵活性。这虽然简化了用户部署无服务器计算的界面，但却造成了部署资源效率低下的问题。在本文中，**我们对无服务器函数的资源分配问题采取了一种原则性的方法，分析了以实现性能和成本最佳组合的方式自动做出这一选择的效果**。特别是，**我们系统地探索了解耦内存和 CPU 资源分配以及使用不同虚拟机类型所带来的机遇，并在性能和成本之间找到了丰富的权衡空间。**提供商可以通过多种方式利用这一点，例如，向用户公开所有这些参数；忽略用户对性能和成本的偏好，只提供相同的性能和较低的成本；或向用户公开少量选择，让用户以性能换成本。\n\n我们的研究结果表明，**通过解耦内存和 CPU 分配**，执行成本有可能比当前无服务器产品中常见的预设耦合配置低 40%。同样，正确选择虚拟机实例类型可使执行时间最多缩短 50%。此外，我们还证明，提供商可以灵活地为相同的功能选择不同的实例类型，以最大限度地提高资源利用率，同时为每个功能提供的性能不超过最佳资源配置的 10-20%。\n\n##### 3.Groundhog: Efficient Request Isolation in FaaS\n\n**摘要：**\n\n安全是函数即服务（FaaS）提供商的核心责任。**流行的方法是将函数的并发执行隔离在不同的容器中。然而，同一函数的连续调用通常会重复使用前一次调用的运行时状态，以避免容器冷启动延迟。**虽然效率很高，但这种容器重用对于代表不同权限用户或管理域调用的函数具有安全影响：函数实现中的漏洞（或其依赖的第三方库/运行时）可能会将一次函数调用中的私有数据泄露给后续调用。\n\nGroundhog **通过在每次调用后有效地恢复到干净的状态来隔离函数的连续调用，该状态不包含任何私人数据。**该系统利用了典型 FaaS 平台的两个特性：每个容器一次最多执行一个函数，合法函数不会在调用过程中保留状态。这使得 Groundhog 能够以独立于编程语言/运行时的方式在调用之间高效地快照和还原函数状态，而无需对现有函数、库、语言运行时或操作系统内核进行任何更改。我们介绍了 Groundhog 的设计与实现，以及它与 OpenWhisk（一种流行的生产级开源 FaaS 框架）的集成。在现有的三个基准套件中，相对于重用容器和运行时状态的不安全基线，Groundhog隔离了顺序调用，对端到端延迟（中位数：1.5%，95p：7%）和吞吐量（中位数：2.5%，95p：49.6%）的开销不大。\n\n#### 2022\n\n##### 1.Fireworks: a fast, efficient, and safe serverless framework using VM-level post-JIT snapshot\n\n**摘要：**\n\n无服务器计算是云计算领域迅速流行的一种新模式。无服务器计算的一个独特特性是，部署和执行的单位是一个无服务器函数，它比典型的服务器程序小得多。无服务器计算引入了一种新的 \"即用即付 \"计费模式，并通过高弹性的资源调配带来了较高的经济效益。然而，无服务器计算也带来了新的挑战，例如：（1）与相对较短的函数执行时间相比，启动时间较长；（2）高度整合环境带来的安全风险；（3）不可预测的函数调用带来的内存效率问题。这些问题不仅会降低性能，还会降低云提供商的经济效益。\n\n为了不折不扣地应对这些挑战，**我们提出了一种新颖的虚拟机级后 JIT 快照方法**，并开发了一种新的无服务器框架 Fireworks。我们的主要想法是**协同利用虚拟机（VM）级快照和语言运行时级即时编译（JIT）。Fireworks利用JIT无服务器函数代码来减少函数的启动时间和执行时间，并通过共享JIT代码来提高内存效率。**此外，**Fireworks 还能通过使用虚拟机作为沙箱来执行无服务器函数，从而提供高水平的隔离性**。我们的评估结果表明，Fireworks的性能比最先进的无服务器平台高出20.6倍，内存效率高达7.3倍。\n\n##### 2.Jiffy: elastic far-memory for stateful serverless analytics\n\n**摘要：**\n\n有状态无服务器分析可以使用远程内存系统来实现任务间通信，以及存储和交换中间数据。然而，现有系统是按任务粒度分配内存资源的--任务在提交时指定其内存需求；系统会在任务的整个生命周期内分配与任务需求相等的内存。**当中间数据大小在作业执行过程中发生变化时，这将导致资源利用不足和/或性能下降。**\n\n本文介绍了用于**有状态无服务器分析的弹性远端内存系统 Jiffy，它能满足作业在秒级时间尺度上的瞬时内存需求。Jiffy 在并发运行的作业中有效地复用内存容量，减少了对较慢的持久性存储的读写开销**，从而使作业执行时间比生产工作负载提高了 1.6-2.5 倍。Jiffy 目前在亚马逊 EC2 上运行，支持多种分布式编程模型，包括 MapReduce、Dryad、StreamScope 和 Piccolo，并在 AWS Lambda 上原生支持大量分析应用。\n\n##### 3.FaaSnap: FaaS made fast using snapshot-based VMs\n\n**摘要：**\n\n**FaaSnap 是一个基于虚拟机快照的平台，它使用一系列互补优化来提高功能即服务（FaaS）应用程序的冷启动性能**。紧凑型加载集文件能更好地利用预取。每区域内存映射可根据不同客户虚拟机内存区域的内容定制页面故障处理。分层重叠的内存映射区域简化了映射过程。并发分页允许客户虚拟机立即开始执行，而不是在加载工作集之前暂停。总之，**FaaSnap 显著减少了关键路径上的客户虚拟机页面故障处理时间，提高了整体函数加载性能**。无服务器基准测试表明，与最先进的技术相比，FaaSnap 可将端到端的函数执行速度最多降低 3.5 倍，平均仅比缓存在内存中的快照慢 3.5%。此外，我们还展示了 FaaSnap 对工作集变化的适应能力，在突发工作负载和快照位于远程存储时仍能保持高效。\n\n#### 2021\n\n\u003e 2021.426-4.28\n\n##### 1.OFC: an opportunistic caching system for FaaS platforms\n\n**摘要：**\n\n基于 \"函数即服务\"（FaaS）范式的云应用已经变得非常流行。然而，**由于它们的无状态性质，它们必须经常与外部数据存储互动，这限制了它们的性能**。为了缓解这个问题，我们引入了**OFC，一个透明的、垂直和水平弹性的内存缓存系统**，用于 FaaS 平台，分布在工作节点上。OFC 通过利用两种常见的资源浪费来源，以成本效益的方式提供这些好处。(i) 大多数云租户过度配置为其函数预留的内存资源，因为它们的足迹与输入无关；(ii) FaaS 供应商将函数沙箱保持几分钟，以避免冷启动。使用针对典型函数输入数据类别（如多媒体格式）调整的机器学习模型，OFC 估计每个函数调用所需的实际内存资源，并囤积剩余的容量以供给缓存。我们基于对 OpenWhisk FaaS 平台、Swift 持久性对象存储和 RAM-Cloud 内存存储的改进来建立我们的 OFC 原型。通过使用一组不同的工作负载，我们表明 OFC 可以将单级和流水线函数的执行时间分别提高 82% 和 60%。\n\n#### 2020\n\n##### 1.A fault-tolerance shim for serverless computing\n\n**摘要：**\n\n近年来，无服务器计算越来越受欢迎，越来越多的应用程序被构建在函数即服务（FaaS）平台上。默认情况下，**FaaS 平台支持基于重试的容错，但这对于修改共享状态的程序来说是不够的，因为它们会在不知不觉中坚持部分更新集，以防出现故障**。","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fpenghuima%2Fawesome-serverless-papers","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fpenghuima%2Fawesome-serverless-papers","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fpenghuima%2Fawesome-serverless-papers/lists"}