Architectural Implications of Function-as-a-Service Computing Mohammad Shahrad Jonathan Balkind David Wentzlaff Princeton University Princeton University Princeton University Princeton, USA Princeton, USA Princeton, USA [email protected] [email protected] [email protected] ABSTRACT Network Serverless computing is a rapidly growing cloud application model, popularized by Amazon’s Lambda platform. Serverless cloud ser- Scheduling vices provide fine-grained provisioning of resources, which scale Platform (priorwork) automatically with user demand. Function-as-a-Service (FaaS) appli- Queueing Management cations follow this serverless model, with the developer providing 35% decrease in IPC Interference their application as a set of functions which are executed in response due to interference 6x variation due to to a user- or system-generated event. Functions are designed to Memory BW invocation pattern 20x MPKI for be short-lived and execute inside containers or virtual machines, Branch MPKI >10x exec time short functions introducing a range of system-level overheads. This paper studies for short functions Cold Start Server the architectural implications of this emerging paradigm. Using (500ms cold start) Up to 20x (thispaper) Container the commercial-grade Apache OpenWhisk FaaS platform on real slowdown servers, this work investigates and identifies the architectural im- Native plications of FaaS serverless computing. The workloads, along with Execution Figure 1: We characterize the server-level overheads of the way that FaaS inherently interleaves short functions from many Function-as-a-Service applications, compared to native exe- tenants frustrates many of the locality-preserving architectural cution. This contrasts with prior work [2–5] which focused structures common in modern processors. In particular, we find on platform-level or end-to-end issues, relying heavily on that: FaaS containerization brings up to 20x slowdown compared reverse engineering of commercial services’ behavior. to native execution, cold-start can be over 10x a short function’s execution time, branch mispredictions per kilo-instruction are 20x higher for short functions, memory bandwidth increases by 6x due 1 INTRODUCTION to the invocation pattern, and IPC decreases by as much as 35% Serverless computing is a relatively new paradigm in cloud com- due to inter-function interference. We open-source FaaSProfiler, puting, first launched by Amazon’s AWS Lambda [1] in November the FaaS testing and profiling platform that we developed for this 2014. In serverless, the cloud provider manages the provisioning work. of resources for a service in a transparent, auto-scaling manner, without the developer in the loop. The developer is charged in a fine- CCS CONCEPTS grained way, proportional to the resources provisioned and used • Information systems → Enterprise resource planning; Com- per request, with no cost levied when the service is idle (receiving puting platforms; • Computer systems organization → Ar- no requests). chitectures. Function-as-a-Service (FaaS) is a key enabler of serverless com- puting. FaaS gets its name as it is a way to scale the execution KEYWORDS of simple, standalone, developer-written functions, where state is serverless, function-as-a-service, faas, cloud, OpenWhisk, architec- not kept across function invocations. Functions in FaaS are event- ture driven, invoked by a user’s HTTP request or another type of event created within the provider’s platform. To match the rate of func- ACM Reference Format: tion invocations, the platform automatically scales the resources Mohammad Shahrad, Jonathan Balkind, and David Wentzlaff. 2019. Ar- available to execute more instances of the developer’s function in chitectural Implications of Function-as-a-Service Computing. In The 52nd Annual IEEE/ACM International Symposium on Microarchitecture (MICRO- parallel. 52), October 12–16, 2019, Columbus, OH, USA. ACM, New York, NY, USA, The majority of serverless research has targeted mapping ap- 13 pages. https://doi.org/10.1145/3352460.3358296 plications to this model, or has focused on scheduling policies or mechanisms for orchestrating FaaS setups. However, we are inter- Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed ested to know if the computational building blocks of FaaS, namely, for profit or commercial advantage and that copies bear this notice and the full citation commodity servers used in modern cloud data centers are suitable on the first page. Copyrights for components of this work owned by others than the for such workloads. FaaS applications differ from traditional author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission cloud workloads in ways that may jeopardize common ar- and/or a fee. Request permissions from [email protected]. chitectural wisdom. MICRO-52, October 12–16, 2019, Columbus, OH, USA Firstly, FaaS functions are typically short-lived and priced in © 2019 Copyright held by the owner/author(s). Publication rights licensed to ACM. ACM ISBN 978-1-4503-6938-1/19/10...$15.00 multiples of a 1ms, 10ms, or 100ms time quantum. Function ex- https://doi.org/10.1145/3352460.3358296 ecution time is usually also capped. Providers must rely on the MICRO-52, October 12–16, 2019, Columbus, OH, USA Mohammad Shahrad, Jonathan Balkind, and David Wentzlaff fine-grained interleaving of many short functions to achieve high 2 BACKGROUND throughput. This fine-grained interleaving causes temporal The ideas behind serverless and FaaS have developed over a long locality-exploiting structures like branch predictors to un- period [7], but only formed into commercial services within the derperform, raising questions about present-day computer last few years. FaaS takes lessons from Infrastructure-as-a-Service architectures’ ability to execute FaaS efficiently. For instance, (IaaS), Platform-as-a-Service (PaaS), and microservices, but brings we observe a 20x increase in branch mispredictions per kilo-instruction with it completely new pricing, development, and provisioning (MPKI) when comparing our shortest functions to longer functions. models. This finding and others are shown in Figure 1. Secondly, functions often run in a deeply virtualized manner: 2.1 Differences with Other Cloud Models inside containers which might run within virtual machines. This FaaS is unlike traditional cloud models like IaaS and PaaS, and has causes a number of OS-level overheads. We find that flat overheads significant differences with newer models such as microservices like the cold start latency of 500ms or more have an outsized impact which have recently been thoroughly studied [8–10]. Differences on short functions. of FaaS from prior models include: Lastly, FaaS developers can write their functions in almost any • The FaaS developer does not provision or manage the servers language. Each platform has preferred languages, but developers that functions run on. This means there is no management may upload their own container to run a chosen application in of compute bottlenecks by developers. the FaaS environment. Together, these features make for a highly • Functions are abstracted from machine type. Most providers dynamic system, with many, fast-changing components, which we do not guarantee a machine type, nor do they price differen- have found bring new, unforeseen overheads and challenges for tially based on them. architectural optimization. • Functions are used to increase server utilization. As such, We provide the first server-level characterization of a Function- functions are often in contention with traditional applica- as-a-Service platform by carefully investigating a compute node of tions using the same server. an open-source FaaS platform, Apache OpenWhisk (sold commer- • FaaS is priced at a fine granularity, based on resource utiliza- cially as IBM Cloud Functions [6]). This contrasts with previous tion, not per API call. FaaS brings cloud computing closer to work solely focusing on black-box reverse-engineering of commer- a compute-as-utility model. cial FaaS systems [2–5]. With full control of our deployment, we • The developer is only charged for their function’s execution precisely induce function co-location and access hardware perfor- time based on memory usage. This ignores platform (e.g. mance counters, something impossible for an external black-box network, cluster-level scheduling, queuing) and system-level analysis. Our bottom-up approach enables us to decouple overheads details (e.g. container management and OS scheduling) and in managing the cloud platform from the overheads caused in the motivates the provider to minimize these overheads. server context. This reveals the architectural implications of FaaS • Similar to microservices, functions are typically very short computing. (O(100ms)). This is in contrast to common cloud and pro- We identify a range of new overheads that affect FaaS execution cessor architectures that expect long-running applications. with short functions affected most acutely. Figure 1 summarizes The overheads of handling these short functions can further these overheads in the context of the full stack of overheads. worsen the problem of low utilization in cloud servers [11– Our contributions are as follows: 13]. Moreover, due to high parallelism, performance