A mixed-method empirical study of Function-as-a-Service software development in industrial practice

Highlights

• The first systematic study of serverless and FaaS cloud offerings.

• Combines analysis of grey literature, interviews, and Web-based survey.

• FaaS services are commonly used in the backend, although frontend usage is possible.

• Adopting serverless requires a different, composition-oriented mindset.

• Tooling availability and maturity remain barriers to entry.

Abstract

Function-as-a-Service (FaaS) describes cloud computing services that make infrastructure components transparent to application developers, thus falling in the larger group of “serverless” computing models. When using FaaS offerings, such as AWS Lambda, developers provide atomic and short-running code for their functions, and FaaS providers execute and horizontally scale them on-demand. Currently, there is no systematic research on how developers use serverless, what types of applications lend themselves to this model, or what architectural styles and practices FaaS-based applications are based on. We present results from a mixed-method study, combining interviews with practitioners who develop applications and systems that use FaaS, a systematic analysis of grey literature, and a Web-based survey. We find that successfully adopting FaaS requires a different mental model, where systems are primarily constructed by composing pre-existing services, with FaaS often acting as the “glue” that brings these services together. Tooling availability and maturity, especially related to testing and deployment, remains a major difficulty. Further, we find that current FaaS systems lack systematic support for function reuse, and abstractions and programming models for building non-trivial FaaS applications are limited. We conclude with a discussion of implications for FaaS providers, software developers, and researchers.

Introduction

Since its emergence, the programmable cloud has been a rapidly growing area of interest for application deployment. Various providers, including Amazon Web Services, Google Cloud, Microsoft Azure, and IBM Cloud (formerly Bluemix), offer services on different levels of the cloud stack, e.g., Infrastructure-as-a-Service (IaaS) or Platform-as-a-Service (PaaS). IaaS services often lend themselves to a “lift-and-shift” style migration, where entire applications can be migrated without deep changes as mostly self-contained virtual machines (VMs) or containers. However, PaaS services, which provide a higher level of abstraction, ask for more concessions in how applications are architected, built, and deployed in return for a richer development experience and more built-in features (Sharma et al., 2013). Ultimately, many applications deployed in PaaS clouds are “cloud-native”, in the sense that they are specifically built for the cloud, or even a specific combination of services, and cannot easily be operated anywhere else. This introduces a certain amount of lock-in, which practitioners are still often willing to accept in exchange for built-in elasticity and resilience, lower costs of operation, and a relief from having to manage their own infrastructure (Cito et al., 2015).

In recent years, the term “serverless computing”¹ has gained momentum to describe the pinnacle of the cloud-native model: a “serverless” cloud application is deployed to infrastructure components that are entirely transparent to the application developer. The fundamental promise of serverless is sometimes pointedly described as “NoOps”, a wordplay on the well-known DevOps movement (Bass et al., 2015) that stresses that “no operations” is, at least in theory, required to maintain a serverless application.

The most prominent implementation of the serverless model are Function-as-a-Service (FaaS) offerings, such as AWS Lambda, Azure Functions or IBM’s and Google’s Cloud Functions. When using FaaS offerings, application developers provide source code of relatively atomic and typically short-running functions, and define triggers for executing these functions, for example HTTP requests or system events. The FaaS provider then, on-demand, executes and bills functions as isolated instances and scales their execution horizontally as needed. Ideally, application developers using FaaS benefit from simple deployments, reduced operation efforts, and pay-as-you-go pricing, while providers have the chance to efficiently serve large numbers of users and functions with relatively few resources.

Unsurprisingly, these advantages of FaaS do not come for free. FaaS-based applications need to adhere to a multitude of technical and architectural restrictions to ease their transparent management. For instance, functions deployed to AWS Lambda cannot, at the time of writing, retain state between invocations, need to finish processing in 5 minutes or less, have unpredictable execution time deviations and cannot make use of more than a single CPU thread (Malawski et al., 2017). More importantly, AWS Lambda and other FaaS services are ultimately intended to host small microservices implemented in a few hundred lines of program code. Composing larger applications from such stateless microservices, or decomposing an existing monolith into them, is still a challenging open issue (Mazlami, Cito, Leitner, 2017, Bass, Weber, Zhu, 2015).

In this paper, we present the first systematic study of software development for FaaS-based applications. Our study addresses the following research questions:

• RQ1: Which types of applications is FaaS-based computing used for in today’s industrial practice? Which types of use cases is this technology valuable for?

• RQ2: What are the key architectural patterns and best practices for building FaaS applications?

• RQ3: What are the major advantages and challenges of using serverless and FaaS in practice?

Given the immaturity of our study subject, we use an exploratory mixed-method empirical research design to address these questions. We initially conduct a structured review of multi-vocal (“grey” Garousi et al. (2016)) literature (e.g., online blogs) and semi-structured interviews with 12 practitioners in the field. We use grounded theory, as well as open and axial coding, to generate a number of initial findings and hypotheses related to our research questions, which we then validate and refine based on a Web-based survey with 182 valid respondents.

Our study shows that FaaS is commonly used in backend scenarios, where the technology is often used to handle batch jobs. Building user-facing FaaS applications is possible, but requires careful design to deal with slow tail latency due to container startup. Adopting serverless requires a different mental model, where systems are primarily constructed by composing pre-existing services, with FaaS often acting as the “glue” that brings these services together. FaaS offers technical and business-related advantages, but managing and predicting deployment costs is difficult for larger applications. Further, tooling availability and maturity, especially related to testing and deployment, remains a barrier to entry. Finally, limited support for function sharing and the absence of a service ecosystem is seen as a challenge.

The remainder of this paper is structured as follows. We provide details on FaaS offerings, development of cloud functions and other important concepts in Section 2. In Section 3, we discuss our study design in detail, followed by an extensive discussion of results and study outcomes in Section 4. Section 5 discusses the main implications of these results and presents the central lessons learned for FaaS providers, users, and researchers. Section 6 puts our work in context of the existing body of research. Finally, Section 7 summarizes and concludes the paper.