# Efficiency in the Serverless Cloud Computing Paradigm: A Survey Study

Chavit Denninnart, Mohsen Amini Salehi
High Performance Cloud Computing (HPCC) Laboratory,
School of Computing and Informatics, University of Louisiana at Lafayette, USA
<EMAIL_ADDRESS>
###### Abstract

Serverless computing along with Function-as-a-Service (FaaS) are forming a new
computing paradigm that is anticipated to found the next generation of cloud
systems. The popularity of this paradigm is due to offering a highly
transparent infrastructure that enables user applications to scale in the
granularity of their functions. Since these often small and single-purpose
functions are managed on shared computing resources behind the scene, a great
potential for computational reuse and approximate computing emerges that if
unleashed, can remarkably improve the efficiency of serverless cloud
systems—both from the user’s QoS and system’s (energy consumption and incurred
cost) perspectives. Accordingly, the goal of this survey study is to, first,
unfold the internal mechanics of the serverless computing and, second, explore
the scope for efficiency within this paradigm via studying function reuse and
approximation approaches and discussing the pros and cons of each one. Next,
we outline potential future research directions within this paradigm that can
either unlock new use cases or make the paradigm more efficient.

###### Index Terms:

Serverless, Computational Reuse, Approximate Computing, Survey

##  I Introduction

###  I-A Serverless Computing Paradigm

The first generation of cloud technology, established around 2010, mitigated
the burden of system administration and maintenance via consolidating servers
and forming centralized data centers. It is anticipated that the second
generation of cloud technology focuses on mitigating the burden of developing
cloud native applications for programmers and solution architects via
serverless computing paradigm [1].

Serverless computing provides the developers with high-level software
abstractions, such as functions (a.k.a. Function-as-a-Service (FaaS)), and
transparently deploying them, such that the user has the illusion of having no
servers to manage [2]. Accordingly, modern software engineering methodologies,
such as DevOps [3] and Continuous Integration Continuous Delivery (CI/CD)
pipelines [4], have adopted the serverless computing paradigm to facilitate
rapid cloud native application development. These methodologies instruct
splitting an application into several functions that are invoked periodically
or in response to an event. Behind the scene, each function invocation leads
to execution of one (or an ordered set of) stateless micro-service(s) [5].

As shown in Figure 1, the serverless computing paradigm can be defined as the
combination of FaaS and BaaS. While FaaS focuses on the front-end development
of functions in a wide-variety of programming languages, Backend-as-a-Service
(BaaS) focuses on the transparent and isolated execution of the functions.
BaaS is also in charge of scheduling, monitoring, and transparent elasticity
of the functions (micro-services). In summary, we can say Serverless = FaaS +
BaaS [1]. It is noteworthy that serverless computing is a loose term and it
does not strictly enforce the user’s code to be based on FaaS.

Figure 1: Serverless computing paradigm mitigates the burden of developing
cloud-native applications via offering a high-level programming abstraction
(FaaS) and transparently executing them (BaaS). Different applications can
define and trigger functions with minimal configurations needed for each
function.

A common approach to handle function calls (henceforth, called users’ requests
or tasks) in BaaS is to gather the requests from all triggering sources (e.g.,
API calls, timer, and events) into a central queue. Then, a resource allocator
maps these requests to scalable pools of computing resources. To isolate the
requests from each other and to avoid the side-effects of using shared
resources, often, some form of task sandboxing, such as containers or micro
Virtual Machines (e.g., Firecracker VM [6]), is employed.

###  I-B Scope for Efficiency in the Serverless Computing Paradigm

The shared and transparent nature of serverless systems offer a great
potential for efficiency—both from the system and user perspectives. From the
system end, metrics such as throughput, utilization, energy consumption, and
carbon emission, and from the user end, Quality of Service (QoS) (e.g.,
turnaround time), and the user’s incurred cost can be potentially improved.
The potential efficiency improvement can be unleashed, primarily via smart
resource allocation methods that can identify identical and/or similar tasks
in the serverless system. Accordingly, two main directions to improve the
efficiency of serverless computing can be enumerated as follows:

  1. (A)

_Computational reuse_ that avoids redundant processing of identical or similar
function requests. It focuses on reusing the whole or part of the execution,
underlying platform (e.g., container), and allocated resources of a process. A
well-established reusing approach is based on caching [7] that can avoid re-
execution of a recent task. While caching is _retroactive_ by nature and can
only capture identical tasks, in the serverless computing, there is scope for
_proactive_ reusing. In this manner, similar (or identical) concurrent
function calls can be aggregated to one merged task to reuse part of (or the
whole) computation.

  2. (B)

_Approximate computing_ that can be employed in circumstances where lower
quality (less accurate) results can be tolerated. Using approximate computing,
cost, energy, and response time of the serverless cloud can be reduced. Some
common approaches for approximate computing include scaling down the precision
of the invoked function, downsampling its input data, skipping some of the
computation steps in the function workflow, or approximating the function
result from the similar or recent invocations.

Figure 2: Comparison of three scenarios to handle similar function
invocations: (a) separately executing functions; (b) reusing load and decode
micro-services of the function calls; and (c) approximating a function call
and make it compatible with an existing one.  Figure 3: In both IaaS and PaaS,
the user has to deal with the application development and configuring the
application on the servers and platforms. Serverless computing, however,
enables the user to think at the function level and abstracts her from dealing
with the server configuration details. It allows the users to become solution-
oriented and focus on their business logic without the need to micro-manage
system-level aspects in the cloud.

As a motivating example, consider the case of a serverless cloud used for
processing live video contents before streaming them to the viewers [8]. As
shown in Figure 2, the system has transcode(v,c) function to change the codec
of video segment v to c; and bitrate(v,b) function to change the bit-rate of
video segment v to b. The figure shows possible scenarios of function
execution in the system. Consider two invocations of transcode(v1,c1) and
transcode(v1,c2) coexist in the system. Without merging, shown in Figure 2(a),
the two invocations separately load, decode, and encode the video.
Alternatively, by merging these invocations into one task, shown in Figure
2(b), the load and decode operations that are identical can be reused, and
then encode operation into two different codecs is carried out individually.
Because transcode() function cannot be approximated, consider bitrate()
function to explain function approximation. In this case, shown in Figure
2(c), one invocation, bitrate(v1,b2), can be approximated to bitrate(v1,b1),
hence, the whole execution chain can be reused.

###  I-C Paper Structure

Prior to study efficiency in the serverless cloud computing, we need to learn
about nuts and bolts of the serverless computing. Accordingly, in the rest of
this survey, we first dive deep into the serverless computing details and
study its anatomy. Then, we concentrate on the efficiency of the serverless
systems. In fact, the examples described in the previous part only show one
possible scenario for reusing and approximating a function. We are to explore
the potential for different forms of function reuse and approximation that can
be unleashed, thereby, enabling efficient serverless cloud computing. An
overview of the approaches that are studied in this work is shown in Figure 6.

We believe this survey study can help the research community to further
develop these areas and build more efficient serverless computing platforms.
The rest of the paper is organized as follows: Section II introduces the
current state of commercial and research-based serverless computing platforms.
Then, Section III discusses the potential of computational reuse on various
parts of the serverless computing platform. Next, Section IV discuss the
approximate computing techniques that can be applied on the serverless
computing platforms. Section V lists some potential development directions to
increase data and compute reusability in the serverless computing platforms.
Finally, we conclude this paper in Section VI.

##  II Nuts and Bolts of Serverless Computing Paradigm

###  II-A Serverless Versus Conventional Cloud Paradigms

Serverless computing provides a higher level of abstraction in compare to the
conventional cloud service paradigms. Figure 3 elaborates on this point by
showing various forms of server deployment and the abstraction level they
offer. In this figure, from left to right, we have:

  * •

In-house server deployment that involves the users in all the server
acquisition, maintenance, and management (e.g., scheduling and scaling)
details.

  * •

Infrastructure-as-a-Service (IaaS) that mitigates the burden of server
acquisition and maintenance, but still involves the user in server management
and configuration details.

  * •

Platform-as-a-Service (PaaS) offers one more level of abstraction and covers
server management too. However, the abstraction is offered behind a specific
software platform (e.g., a certain programming language or a database
management system). Therefore, to develop and deploy an application, the user
has to engage with and configure various PaaS services (e.g., for compute,
load-balancing, and database).

  * •

Serverless computing and FaaS abstract the users from both the server
maintenance and management too. However, unlike PaaS, using serverless entails
breaking the application into multiple functions that each one can potentially
be developed with a different programming language. Then, the entire function
execution management, such as resource allocation, scaling, scheduling, fail-
over, and platform configurations, are transparently handled by the underlying
serverless platform. Thus, this paradigm simplifies the software development
process and enables the users to become solution oriented and focus on their
business logic, rather than specific server configuration details.

###  II-B Functions and Triggers in Serverless Computing

FaaS enables users to develop functions and define a way to enact their
execution, called function triggers. FaaS platforms desire the user’s
application to be constructed as a set of single-purpose functions that
receive a set of input parameters and yield a set of output [9]. Each function
is managed and scaled independently by the BaaS platform.

The function triggers are commonly based on API-calls (e.g., web requests),
timers, and completion of other events (e.g., completion of another task) [10,
11]. Two main ways to designate function triggers are: (A) Defining the
trigger for each function individually; and (B) Using a _workflow_ schema file
(e.g., JSON workflow definition [12]).

Although defining an individual trigger for each function is simpler and more
popular, defining multiple function triggers together in form of a workflow
schema has its own advantages. First and foremost, the schema can provide
useful metadata for the resource allocator in BaaS to identify parallelizable
tasks and schedule them together, thereby, improving resource utilization and
users’ QoS (e.g., waiting time). Second, using the schema, complex function
workflows can be defined that otherwise would be time-consuming and error-
prone to build [13]. Third advantage is the portability and reusability that
employing a workflow schema offers. While per-function triggers are tied to
each function, the workflow of functions is defined within a schema file with
a specific syntax [13]. The schema can be used to effortlessly re-deploy the
application on the same or a different serverless platform.

###  II-C The Matter of “Function State” in Serverless Computing

Functions in the serverless computing are originally designed to be stateless.
That is, a function does not maintain (i.e., memorize) any state data (e.g.,
shared variables) between consecutive invocations and its output is merely
subject to its input arguments. Statelessness is, in fact, a primary practice
in functional programming [14] that prevent side-effects [15], thereby,
improving software robustness and predictability. This implies that, for a
given input, a stateless function always yields the same output, thus, the
function results can be reused (e.g., via caching). In addition, stateless
functions mitigate the overhead of serverless platforms by relieving them from
maintaining data consistency and synchronization in executing functions [2].

Despite the benefits of stateless functions, some applications naturally
demand the state to be maintained. Refactoring stateless version of these
applications makes them prohibitively inefficient. For instance, a big data
analytics workload (e.g., semantic search [16]) cannot afford loading the
entire dataset for each function call, nor can it afford forwarding the output
to other functions along the workflow. A common approach to circumvent this
situation is to persist the state on the external storage services [17].
However, Pu et al.,  [18] demonstrate that employing external storage to carry
out serverless data analytics is up to 500$\times$ slower than using IaaS
cloud.

In fact, the matter of state is still an open challenge in the serverless
paradigm. Several research works have been undertaken to offer a built-in
stateful serverless solution [19]. Such solutions often employ some forms of
key-value and/or file-based storage. Sreekanti et al.,  [20] develop a
stateful serverless platform, called Cloudburst, using Anna [21], which is an
auto-scaling key-value storage, to persist the state. Pu et al., propose
Shuffling [18], a stateful domain-specific serverless platform for data
analytics, with a hierarchical state persistence—a fast layer on the memory
and a slower one on the device storage. Schleier-Smith et al., develop a
dedicated POSIX-like file-storage system to enable a stateful serverless
computing, called FAASFS [22]. It tackles multiple challenges of providing a
shared file system across functions, such as cache and transactional
consistency [23, 24]. Shillaker and Pietzuch evaluate stateful functions
within the FASSM platform [25] via sharing the state in form of both memory
segments and files.

Serverless System |  Open-Source |  Supported Programming Language |  Feed Format |  Underlying Platform |  Stateful |  Function Start |  Workflow Support |  Special Features / Note
---|---|---|---|---|---|---|---|---
AWS Lambda | ✗ | Any |  FN, CN | Firecracker | ✗ |  Cold/ Warm | ✓ |
AWS Fargate | ✗ | Any | CN |  CN on Firecracker | ✓ |  Warm | ✓ |
Microsoft Azure Functions | ✗ | Any |  FN, CN |  Kubernetes /Azure Arc | ✗ |  Cold/ Warm | ✓ |
Microsoft Durable Function | ✗ | Any |  FN, CN |  Kubernetes /Azure Arc | ✓ |  Warm | ✓ |
Google Cloud Functions | ✗ |  .Net, PHP, JS, Go, Python, Java, Ruby | FN |  Google App Engine | ✗ |  Cold/ Warm | ✗ |
Google Cloud Run | ✗ | Any |  FN, CN |  Kubernetes | ✓ |  Cold/ Warm | ✓ |
IBM Cloud Functions | ✗ |  Any |  FN, CN | OpenWhisk | ✗ |  Cold/ Warm | ✗ |
Oracle Fn | ✗ | Any |  FN, CN | CN | ✓ |  Cold/ Warm | ✓ |  Based on Fn Project & Fn Flow
OpenFaaS | ✓ | Any |  FN, CN |  Kubernetes/ OpenShift | ✗ |  Cold/ Warm | ✗ |
Apache OpenWhisk | ✓ |  Any |  FN, CN |  Kubernetes/ OpenShift | ✗ |  Cold/ Warm | ✗ |
Platform9 Fission | ✓ |  Go, Python, JS, PHP, Java, Ruby | FN | Kubernetes | ✗ |  Cold/ Warm | ✗ |
Nuclio | ✓ |  Any | CN |  Kubernetes/ Docker | ✓ |  Cold/ Warm | ✓ | GPU support
Knative | ✓ |  Any | CN |  Kubernetes | ✓ |  Cold/ Warm | ✓ |
TABLE I: Comparison of the major serverless computing platforms. In the table,
FN represents ‘Function’ and CN represents ‘Container’.

###  II-D Function Isolation in Serverless Computing

In principle, virtualization is not a must for FaaS and serverless cloud
offerings. A user can essentially call a function using a command in the
general form of client.invoke(FunctionName=‘F’,
Payload=Data) [26, 27]. Upon invocation, the FaaS engine can interpret the
function and form a task that can be then directly executed on the host
machine (i.e., bare-metal resource provisioning). However, lack of isolation
in bare-metal raises security concerns, particularly, when there are
coexisting tasks from multiple users on shared computing resources. Therefore,
some form of sandboxing is required to isolate the execution environment of
each function call. Broadly speaking, such isolation can be provided at the
following levels: application-level runtime frameworks (WebAssembly [28]),
Operating system-level (containerization), and hardware-level
(virtualization). The layer-view of each isolation platform for the serverless
functions is provided in Figure 4. The software stack of each platform implies
the overhead imposed by that platform. In this figure, the left-most boxes
serve as the legend—dedicating a color for each layer. The white space(s) in
each isolation platform express the absence of the corresponding layer(s),
represented at the left-most side.

WebAssembly:  WebAssembly (a.k.a. Wasm) is an open standard that enables
generation of portable binary-code from various high-level programming
languages and interfaces the binary-code with the underlying host environment.
The binary can be executed both as a standalone code or within a Web browser.
WebAssembly and particularly its software-fault isolation (SFI) feature [25]
provides software-level isolation that can be used by serverless function
solutions. FAASM [25] is an instance of serverless frameworks that executes
functions on WebAssembly. Also, in Kruslet [29], containers are replaced with
WebAssembly in the context of Kubernetes orchestrator [30]. Kruslet listens to
the Kubernetes event stream and upon receiving a task request, it executes the
task on WebAssembly runtime [2], instead of creating (container) pods.

Although WebAssembly can satisfy the needs of small-size functions, in many
use cases a specific environmental setup, such as software packages and
libraries, is required. Just-in-time preparation of these dependencies for
each function execution is time-consuming in WebAssembly. Moreover, making use
of WebAssembly implies compiling the functions to WebAssembly that curbs the
generality of the serverless solution. Therefore, for the sake generality and
to maintain cost- and time-efficient preparation of functions, container or
virtual machine (VM) technologies are more commonly used in the serverless
domain.

Containerization: The the most common way to package and isolate the function
is through containerization [27]. In this technology, a function is
encapsulated within a widely-accepted container standard, termed Open
Container Image (OCI) format [31], that is supported in all modern
containerization solutions. Any programming language and/or software
dependency can be supported, thus, the desired generality of serverless is
accomplished. Unlike VMs that emulate the whole operating system stack,
containers share the host kernel, thereby, both the memory and storage
footprints are reduced. In fact, this pattern of reusing the kernel is
extended to other layers within the container image. Specifically, container
images have a layered structure that encourages reusing software packages
across these images. Container engines use a method, called union mounting,
through which a container is formed dynamically (i.e., on-demand) via fetching
its (read-only) layers at the runtime. Further details about union mounting is
discussed in Section III-D.

Figure 4: A bird-eye view to the underlying layers of various isolation
platforms for serverless functions. From left to right, respectively, there
are functions on bare-metal (e.g., via WebAssembly), on various forms of VMs,
and on a container. The number of layers implies the overhead of each
isolation platform.

Virtualization: Virtualization is the traditional method of providing strong
isolation in cloud computing. Due to including the whole operating system and
application stack in the VM image, in general, VMs suffer from a high memory
and storage footprints. In addition, VMs introduce a high startup delay [32]
to boot up, hence, they are not a perfect fit for frequent starts and
terminations inherent to the serverless functions [11]. As such, VMs are
usually employed as the underlying platform of the serverless frameworks,
rather than an isolator of each individual function. In this case, function
isolation within the VM is offered either via application-level solutions
(e.g., WebAssembly) or containers.

Micro-VM: Although VMs are generally not ideal isolators for functions, there
are some notable efforts to customize VMs for functions. Firecracker [6] is an
AWS open-source project that provides a lightweight VM (a.k.a. micro-VM) with
a high isolation and low startup delay. It is being used by the AWS FaaS and
serverless platforms (e.g., AWS Lambda and AWS Fargate). Firecracker works in
a similar fashion to other full VM technologies that offer an isolated
operating system environment to the user. However, unlike other KVM-based VMs,
which sit on top of the QEMU in the user space, Firecracker directly
communicates with the KVM (kernel) layer via a customized emulation stack.
While such a highly simplified emulation stack is sufficient for ordinary
tasks, it lacks some notable features, such as libraries to support GPU and
specialized CPU instructions. Another downside of Firecracker is its
deployment inflexibility, because it only has to be deployed on top of the KVM
hypervisor.

Unikernel [33] is another lightweight VM-based technology. Similar to micro-
VMs, it bypasses the user space of the hypervisor. Moreover, it bypasses the
user spacce of the guest operating system too. Thus, to run a function inside
Unikernel, required guest OS libraries have to be incorporated at the
application level. That is, the applications that are deployed within
Unikernel have to encapsulate all their required libraries. Storing libraries
on each function image causes a substantial data redundancy and overhead. As
such, Unikernel utilization becomes limited to small functions that do not
require large dependencies.

###  II-E Memory Contention in Serverless Computing: Cold Start vs Warm Start
Functions

Unlike conventional cloud computing services (e.g., IaaS services) in which
users are in charge of explicitly running and terminating their services, in
serverless computing, the platform automatically allocates resources and runs
the services upon request, and then de-allocates them when they are not needed
anymore. This automated allocation and de-allocation of resources is realized
via transient isolation platforms, e.g., containers, that also enable charging
users only for the times the services (functions) are being used. Ideally, the
containers should be maintained in memory to warrant fast execution of the
functions, which is critical in latency-sensitive applications [34]. However,
in a large-scale serverless cloud, maintaining all the functions in memory is
infeasible, owing to both hardware and economic limitations, thus, there is a
memory contention between containers to access the memory. Efficiently
resolving this contention and determining which functions should remain in the
memory and which ones should be loaded in an on-demand manner is a challenging
problem for the BaaS part of the serverless platforms.

In a container-based serverless platform, a function container that resides in
the memory to be launched rapidly is generally referred to as a _warm start_
container. In contrast, the function that must be loaded from the storage
system in an on-demand manner is referred to as a _cold start_ container [5].
The cold start function involves loading the container image that (depending
on the container size) imposes a nontrivial time overhead and can potentially
dominate the function execution time [5]. The overall cold start overhead of a
function can be approximated via multiplying the function invocation frequency
and the cold start overhead.

Note that, calculating the cold start overhead can be further complicated when
other system factors, such as elasticity and storage location, are taken into
consideration. Importantly, there can be a lower-level cold start in which a
function has to undergo the elasticity overhead and wait for the underlying VM
(or hardware) to be made available, before it can be loaded into its memory.
Depending on the storage location, the cold start overhead can be sub-divided
into multiple tiers of cold, namely _local storage cold_ and _repository
cold_. In the former, the function container can be retrieved from a local
storage, whereas, in the latter, the function must be retrieved from a remote
storage (e.g., on a central cloud) that implies a longer overhead. These
factors show that in an efficient serverless, the BaaS part must handle the
cold/warm start of each function individually and based on the function
characteristics. In Section III-D2, multiple approaches to strategically
manage the containers and mitigate the cold start frequency are introduced.

###  II-F Heterogeneity in Serverless Computing

Serverless computing systems were originally pioneered with the aim of
creating an illusion that there is no server to manage. Fulfilling this aim is
viable when the underlying computing resources are either homogeneous or of
the same architecture (i.e., consistently heterogeneous [35]). As such, to
date, commercial Serverless computing providers support only various forms of
CPU-based machines that are auto-provisioned by the back-end to match the
function desires [36]. However, to accommodate more flexibility and efficiency
in FaaS and serverless computing, inconsistently heterogeneous systems with a
combination of CPU, GPU, TPU, FPGA and other forms of emerging ASICs [36, 37]
are desired. In this manner, domain-specific programming languages, framework,
APIs, and libraries (e.g., CUDA [38], Tensorflow [39], and OpenCL [40]) can be
accommodated.

To the best of our knowledge, nuclio [37] is the only commercial serverless
platform that offers GPU-based machines. However, with the slow-down in
general-purpose computing and the rise of the specialized computing [41], we
expect to have application-specific hardware to become more prevalent on
serverless platforms in the near future [36].

Supporting heterogeneous computing on a large scale serverless system, implies
addressing several research challenges. First and foremost, is the programming
in different languages. Heterogeneous machines require the code to be written
in a specific way. For instance, a function code that is written for a CPU-
based machine has to be refactored to be able to utilize GPU. Demanding the
user to intervene and provide the function code based on the machine type is
against the ideal user transparency promised by the serverless computing. To
maintain the transparency and at the same time supporting heterogeneity, FaaS
engines must be able to run the same user code on multiple on heterogeneous
machines. In domain-specific applications such capability can be achieved if
the user function runs on top of heterogeneous supported frameworks (e.g.,
Tensorflow for machine learning tasks, FFmpeg [42] for multimedia processing
tasks).

Provided that the user functions can utilize heterogeneous resources, the next
challenge is how to schedule and provision such functions (tasks) on the
heterogeneous resources efficiently. Unlike many HPC configurations,
serverless tasks are small and require low latency. Therefore, a light-weight
and low latency scheduling method that is aware of the machine heterogeneity
is desired. Moreover, to make informed scheduling decisions in a heterogeneous
system, a function execution-time profiler is needed to provide an estimated
execution-time of a given function of different machine types [43]. Since each
serverless function often recurs multiple times, execution-time profiling can
be carried out [11, 44]. However, to reduce the uncertainty in the execution-
time prediction, thereby, making more informed scheduling decisions, on
different machine types, function profiling must be performed proactively and
in an explorative way to examine the infrequently-used options and collect
their execution time statistics. Importantly, scheduling new user-defined
functions, for which there is no prior execution-time statistics, is more
challenging. Methods based on Transfer Learning [45] should be developed to
enable inferring the execution time of the new function based on other
existing functions on different machine types. A similar challenge and
solution can be posed upon addition of new machine types to the serverless
system.

###  II-G Serverless Cloud Solutions

In this part, we first survey various commercial and open-source serverless
cloud solutions that are available and compare them based on the aspects
described in the previous parts. Table I summarizes the specifications of
different serverless solutions. We note that, in addition to the platforms
listed in the table, there has been several other serverless computing
projects (namely, Fission Workflow [46], Kubeless [47], Iron Function [48])
that were discontinued. We have excluded these platforms from the table.

Leveraging our observations from the studied serverless solutions, in the next
part (Section II-G3), we come up with a generic architecture that include the
main components of these systems.

####  II-G1 Public serverless clouds

FaaS and Serverless computing have commercially been made available via AWS
Lambda service [49] for the first time. AWS Lambda executes each function
based on a user-defined trigger and charges the user only for the actual
resource usage time (i.e., function execution time). The Lambda service
arguably pioneered and shaped other FaaS services. Nowadays, Amazon also
offers other serverless computing services—most notably notably AWS Step
Functions [50] and AWS Fargate [51]. AWS Step Functions is a workflow service
that can chain a sequence of Lambda functions and other AWS services to build
a serverless application. It manages the workflow in terms of scheduling,
failure, and parallelization so that the users can focus on the higher-level
business logic. Alternatively, AWS Fargate operates based on containers rather
than functions. In fact, it is an example of a serverless service that is not
built from a FaaS platform.

After AWS, multiple competing serverless computing cloud services, such as
Azure Functions [52], Google Cloud Functions [53], and IBM Cloud Functions
[54] were emerged. These services are consistently evolving with different set
of features. Notably, recently, Azure released Durable Functions [55] to
extend the Azure Function service to support stateful workflows.

####  II-G2 Private Serverless Clouds

Although public serverless platforms are increasingly popular, they come with
the vendor lock-in risk and the trustworthiness issue that is inherent to
public cloud services. Therefore, multiple open-source serverless platform
projects have been developed to allow serverless deployment on self-hosted
servers [56]. OpenFaaS [57] and Apache OpenWhisk [58] are two popular open-
source serverless platforms that dominate the private serverless cloud market.

OpenFaaS handles each function as a container that are deployed through
Kubernetes. Therefore, a user can develop functions in the programming
language of her choice. A packaging script creates a container image with the
user’s function encapsulated in it. Each function container is stored and
managed in the Docker Registry [59] and also in the function store. While
OpenFaaS is open-source and free to use, OpenFaaS PRO [57] is developed for
commercial purposes.

OpenWhisk is another popular open-source serverless cloud platform backed by
the Apache foundation [60]. In compare with OpenFaaS, OpenWhisk has a bigger
developer community and many more features. Similar to OpenFaaS, OpenWhisk
project is also based on Kubernetes. It also utilizes many features from other
open-source products, such as Kafka [61], CouchDB [62], Nginx [63], Redis [7],
Zookeeper [64]. This allows the OpenWhisk to be very scalable and, at the same
time, feature-rich. However, this makes the learning curve of deploying and
managing OpenWhisk steeper. OpenWhisk is also offered commercially on IBM
Cloud Functions [54]. Fission [65] is another serverless platform that is
based heavily on Kubernetes. However, it does not integrate itself into
Kubernetes the way Kubeless does.

Fn Project [66] is an open-source platform that works with Docker containers
in its underlying layer. It supports API-based event triggers (e.g., in form
of web requests). Fn Flow [67] is an alternative version of Fn that can
support workflows. Although both projects have attracted limited users from
the open-source community, Oracle still offers them as commercial serverless
solutions.

Knative [68] is a fast-growing open-source project led by IBM and Google.
Similar to Kubeless [47], which has been discontinued, Knative sits on top of
Kubernetes and enables it to handle serverless workloads. According to the
Cloud Native Computing Foundation (CNCF) survey [69], Knative has been the top
installable serverless solution in 2020. Knative project includes three main
components, namely _Build, Serve,_ and _Event_. Build is in charge of source
code management, containerization, and making it deployable by Kubernetes.
Serve deals with service deployment, managing micro-service revisions, routing
requests to different versions of micro-services, automatic scaling, and scale
to zero. Finally, Event takes care of creating function triggers and forming
workflow pipelines.

Figure 5: Common architectural components of a serverless framework. Note that
not all these components exist in every framework. For example, Function
Packager exists only on the frameworks that do not run functions straight from
the source code.

####  II-G3 General Architecture of Serverless Clouds

Considering the common architectural components of the studied serverless
platforms, we can design a generic architecture, depicted in Figure 5, that is
composed of an underlying function execution framework and eight components on
top of that that take care of different aspects of serverless management. Note
that, a given serverless platform may only have a subset of these components
and it may categorize them differently. For instance, Knative’s main
components (Build, Serve, and Event) can be mapped to _Packaging, Execution,_
and _Trigger_ group of components. Function Packager is only needed if the
framework requires function code to be transformed into the container or other
forms of the compiled function. Workflow Pipeline only exists in the
frameworks that support function workflows.

##  III Reusing Opportunities in Serverless Clouds

Reusing is defined as a way(s) to reduce the resource usage and increase the
efficiency via deduplicating data or computations that share a certain level
of similarity. Historically, reusing (e.g., in form of caching) has been a
fundamental approach to achieve software and hardware efficiency. In this
section, we study reusing in the context of serverless computing and describe
how it can be potentially advantageous for both cloud providers and users.
Then, we explore a wide-variety of techniques to carry out computational reuse
in the serverless context. A summary of these techniques is shown in Figure 6.

###  III-A Advantages of Reusing in Serverless Computing

####  III-A1 Cost efficiency

Serverless cloud computing promotes itself as a cost-efficient computing
paradigm where users only pay for their actual resources usage [70]. The
serverless paradigm encourages cost efficiency in two main ways: (A)
Allocating multiple users’ tasks on shared underlying resources; and (B)
Adopting reusability techniques (e.g., for containers) that are allowed by the
serverless paradigm.

####  III-A2 Quality of Services (QoS)

Computational reuse deduplicates data and computation redundancy. In addition
to the user’s cost-saving, this can directly and indirectly impact the users’
perceived QoS. The direct impact is for the tasks that can complete early by
reusing already available data. Such reusing makes the system less busy,
thereby, making the resources more available to the tasks that cannot directly
benefit from reusing.

####  III-A3 Energy efficiency

Reusing in the serverless platforms can reduce the energy consumption in two
levels: (A) At the macro level, in the cloud datacenters; and (B) At the micro
level, in the energy-limited edge devices [71].

At the macro level, in addition to the resource sharing mentioned earlier,
serverless platforms can reduce the energy consumption by means of rapid
scaling. This avoids the need for resource over-provisioning that is commonly
practiced in IaaS clouds to cope with the surge demands. At the micro level,
serverless edge systems accommodate seamless task (or workflow) live-migration
from the energy-limited edge devices to the cloud tier [72, 73]. In fact,
migration is a way to reuse the performed execution rather than restarting it.
In an opposite direction in the edge-to-cloud continuum, the migration of
services to the edge tiers can help energy-efficiency by means of reducing the
volume of transferred data [73].

Figure 6: Taxonomy of approaches for efficiency in the serverless cloud
computing platforms. The approaches are classified into two categories that
are based on the _computational reuse_ , and then based on _approximate
computing_. There are approaches in the intersection of these two, known as
_approximate reusing_.

###  III-B Deterministic Versus Semantic Reusing

Deterministic reusing refers to the set of techniques that can detect reusable
computation or data in a definitive manner and perform the reusing without
altering results of the involved tasks. That is, these techniques do not
require to infer the semantic similarity between two data or two computations.
An example of deterministic reusing is when a user requests for a re-execution
of stateless video encoding function with identical specifications on the same
video. As the stateless function output depends entirely on its input, a re-
execution of task executed with the same input arguments yields the same
result. Thus, the video result of such task execution can be cached and
reused. Majority of the deterministic reusing techniques operate based on
detecting frequently-used computation and/or data and caching them to be
reused at a later time [74]. Accordingly deterministic reusing techniques can
be categorized into _data reusing_ (a.k.a. caching) and _process reusing_ that
are elaborated in the next subsections.

Alternatively, semantic reusing aims to find a semantic relationship between
not-so-obvious similar (i.e., non-identical) data [75] and perform reusing on
them. In a sense, semantic reusing can be viewed as an approximation approach,
due to similarity detection and the fact that the execution results of the
involved tasks are not deterministic. Moreover, the semantic similarity
detection is prone to misinterpretation, thus, can potentially lead to
incorrect results.

An example of semantic reusing can be in an application that provides ambient
perception for blind and visually impaired users by detecting obstacles in
their environment (e.g., [76]). These users often visit repeated locations and
interact with objects they have previously encountered during their day-to-day
activities. The captured pictures of these objects are _digitally_ different
because they are captured from different angles or under different light
conditions. However, these pictures are _semantically_ representing the same
objects [77]. Accordingly, a reusing mechanism that can pre-process incoming
images and detect whether a semantically similar one has been (or is being)
processed can be helpful.

Further details about different approaches to perform semantic (approximate)
reusing are discussed in Section III-E

###  III-C Data Reusing

Data reusing is the act of saving certain data to be reused at a later time.
It is an integral part in different levels of modern computing systems—from
the hardware level to the compiler and execution levels. In the particular
case of serverless computing and FaaS, the fact that tasks are fine-grain
(function level) and stateless provides an ideal opportunity for data reusing
via saving (caching) and reusing the results of each function execution.

Data reusing is predominantly achieved via caching operation. Caching is an
optional, but very popular, operation in the computing systems to mitigate the
slow down resulted from accessing storage systems, hence, accelerating the
task execution. That is, the system can still function correctly, even if it
misses the cached data and retrieves it from the storage. Since caching is
limited and often costly, establishing a trade-off between cost and efficiency
in the caching scheme is of paramount importance. An extensive cache space
imposes a significant cost, whereas, an inadequate cache space leads to
missing reusable function results that, in turn, increases the re-computation
cost and the response time [78, 79].

Based on the way data is stored and reused, the data reusing techniques fall
into four categories: (1) Task caching; (2) Intermediate data caching; (3)
Function consolidation; and (4) Incremental computing solution. These
categories are explained in the next parts.

##### Task caching

Task caching is the act of capturing and reusing the end result of a task
(function) execution. Due to the stateless nature of functions in the
serverless systems, this caching technique can be deployed in a transparent
way from the user. The cached data can be quickly identified by making use of
the hash value of the function call signature that is composed of the function
name and its arguments [80]. The cache table can be either shared across users
(i.e., public) or maintained separately for each individual user (i.e.,
private). Unarguably, a public cache table maximizes the likelihood of data
reusability across functions of all users. However, it can be vulnerable to
cache poisoning attacks [81]. Alternatively, a private cache table offers a
better security via segregating the cache table either based on the user or
the function [82].

##### Intermediate data caching

Intermediate data caching maintains partial results of the execution, rather
than the final result. The technique is usually suited to large tasks with
multiple computing steps, in which caching the intermediate result offers a
higher chance of reusability than caching the final result [79, 21, 20].
Intermediate result caching can be offered in form of a key-value storage for
the (stateful) functions [7]. To achieve reusability, this caching technique
requires the function code to explicitly store and retrieve partial results
from the caching system. Thus, it is not transparent from the user.

##### Function Consolidation

Another variation of data reusing occurs in the scheduling of workflows [83,
84, 85] that include multiple functions and data dependency between them. In
such workflows, because each function can be potentially allocated to a
different machine, the overhead of transferring the output of one function to
be used as the input of another function can be significant [83]. Such an
overhead can be reduced by fusing small functions together. That is, two or
more functions can be consolidated to form one big function, such that the
whole function is executed together and the data transfer overhead is
eliminated. Function consolidation can be employed at the programming level
via defining less granular functions, however, doing so is against the micro-
service-based software engineering methodology and makes the function
maintainability cumbersome.

A more efficient approach for function consolidation is to let users maintain
their fine-grain functions and let a framework in the back-end automatically
carry out the fusing [83] process without any user intervention. The main
challenge in this approach is how to balance reducing the data transfer
overhead against the resource inefficiency potentially caused by forming
coarse-grain (consolidated) functions [83]. The reason for inefficiency (and
potentially resource wastage) is that coarse-grain functions limit the ways
tasks can be allocated, thereby, reduce the flexibility of resource allocation
methods. For instance, consider a workflow with two chained functions where
the first one, denoted $f_{m}()$, is memory-intensive and the second one,
denoted $f_{c}()$, is CPU-intensive. These functions can be efficiently
allocated on different machines in a heterogeneous system—$f_{m}()$ on a
memory-rich machine and $f_{c}()$ on a CPU-rich machine. However,
consolidating the two functions requires a machine that is both memory- and
CPU-rich. This can potentially lead to inefficient resource utilization or the
incurred cost of accessing such a high-end machine can be more than the
benefit of reducing the data transfer overhead. In summary, we note that an
efficient function consolidation framework must consider the function
characteristics and bases its decisions on comprehensive function profiling
[11].

##### Incremental computing

The fourth category of data reusing is the incremental computing technique
[75]. Similar to the task caching, this technique also caches the task result.
However, the cached content is reusable beyond the tasks with identical input
arguments. Incremental computing utilizes a _correction function_ to adapt
(i.e., prune and expand) the cached results based on the new input. A common
use case of incremental computing is in data analytics [86, 75]. For instance,
consider a repetitive function (query) that is regularly applied against a
database with minor daily updates. A naïve way to handle the query is to
thoroughly search the database every time. Alternatively, an incremental
reusing technique retrieves the results of the prior day and corrects them by
pruning the invalid records and adding new ones via searching only within the
updates in the database since the prior day. It is noteworthy that incremental
reusing is a highly context-specific technique and currently it is not
implemented within the general-purpose serverless platforms. For instance,
Zhang et al.,  [87] propose a serverless and FaaS-based platform that takes
advantage of incremental computing the video analytics context. Their use case
employs a deep neural network (DNN) model for video object classification. The
model requires frequent updates to its weights to gain the maximum accuracy
with the ever-changing datasets. To avoid excessive cost of re-training the
model frequently, their platform deploy incremental machine learning [88]
technique to keep up with the gradual changes in the input datasets.

One way to enable incremental computing in the future serverless platforms is
to allow users to define multiple auxiliary functions, in addition to the main
function. The auxiliary functions can include: a _subtract function_ (to
remove part of the existing results that are not valid for the input argument)
and an _addition function_ (to include new results to the existing ones and
adapt them based on the new function arguments).

###  III-D Container Reusing

Apart from the data reusing, serverless efficiency can be gained via reusing
at the sandboxing platform (i.e., container) level. More specifically,
container reusing can be carried out at the _container image_ or at the
_container instance_ levels that are described in the following subsections.

####  III-D1 Container image reusing

##### Union mounting

Union mounting [89] is a well-established approach to reduce the container
image footprint (and hence, start-up overhead of the container). In union
mounting, a container image stored as multiple separate components (layers)
that can mount together to form an image. In this manner, the same layer can
be utilized (i.e., reused) in multiple images that share a module, thus, the
storage overhead of container images is reduced. For instance, two machine
learning functions can share the same operating system layer and the same
machine learning framework (e.g., Tensorflow [39]) layer. Then they only
differ on the application and model layers. Although deduplicating redundant
layers is already widely-used by the runtimes, further research works have
recently been undertaken to improve the efficiency of deduplicating [90, 91]
and to extend the deduplication idea to reuse _similar_ layers [92]. Notably,
Zhao et al., ’s Duphunter [90] is a replacement layer loading module for
Docker platform. The architecture is more effective in deduplicating similar
layers across multiple docker images with less deduplication overhead than
prior designs.

##### Container image merging

When two or more functions whose container images have only minor differences
are launched from a cold start, union mounting can capture and reuse most
parts of their images. However, from the serverless platform perspective,
these two are separate functions, hence, are treated independently. In the
event that these functions are infrequently invoked, they can get evicted from
the memory. To encourage the system to keep these infrequently used functions
warm (i.e., in the memory), one approach that can be explored is to merge
these functions such that they share the same container image. In this case,
the collective invocation frequency of these functions is increased that can
in turn avoid the memory eviction for them.

####  III-D2 Container instance reusing

##### Predictive warming and cooling

Due to the memory limitations of the servers, not all function containers can
be maintained in the memory to rapidly start the functions’ execution.
Infrequently used functions have to be offloaded to the storage to make room
for the frequently-used ones. Such a memory contention across function
containers is one of the challenges in the serverless domain and resolving it
entails dealing with multiple problems: (1) how to reduce the cold start time
overhead? (2) how to keep more containers in a given memory space? (3) how to
minimize the number of cold starts through efficient memory allocation?

The main approach to mitigate the cold start overhead is to alter the
transient nature of containers and keep them in the memory even after the
function execution. Another approach is to proactively loading the container,
i.e., prior to the function invocation. An example of such an approach is the
research conducted by Shahrad et al.,  [11] who studied 14 days of function
invocation patterns in Azure Cloud and leveraged that to develop a container
memory allocation strategy. They propose to reduce the number of cold starts
via categorizing the functions where each category has its own pattern of
_pre-warm_ and _keep-alive_ periods. Right after finishing an invocation, the
function is removed from the memory for the _pre-warm_ period of time, because
the system does not expect to get another invocation of the function in the
near future. Then, once the pre-warm period expires, the container is loaded
back into the memory (warmed) to get ready for the next warm start function
invocation. If the function stays in the memory for more than the keep-alive
period without any invocation, then the function is removed from the memory.
Such a strategy reduces the number of cold starts for the majority of the
functions, however, there are still some functions whose invocation pattern is
unpredictable, hence, cannot benefit from the predictive memory allocation.
Nevertheless, the benefit of correct predictions and delivering warm start
remarkably exceeds the cold start mis-prediction plus the solution overhead.

##### Predictive function (task) batching

Although the request turnaround time is one of the main criteria in measuring
the performance of serverless clouds, not every application needs the function
to complete as soon as possible. Moreover, even deadline-constraint tasks
often can tolerate some delay (slack) before missing their deadline. In fact,
a recent study conducted by Eismann et al.,  [93] demonstrate that around 38%
of their surveyed serverless applications have no latency requirement and
another 28% of the applications have a few latency-sensitive functions. Only
2% of the applications are real-time with rigid latency constraints.

To maximize reusing in the serverless computing, the user or the system should
have a way to declare the task urgency, possibly in multiple tiers (e.g.,
urgent or non-urgent) or as a continuous number (such as a deadline). In this
case, highly urgent tasks can be scheduled to to complete with the minimum
turnaround time via warmed containers, whereas, the less urgent ones can
potentially wait to aggregate with other similar arriving requests, thereby,
maximizing the container reuse and reduce the incurred cost. The scheduler
must have the ability to predict the cost-benefit of delaying tasks in favor
of batching them, such that each task waits as long as possible without
missing its deadline to share the function container and other resources with
other tasks. Using this concept, Grandslam [94] scheduler is proposed to
dynamically reorder tasks to maximize the task batching and minimize Service
Level Objective (SLO) violations in an oversubscribed system. Fifer [95]
includes a scheduler with mechanisms to batch tasks and reduce the amount of
container usage and cold start overhead within a given latency budget. Unlike
Grandslam, Fifer tries to minimize the resource usage in an underutilized
system, rather than trying to meet the tasks’ deadlines in an oversubscribed
systems.

##### Durable container

Prior studies (e.g.,  [96, 11]) express that, in a serverless system, a
certain percentage of functions are invoked very frequently. If warm start
execution of these functions incur a significant loading overhead, then the
frequent warm starts can compound to a substantial overhead for the system. A
common example of functions with high warm start overhead are those that
involve an online machine learning model [45]. To solve such inefficiency,
certain serverless computing platforms allow functions to run as a durable
container that means the container does not terminate after the task
completion (i.e., non-transient container). These durable containers can
maintain state (e.g., updates on the machine learning model, in the above
example) across function calls that help to process subsequent tasks without
paying repeated start-up overhead. In the event that there are multiple
requests for the same function, the requests are queued to receive the
service. Microsoft Durable Functions [55] and Oracle Fn Flow [67] support such
capability. We envision that the future serverless platforms will auto-detect
frequently-used functions and make their containers permanent without any user
intervention.

###  III-E Semantic (Approximate) Reusing

While deterministic reusing is only built on the identical data, semantic
reusing aims to achieve reusing where the data are not digitally identical,
but the base for reusing is some form of _semantic similarity_ between the
data. Semantic reusing can maintain semantic correctness by producing
approximately the same results, while remarkably avoiding resources wastage
and improving users’ satisfaction. That is why this category of reusing is
also considered as a type of approximation (discussed in Section IV). However,
the mechanism to detect semantic similarity is not infallible and, similar to
other approximation approaches, can potentially lead to inaccurate results
that in certain contexts (e.g., video streaming) could be tolerable and still
useful.

In the serverless context, there are four types of similarities that can be
leveraged for semantic reusing:

(1) Similar input: For stateless functions, the end result of execution
depends only on the input argument. The input often is composed of multiple
parameters. For instance, a video encoding function has the video segment,
resolution, frame rate, bit rate, and codec as its input parameters. By
designating certain parameters of the function as approximable, function
reusability can be enhanced [77]. For instance, consider two users who call
the transcode function to process same video with two different (but
approximable) resolutions. In this case, the system can approximate the
resolution arguments and process the function once, instead of twice, and send
the results to both users. Such scenarios can be particularly useful under
certain circumstances, such as when the system is oversubscribed or when some
users can tolerate lower QoS (e.g., free subscribers of a video streaming
service).

(2) Similar function: Following the micro-service-based software development
principles [4], generally, functions are developed to be short and single-
purpose to ease the continuous deployment (CD) process. Therefore, it is
likely that multiple users define similar functions that try to achieve the
same purpose. These functions are semantically the same, while having distinct
source codes. Let functions $A$ and $B$ be semantically the same and $x$ be an
arbitrary input argument. In this case, the serverless computing system with
the function similarity detection mechanism in place can reuse the result of
$A(x)$ for $B(x)$ too. Moreover, since these functions are similar, one of the
functions can be replaced by the other one, rather than keeping both functions
available. This saves the number of functions that have to be kept active for
rapid execution.

(3) Similar context: In this category, the state (context) of a stateful
function is to be reused. This is particularly helpful in the circumstances
that the state data is not sensitive and can tolerate minor differences. That
is, minor changes in the state do not significantly impact the results. For
instance, consider a function for online-learning of an image classification
machine learning (ML) model [97] where the state data is the weights of the ML
model. Other functions that intend to train the same model can borrow (reuse)
state (weights) of the model from the earlier function, and train it further
with their own data. Such reusability makes the ML model converge faster and
is more cost- and energy-efficient. A similar type of reusing can be
considered in a serverless federated learning system [98] where the workers
reuse a central model and train it further with their own local data.

(4) Reusing prior knowledge: In a serverless system, function (task) profiling
data, collected and summarized from prior executions via automatic task
profilers [99], can be supplied to the task scheduling module to maximize the
resource allocation efficiency of the system. Moreover, for a new user-defined
function that lacks prior profiling information, the serverless platform can
reuse prior knowledge of semantically similar functions to estimate the
execution time of the new function on different machine types available in the
system. Otherwise, lack of such information causes uninformed scheduling
decisions that negatively impact the users’ perceived QoS. Unlike other forms
of semantic reusing that directly impact quality of the results, reusing prior
knowledge deals with the system parameters (e.g., utilization and QoS) and is
used to improve them.

Transfer learning is a technique to reuse the knowledge gained while solving
one problem and applying it to a different but related problem [100].
Accordingly, transfer learning can be employed to predict the execution time
of a new function on a given machine type based on the trained networks of
other functions on the same machine type. Moreover, methods can be explored to
measure the semantic similarity between the new function and each one of the
existing functions based on the dependencies and libraries shared between
them. Then, the weighted average similarity of the new function with other
functions can be used to estimate the execution time of the new function on
that particular machine type. It is worth noting that, once enough execution
time information for the new function are collected, a model specific to that
task type can be trained to infer its execution time independent from other
task types. Similarly, when a new machine type is added to a heterogeneous
serverless system, the prior profiling information of functions on other
machine types can be leveraged to estimate the expected execution time of the
functions on the new machine type, thereby, utilizing it more efficiently.

##  IV Approximate Computing in Serverless Clouds

Approximate computing allows functions (tasks) with unaffordable response
time, energy, or cost constraint(s) to be completed within its constraint(s)
[101]. Even the tasks with affordable constraints that can tolerate
approximate results (i.e., multi-fidelity tasks [102]), can use approximate
computing to bring about further resource-saving in the system. Since
approximate computing compromises the precision and/or accuracy of the
results, we envision that employing approximation techniques has less scope
(in compare to reusing) in serverless platforms and is used only to meet the
tasks’ constraints that are otherwise unattainable. Example use cases of
approximate computing in the serverless systems include:

  * 1)

Improving the _response time_ via fast approximated results, before confirming
or correcting the results by the exact computing.

  * 2)

Providing an approximate result to save the _cost_.

  * 3)

Providing an approximate result only if the system is _oversubscribed_ and
cannot perform exact computing in time.

There are various approaches for approximate computing that can improve the
efficiency of the serverless computing platforms. We can categorize these
approaches into four classes as shown at the lower part of Figure 6. In this
section, we first position approximation approaches with respect to the
reusing-based approaches and then discuss the general requirements for
function approximation in the serverless context. Next, we elaborate on the
four classes in Sections IV-C—IV-F.

###  IV-A Approximation Versus Reusing

The main difference between approximation and computational/data reusing is
the impact on the result accuracy and precision. Computational reuse
accelerates the turnaround time or saves the computing resource without
influencing the task result. Conversely, approximate computing compromises the
result accuracy and/or precision in favor of time- and/or resource-saving.

While approximate computing can be applied to tasks independently, many of the
approximation techniques benefit from reusing information gathered from prior
tasks. Such information can be either predefined ahead of time (e.g., trained
ML models) or collected and applied dynamically at the run time (e.g., caching
the results of similar tasks). Approximate computing techniques that directly
reuse the result of other similar tasks are also known as approximate reusing
that is elaborated in the previous section.

###  IV-B Approximate Computing Requirements

Approximate computing exploits the resilient property of the system by
producing inexact but acceptable result at a lower cost. A resilient system
[101] or application should be able to tolerate a certain amount of deviation
from the ideal result [103]. Specifically, an approximate computing technique
should not cause deviations that exceed the application resiliency in both
error magnitude and likelihood (chance).

#####  IV-B0a Error magnitude

Error magnitude is defined and measured based on the variation of the obtained
result from the ideal result. Applications’ tolerance to the error magnitude
varies based on the context. For example, video processing for live video
conferences can tolerate a higher error magnitude than the video processing
for traffic cameras that has to perform vehicle identification.

#####  IV-B0b Error chance

Another dimension of the error quantification is the likelihood of error
occurrence. Formally, the likelihood of getting an overly inaccurate
approximation is called the _error chance_. Certain approximation techniques
(e.g., DVFS [104]) produce mostly accurate results, however, there is a chance
that the error occurred and the result accuracy is off by far beyond the
acceptable error magnitude. In such approximation techniques, upon detecting
an error by a validation function, a correction function [105] is employed to
fix the error retroactively. In the event that the chance of getting an error
is considerably high, then the overhead of correcting the results frequently
can exceed the benefits of the approximation.

###  IV-C Data Level Approximation Approaches in Serverless Computing

####  IV-C1 Approximate reusing

Approximate reusing is the same as semantic reusing and is performed via
identifying potentially reusable tasks and using their data to approximate
other tasks [106]. Allowing repeated function-calls to reuse the result of
similar, but not strictly the same, tasks promotes the reusability. The main
challenge in approximate reusing is detecting the semantic task similarity.
Applying This type of computational reuse can improve both the user and system
metrics, unless the users opt-out of it due to privacy concerns.

####  IV-C2 Data sampling

For functions that work on a batch of data, such as data analysis works [18,
75], it is possible to reduce the input data size by sampling from the
dataset. Various techniques have been explored for data sampling, performing
computation on the samples, and then analyzing the variability and the error
rate in comparison to the complete data analysis on the whole data. For
example, ApproxIoT [107] proposed a method to sample data from a stream of
unknown data size. Sampled data are stored in a size-limited reservoir. New
data can randomly replace the existing ones in the reservoir. This approach of
approximate computing can be offered as an optional service for various
special-purpose stateful serverless functions.

####  IV-C3 Approximate data storage and data pruning

Approximate data storage can be achieved via either persisting only a portion
of the data or scramble multiple data points together. For instance, in a
serverless multimedia cloud [8, 108] only base video formats can be persisted
and other less popular formats can be transcoded lazily—upon receiving a user
request. For the content types that are error sensitive, similar data points
can be stored together (merged) via lossless data compression methods (e.g.,
[109]), whereas, for the content types that can tolerate minor errors (e.g.,
multimedia and image) lossy compression methods (e.g., [110]) can be employed
to approximate similar data and carry out more effective compression.

Rather than letting the user handle data storage and reusing, the serverless
platform can offer services to store and deduplicate similar data [111]. By
performing the data management at the platform level, the platform can
maximize the likelihood of detecting similar data and performing
deduplication. In such a storage mechanism, the process of retrieving data can
also be approximated to reduce the data retrieval overhead. Eventual
consistency [112] can be utilized on the data that is accessed by multiple
tasks. Such relaxed consistency control incurs a lower cost than a strict data
consistency at the price of allowing the task to start with inconsistent data.
Serverless functions are generally short-lived and are easily undoable.
Therefore, tasks that start with inconsistent data can be canceled and restart
with a minimal overhead.

###  IV-D Instruction Level Approximation in Serverless Computing

####  IV-D1 Precision scaling and stochastic computing

The earliest forms of approximate computing were built by necessity in
computer storage systems that could not store infinite decimal points [113].
Hence, the numbers have to be approximately stored and represented by a close-
enough value. Then, the concept was further developed to a more deliberate
dynamic precision scaling [71] where calculating precision is scaled based on
multiple factors, including the trade-off between computing precision and
energy requirement or turnaround time requirement.

Stochastic computing [43] is a popular collection of techniques to achieve
precision scaling via representing a continuous value in form of a stream of
bits. In this case, calculating the precision can be scaled by altering the
number of bits in the bitstream. Making use of stochastic computing often
implies designing a domain-specific processing unit (a.k.a. ASICs) hardware.
Since precision scaling requires a specific framework and stochastic computing
requires a specialized hardware, these techniques have not yet gained a wide
adoption in the cloud computing industry. However, with the increasing
prevalence of domain-specific hardware and, particularly, the trend in using
precision scaling for the ML inference on the energy-limited edge devices
[114], we envisage that these solutions will eventually carry over to the
cloud systems too. As such, serverless solutions to support domain-specific
processors that achieve instruction-level approximation will be demanded in
the near future to hide the complexity of deploying such hardware across the
edge-cloud continuum from the user perspective. Such solutions will help the
users to become solution-oriented and focus on their application logic, rather
than dealing with the operational details of different hardware systems.

####  IV-D2 Loop perforation and instruction replacement

In a serverless computing platform, functions can either be provided as
containers or, more popularly, as the functional code blocks. It is possible
for the serverless platform to analyze the user code and apply optimize them
to save computing resources. We believe approximating frameworks such as
Approxilyzer [115] proposed by Venkatagiri et al., can be deployed as an
optional service to achieve such optimizations in the serverless platforms.
Approxilyzer analyzes the (function) machine code and dynamically replaces
parts of the instruction with the approximated version. The aggressiveness of
approximation can be tuned with consideration of appropriate quality,
resiliency, and overhead.

###  IV-E Hardware Level Approximation In Serverless Computing

When heterogeneous computing is supported in a serverless computing system, a
specialized hardware that allows approximate computing in the hardware level
can be offered as one of the resource types. The offering can be especially
attractive for use cases, such as big data and machine learning, that data-
intensive and can benefit from domain-specific machines to offer low latency
and real-time services [116]. Moreover, making use of specialized hardware to
accomplish approximate computing can effectively reduce the energy consumption
and footprint of cloud datacenters [116].

Two main hardware-level approximation approaches are namely, Dynamic Voltage
Frequency Scaling (DVFS) [104] and approximate computing hardware. DVFS is a
technique that strategically under-volt common hardware systems. Although such
undervoltage induces errors in the computation, applying it in the controlled
manner (such that the error rate is tolerable by the applications) can improve
the efficiency of the serverless system. For instance, Rahimi et al.,  [104]
propose to strategically under-volt the GPU in favor energy efficiency, while
employing hamming distance [117] to allow more error tolerance at the
application level. On the approximation hardware side, certain computations
are common and can greatly benefits from approximating hardware. Example of
such tasks include stochastic computing which its computation can be greatly
accelerated by compute approximately by hardware [118], DNN approximate
inference using specially designed inference hardware [114], image encoding
using approximate encoder hardware [119], etc.

Such list of tasks that has approximation hardware support are still expanding
as more use cases are found to benefit from approximation hardware and more
tools to aid approximation hardware emerges [120].

###  IV-F Scheduling Level Approximation in Serverless computing

####  IV-F1 Task dropping and deferral

In a serverless system, each task request can be part of a bigger workflow. In
some use cases, the workflow includes optional steps (tasks) whose loss can be
tolerated [121]. Such feature can be exploited at the scheduling level,
particularly to mitigate resource oversubscription [35], via dropping the
optional tasks [122] or deferring [35, 123] their execution to a later time
when the system is less busy. One use case that can take advantage of such
workflow level approximation is in video conferencing where the voice quality
enhancement step (task) on the received video segments can be skipped
(dropped) to keep up with the liveness of the streamed video contents [8].

####  IV-F2 Predictive task serving

The scheduler of a serverless computing platform can operate proactively and
approximately predicts arrival of the user-requests. Such prediction can help
the platform to pre-warm function containers and load their required data in
speculation of upcoming task requests. However, such preparation is not
currently performed in the serverless system due to the prediction complexity
and cost-efficiency issues [11].

##  V Potential Future Research Directions

###  V-A Data Abstraction in Serverless Clouds

Although Function-as-a-Service (FaaS) abstraction relieves users from the
burden of resource management (e.g., load balancing and elasticity), it is not
truly serverless, because it falls short on abstracting data management and
the users still have to get involved with other services (e.g., AWS DynamoDB
[124] or AWS SAM [125]) to serve desires of the functions and/or applications
[18, 19, 22]. In particular, in some use cases the data can represent the
function state. For instance, the state of an online-learned ML model that is
updated frequently. Embedding such model into the function container image is
not practical. Furthermore, ML models are large enough that cannot be fed as
the function arguments, otherwise the function startup overhead would become
substantial. The ML model is the function state and is best to be stored in a
synchronized storage service that can be accessed and updated upon demand.
Currently, users need to intervene and scatter these data objects on various
storage or database services. We believe that, a truly serverless platform
should abstract the deployment and scaling of both resources and data for the
user. Such an integrated serverless system exposes further potential for
reusing and approximation.

Storage for the serverless platform can be categorized into ephemeral and
permanent services. Data in permanent storage is guaranteed to persist, but
accessing data from such storage is slower than an ephemeral one. Ephemeral
storage is intended for hot data shared by multiple tasks. Such storage is
relatively faster than a persistent one. However, it has limited space, hence,
cannot store infrequently-used data indefinitely. These types of storage
systems are offered by different services [18, 25], as such, there are
different APIs to access them. Currently, users have to get involved in this
level of data storage management details and serverless platforms fall short
in offering the same level of storage management transparency that they
provide for the computing resources. The challenge in offering transparent
(serverless) storage solutions is in abstracting the data storage elegantly,
such that it is intuitive for the user and efficient for the system.

###  V-B Object-as-a-Service (OaaS): Going Beyond the Function Abstraction

Current serverless and FaaS solutions are not designed for (and cannot
natively support) IOT devices. For instance, in a FaaS-based application that
needs to persist the frame-rate of a security camera, the programmer should
resort to other cloud service, e.g., AWS RDS [126], to persist the state
information. This makes the development and maintenance of serverless IOT-
based applications difficult and cumbersome. To ease the management of data
sources (e.g., IOT devices) and accelerate the development of new services for
them, a higher level of abstraction is desired that, in addition to hiding the
resource allocation details, it can hide the details of device management and
preserving its state from the users.

To natively support serverless IOT (and data-centric) application development,
we envisage that in the future serverless platforms, the concept of _object_
can be borrowed from the Object-Oriented Programming, as the first-class
citizen to encapsulate both computations (functions) and state within a single
object entity, and offer the notion of _Object-as-a-Service_ (OaaS). OaaS
enables users (service providers) to configure an IOT device (e.g., security
camera) or a data source (e.g., video content) in form of objects with various
attributes (e.g., recording frame-rate) and then bind functions (e.g., face
detection) to it. In addition, OaaS opens the gate for inheritance of
properties and functions across objects, thereby, making it more convenient
for users to organize and manage multiple data sources. For instance, a
serverless platform can offer a builtin live-streaming object that includes
basic live-streaming attributes and functions. Then, based on the sub-class
and super-class relationship, new user-defined objects can be constructed with
new (and override) functions, while inheriting the basic functionalities from
the super-class.

A user of an object-based serverless platform uses an application (e.g., live
streaming for disabled people) to issue requests in form of <object,function>
to trigger a function call, defined for particular objects. For instance, a
streaming request, issued by a viewer’s application or another object, is a
requester to an streaming object (e.g., live video) that triggers one or more
functions (e.g., face recognition) of that object. Even the request to watch
the stream is considered as invoking the playback function of a particular
object. Other possible advantages of objects will be the migration ability
that can be particularly useful to overcome the lack of elasticity at the edge
tier and to support seamless mobility of services—from one tier (e.g., edge)
to another (e.g., cloud). Moreover, object abstraction can facilitate
serverless workflow definition and management. A workflow object can be
defined that includes a data-source and a set of operations (private
functions) that have to be executed via another public function to generate
the desired results.

The object implementation should include: (A) A _data volume_ , via structured
data models (e.g., MySQL), to persist the object’s state information. (B) A
_controller container_ for object management that has sole access to the data
volume and can change the object’s state. (C) One or more _worker containers_
, each one representing a function of the object.

###  V-C Latency-Aware Serverless Computing

In most current commercial serverless computing platforms, functions are
triggered without a specified deadline or urgency levels, thus, the scheduler
treats tasks with equal priorities. Meanwhile, if task urgency data are
mandated in the serverless computing platform, the task with low urgency can
be executed in batch in favor of more serverless efficiency (e.g., container
reuse as mentioned in Section III-D). Such urgency information is also helpful
for the caching and other components to determine their operational
priorities. Moreover, by detecting infeasible deadlines, the system can then
promptly approximate the task, rather than missing its deadline because of
exact computation. Another avenue of exploration is to identify the task
urgency automatically at the platform level and transparent from the user.

###  V-D Edge-to-Cloud Serverless Platform

The main benefits of serverless computing are the ease-of-use and abstracting
the users from resource provisioning details. While the current serverless
solutions are limited to cloud systems, it is desired to extend their benefits
to the emerging edge-to-cloud systems and hide the complexity of dealing with
multiple computing tiers (i.e., device, edge, fog, and cloud tiers) from the
user perspective. The platform can transparently determine the appropriate
tier for the function execution and can seamlessly migrate the the execution
from one tier to another to overcome the inherent resource scalability problem
of the edge systems [127]. These abilities can improve the system efficiency
and unlock new use cases. For instance, consider the use case of a blind
person who uses smart glasses and needs real-time process of observed objects
enters a coffee shop where few people are playing low-latency online games
using the available edge system. Upon arrival of the blind person, to make
room for the blind application, the game functions have to be live-migrated to
cloud, so that the gaming is not interrupted. The opposite can happen when the
blind person leaves the place.

A serverless platform for edge-to-cloud continuum extends the scope for
computational reusability and approximation to circumstances where a task-
result that is already cached in another tier can be fetched from there,
instead of executing it locally [128]. Another interesting reusing potential
that can be unleashed is in a scenario where edge devices forward common
(reusable) tasks to a central cloud, so that other edge tiers can reuse them
by fetching them from the cloud [129].

###  V-E Efficiency via Domain-Specific Serverless Cloud Computing

Along with the rise of domain-specific computing and ASICs hardware, domain-
specific programming languages are also emerging for popular applications,
such as machine learning, cryptography, multimedia processing, and even fluid
dynamics [130]. Within this trend, we envision that the next step will be the
emergence of domain-specific serverless cloud platforms for the popular
applications. A domain-specific serverless system will be equipped with
specialized hardware (ASICs), support of special-purpose programming
languages, and builtin domain-specific functions in its repository. Such
platforms will expedite the application development process and shorten the
CICD cycles. They will help users become solution-oriented and focus on their
specific business logic, rather than spending time on developing basic
services. In addition, they can support more flexible and application-specific
billing schemes (e.g., per successful transaction completion) with even
cheaper prices, due to using more efficient specialized hardware.

Importantly, a domain-specific serverless platform creates new scopes for
serverless efficiency, via specialized function reusing and approximation
techniques. For instance, a multimedia serverless cloud platform can harness
its builtin knowledge of spatiotemporal multimedia streaming patterns to
upraise the likelihood of function reusing.

###  V-F Cloud-Native Programming Languages

As the the second generation of cloud technology is evolving based on the
serverless paradigm and mitigating the programmers’ job, we envisage that the
technology is approaching the _cloud-native programming languages_ era. In
such programming languages, FaaS (and OaaS) concepts will be integrated into
the programming languages and compilers can natively support them. Like that,
functions can be defined as cloudable and seamlessly deployed on the cloud by
the compiler or auto-migrates to the cloud by the run-time system to overcome
the resource shortage or to achieve reusing and approximation. Moreover, these
languages can integrate the “programming code” with the “deployment code”
(a.k.a. infrastructure in code [131]) that are currently developed separately
and potentially by different people. In this manner, the program is analyzed
to automatically identify the infrastructure demands and deploy them on the
cloud.

These features of the forthcoming cloud-native programming languages will
democratize cloud programming, such that people without the cloud knowledge
can utilize them in their programs.

##  VI Summary

It is envisioned that the future generation of highly scalable applications
will predominantly rely on the serverless computing paradigm, hence,
comprehensively studying the anatomy of this paradigm and identifying the
scopes for efficiency can bring about major benefits to the users, developers,
and providers. Accordingly, in this paper, we explored the ways to make the
serverless computing paradigm efficient via investigating two main thrusts,
namely computational reuse and approximate computing. We started by
characterizing the internal mechanics and studying different dimensions of the
serverless systems. Then, we surveyed the current state of serverless and FaaS
solutions (summarized in Table I). Next, we categorized various approaches of
reusing and approximation, respectively. An overview of these approaches is
shown in Figure 6. In sum, we state that the characteristics of the serverless
paradigm, where functions are compact, single-purpose, and portable, creates a
unique scope for efficiency, mostly via computational reuse, and then via
approximate computing.

In this paper, we also outlined several potential directions that can push the
envelop of serverless paradigm towards the next generation of cloud computing
systems. In summary, four prominent directions that we discussed as the future
of serverless paradigm are as follows: (A) Enabling higher level abstractions
(e.g., Object-as-a-Service) in this paradigm; (B) Extending the serverless
platforms beyond cloud infrastructure to cover multi-tier edge-to-cloud
continuum; (C) Establishing domain-specific serverless clouds with specialized
reusing and approximation techniques; and (D) Extending the serverless
abilities towards cloud-native programming languages.

## Acknowledgments

We would like to thank the anonymous reviewers of the paper and members of the
HPCC Lab at UL Lafayette who brainstormed with us on this paper. This research
is supported by the National Science Foundation under award# CNS-2047144.

## References

  * [1] J. Schleier-Smith, V. Sreekanti, A. Khandelwal, J. Carreira, N. J. Yadwadkar, R. A. Popa, J. E. Gonzalez, I. Stoica, and D. A. Patterson, “What serverless computing is and should become: The next phase of cloud computing,” _Communications of the ACM_ , vol. 64, no. 5, pp. 76–84, 2021.
  * [2] P. G. Lopez, A. Slominski, M. Behrendt, and B. Metzler, “Serverless predictions: 2021-2030,” _arXiv preprint arXiv:2104.03075_ , 2021.
  * [3] C. Ebert, G. Gallardo, J. Hernantes, and N. Serrano, “Devops,” _Ieee Software_ , vol. 33, no. 3, pp. 94–100, 2016.
  * [4] S. Arachchi and I. Perera, “Continuous integration and continuous delivery pipeline automation for agile software project management,” in _Proceedings of the Moratuwa Engineering Research Conference_ , ser. MERCon ’18. IEEE, May 2018, pp. 156–161.
  * [5] W. Lloyd, S. Ramesh, S. Chinthalapati, L. Ly, and S. Pallickara, “Serverless computing: An investigation of factors influencing microservice performance,” in _Proceedings of the IEEE International Conference on Cloud Engineering_ , ser. IC2E ’18. IEEE, Apr. 2018, pp. 159–169.
  * [6] A. Agache, M. Brooker, A. Iordache, A. Liguori, R. Neugebauer, P. Piwonka, and D.-M. Popa, “Firecracker: Lightweight virtualization for serverless applications,” in _Proceedings of the 17th usenix symposium on networked systems design and implementation_ , ser. nsdi ’20, Aug. 2020, pp. 419–434.
  * [7] J. L. Carlson, _Redis in action_. Manning Publications Co., 2013.
  * [8] X. Li, M. A. Salehi, M. Bayoumi, N.-F. Tzeng, and R. Buyya, “Cost-efficient and robust on-demand video stream transcoding using heterogeneous cloud services,” _IEEE Transactions on Parallel and Distributed Systems (TPDS)_ , vol. 29, no. 3, pp. 556–571, Mar. 2018.
  * [9] J. Scheuner and P. Leitner, “Function-as-a-service performance evaluation: A multivocal literature review,” _Journal of Systems and Software_ , vol. 170, p. 110708, Dec. 2020.
  * [10] L. Wang, M. Li, Y. Zhang, T. Ristenpart, and M. Swift, “Peeking behind the curtains of serverless platforms,” in _Proceedings of the USENIX Annual Technical Conference_ , ser. USENIX ATC ’18, Jul. 2018, pp. 133–146.
  * [11] M. Shahrad, R. Fonseca, Í. Goiri, G. Chaudhry, P. Batum, J. Cooke, E. Laureano, C. Tresness, M. Russinovich, and R. Bianchini, “Serverless in the wild: Characterizing and optimizing the serverless workload at a large cloud provider,” _arXiv preprint arXiv:2003.03423_ , 2020.
  * [12] serverlessworkflow.io, “serverlessworkflow/specification,” online; Accessed on 20 August 2021. [Online]. Available: https://github.com/serverlessworkflow/specification/blob/main/specification.md#Workflow-Definition-Structure
  * [13] S. Burckhardt, C. Gillum, D. Justo, K. Kallas, C. McMahon, and C. S. Meiklejohn, “Serverless workflows with durable functions and netherite,” _arXiv preprint arXiv:2103.00033_ , 2021.
  * [14] R. S. Bird and P. L. Wadler, _Functional programming_. Prentice Hall, 1988.
  * [15] M. B. Josephs, “Functional programming with side-effects,” _Science of computer programming_ , vol. 7, pp. 279–296, 1986.
  * [16] S. Zobaed, M. E. Haque, M. F. Rabby, and M. A. Salehi, “Senspick: sense picking for word sense disambiguation,” in _Proceedings of the 15th IEEE International Conference on Semantic Computing (ICSC)_. IEEE, Jan. 2021, pp. 318–324.
  * [17] A. Jain, A. F. Baarzi, N. Alfares, G. Kesidis, B. Urgaonkar, and M. Kandemir, “Spiitserve: Efficiently splitting complex workloads across faas and iaas,” in _Proceedings of the ACM Symposium on Cloud Computing_ , ser. SoCC ’19, Nov. 2019, p. 487.
  * [18] Q. Pu, S. Venkataraman, and I. Stoica, “Shuffling, fast and slow: Scalable analytics on serverless infrastructure,” in _Proceedings of the 16th USENIX Symposium on Networked Systems Design and Implementation_ , ser. NSDI ’19, Feb. 2019, pp. 193–206.
  * [19] A. Klimovic, Y. Wang, P. Stuedi, A. Trivedi, J. Pfefferle, and C. Kozyrakis, “Pocket: Elastic ephemeral storage for serverless analytics,” in _Proceedings of the 13th USENIX Symposium on Operating Systems Design and Implementation_ , ser. OSDI ’18, Oct. 2018, pp. 427–444.
  * [20] V. Sreekanti, C. W. X. C. Lin, J. M. Faleiro, J. E. Gonzalez, J. M. Hellerstein, and A. Tumanov, “Cloudburst: Stateful functions-as-a-service,” _arXiv preprint arXiv:2001.04592_ , 2020.
  * [21] C. Wu, V. Sreekanti, and J. M. Hellerstein, “Autoscaling tiered cloud storage in anna,” _The VLDB Journal_ , pp. 1–19, Sep. 2020.
  * [22] J. Schleier-Smith, L. Holz, N. Pemberton, and J. M. Hellerstein, “A faas file system for serverless computing,” _arXiv preprint arXiv:2009.09845_ , 2020\.
  * [23] X. Yu, Y. Xia, A. Pavlo, D. Sanchez, L. Rudolph, and S. Devadas, “Sundial: harmonizing concurrency control and caching in a distributed oltp database management system,” _Proceedings of the VLDB Endowment_ , vol. 11, no. 10, pp. 1289–1302, Sep. 2018.
  * [24] V. Sreekanti, C. Wu, S. Chhatrapati, J. E. Gonzalez, J. M. Hellerstein, and J. M. Faleiro, “A fault-tolerance shim for serverless computing,” in _Proceedings of the 15th European Conference on Computer Systems_ , Apr. 2020, pp. 1–15.
  * [25] S. Shillaker and P. Pietzuch, “Faasm: Lightweight isolation for efficient stateful serverless computing,” _arXiv preprint arXiv:2002.09344_ , 2020\.
  * [26] G. McGrath and P. R. Brenner, “Serverless computing: Design, implementation, and performance,” in _Proceedings of the 37th IEEE International Conference on Distributed Computing Systems Workshops_ , ser. ICDCSW ’17. IEEE, Jun. 2017, pp. 405–410.
  * [27] A. Pérez, G. Moltó, M. Caballer, and A. Calatrava, “Serverless computing for container-based architectures,” _Future Generation Computer Systems_ , vol. 83, pp. 50–59, Jun. 2018.
  * [28] P. Mendki, “Evaluating webassembly enabled serverless approach for edge computing,” in _Proceedings of the IEEE Cloud Summit_. IEEE, Oct. 2020, pp. 161–166.
  * [29] krustlet.dev, “Kubernetes Rust Kubelet,” online; Accessed on 16 April 2021. [Online]. Available: https://github.com/deislabs/krustlet/
  * [30] G. Sayfan, _Mastering kubernetes_. Packt Publishing Ltd, 2017.
  * [31] O. C. Initiative, “About the Open Container Initiative,” accessed on 16 April 2021. [Online]. Available: https://opencontainers.org/about/overview/
  * [32] D. Ghatrehsamani, C. Denninnart, J. Bacik, and M. Amini Salehi, “The art of cpu-pinning: Evaluating and improving the performance of virtualization and containerization platforms,” in _Proceedings of the 49th International Conference on Parallel Processing_ , ser. ICPP ’20, Aug. 2020, pp. 1–11.
  * [33] S.-J. Cha, S. Jeon, R. Ramneek, J. Kim, Y. Jeong, and S. Jung, “Trends in unikernel and its application to manycore systems,” _Electronics and Telecommunications Trends_ , vol. 33, no. 6, pp. 129–138, 2018.
  * [34] L. Baresi, D. F. Mendonça, and M. Garriga, “Empowering low-latency applications through a serverless edge computing architecture,” in _Proceedings of the European Conference on Service-Oriented and Cloud Computing_. Springer, Sep. 2017, pp. 196–210.
  * [35] J. Gentry, C. Denninnart, and M. A. Salehi, “Robust dynamic resource allocation via probabilistic task pruning in heterogeneous computing systems,” in _Proceedings of the 33rd IEEE International Parallel and Distributed Processing Symposium_ , ser. IPDPS ’19. IEEE, Jun. 2019, pp. 375–384.
  * [36] F. Romero, M. Zhao, N. J. Yadwadkar, and C. Kozyrakis, “Llama: A heterogeneous & serverless framework for auto-tuning video analytics pipelines,” _arXiv preprint arXiv:2102.01887_ , 2021.
  * [37] nuclio.io, “Nuclio: Serverless Platform for Automated Data Science,” accessed on 16 April 2021. [Online]. Available: https://nuclio.io/
  * [38] nvidia, “CUDA Toolkit — Nvidia Developer,” online; Accessed on 29 Aug. 2021\. [Online]. Available: https://developer.nvidia.com/cuda-toolkit
  * [39] M. Abadi, P. Barham, J. Chen, Z. Chen, A. Davis, J. Dean, M. Devin, S. Ghemawat, G. Irving, M. Isard _et al._ , “Tensorflow: A system for large-scale machine learning,” in _Proceedings of the 12th USENIX symposium on operating systems design and implementation_ , ser. (OSDI ’16), Nov. 2016, pp. 265–283.
  * [40] T. K. G. Inc, “OpenCL Overview,” online; Accessed on 29 Aug. 2021. [Online]. Available: https://www.khronos.org/opencl/
  * [41] N. C. Thompson and S. Spanuth, “The decline of computers as a general purpose technology,” _Communications of the ACM_ , vol. 64, no. 3, pp. 64–72, 2021\.
  * [42] H. Zeng, Z. Zhang, and L. Shi, “Research and implementation of video codec based on ffmpeg,” in _Proceedings of 2nd International Conference on Network and Information Systems for Computers (ICNISC)_ , Apr. 2016, pp. 184–188.
  * [43] M. A. Salehi, J. Smith, A. A. Maciejewski, H. J. Siegel, E. K. Chong, J. Apodaca, L. D. Briceno, T. Renner, V. Shestak, J. Ladd _et al._ , “Stochastic-based robust dynamic resource allocation for independent tasks in a heterogeneous computing system,” _Journal of Parallel and Distributed Computing_ , vol. 97, pp. 96–111, 2016.
  * [44] S. Wu, C. Denninnart, X. Li, Y. Wang, and M. A. Salehi, “Descriptive and predictive analysis of aggregating functions in serverless clouds: the case of video streaming,” in _Proceedings of the 22nd IEEE International Conference on High Performance Computing and Communications_. IEEE, Dec. 2020, pp. 19–26.
  * [45] L. Torrey and J. Shavlik, “Transfer learning,” in _Handbook of research on machine learning applications and trends: algorithms, methods, and techniques_. IGI global, 2010, pp. 242–264.
  * [46] fission.io, “fission-workflow,” online; Accessed on 29 Aug. 2021. [Online]. Available: https://github.com/fission/fission-workflows
  * [47] Bitnami, “Kubeless,” online; Accessed on 29 Aug. 2021. [Online]. Available: https://kubeless.io/
  * [48] Iron.io, “Iron.io - DevOps Sp;itopm from Startups to Enterprise,” online; Accessed on 14 Mar. 2020. [Online]. Available: https://www.iron.io/
  * [49] Amazon, “AWS Lambda - Serverless Compute - Amazon Web Services,” online; Accessed on 10 May 2020. [Online]. Available: https://aws.amazon.com/lambda/
  * [50] ——, “AWS Step Functions— Serverless Microservice Orchestration — Amazon Web Services,” online; Accessed on 10 May 2020. [Online]. Available: https://aws.amazon.com/step-functions
  * [51] ——, “Serverless Compute Engine - AWS Fargate- Amazon Web Services,” online; Accessed on 10 May 2020. [Online]. Available: https://aws.amazon.com/fargate/
  * [52] Microsoft, “Azure Functions Serverless Compute — Microsoft Azure,” online; Accessed on 14 Mar. 2020. [Online]. Available: https://azure.microsoft.com/en-us/services/functions/
  * [53] G. Cloud, “Cloud Functions — Google Cloud,” online; Accessed on 14 Mar. 2020\. [Online]. Available: https://cloud.google.com/functions/
  * [54] IBM, “IBM Cloud Functions,” online; Accessed on 14 Mar. 2020. [Online]. Available: https://www.ibm.com/cloud/functions
  * [55] Microsoft, “Durable Functions Overview - Azure — Microsoft Docs,” online; Accessed on 29 Aug. 2021. [Online]. Available: https://docs.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-overview?tabs=csharp
  * [56] J. Li, S. G. Kulkarni, K. K. Ramakrishnan, and D. Li, “Analyzing open-source serverless platforms: Characteristics and performance,” _arXiv preprint arXiv:2106.03601_ , 2021.
  * [57] A. Ellis, “OpenFaaS – Serverless Functions Made Simple,” Online; Accessed on 4 October 2020. [Online]. Available: https://www.openfaas.com/
  * [58] A. S. Foundation, “Apache OpenWhisk is a serverless, open source cloud platform,” Online; Accessed on 4 October 2020. [Online]. Available: https://openwhisk.apache.org/
  * [59] D. Inc., “Docker Registry — Docker Documentation,” online; Accessed on 29 Aug. 2021. [Online]. Available: https://docs.docker.com/registry/
  * [60] Apache, “Apache Foundation,” online; Accessed on 29 Aug. 2021. [Online]. Available: https://www.apache.org/
  * [61] ——, “Apache Kafka,” online; Accessed on 29 Aug. 2021. [Online]. Available: https://kafka.apache.org/
  * [62] ——, “Apache CouchDB,” http://couchdb.apache.org/, online; Accessed on 29 Aug. 2021.
  * [63] I. F5, “NGINX — High Performance Load Balancerm Web Serverm & Reverse Proxy,” online; Accessed on 29 Aug. 2021. [Online]. Available: https://www.nginx.com/
  * [64] Apache, “Apache Zookeeper,” online; Accessed on 29 Aug. 2021. [Online]. Available: https://zookeeper.apache.org/
  * [65] fission.io, “Fission: Serverless Functions for Kubernetes,” online; Accessed on 29 Aug. 2021. [Online]. Available: https://github.com/fission/fission
  * [66] Oracle, “Fn Project - The Container Native Serverless Framework,” online; Accessed on 29 Aug. 2021. [Online]. Available: https://fnproject.io/
  * [67] ——, “Fn Flow,” online; Accessed on 29 Aug. 2021. [Online]. Available: https://github.com/fnproject/flow
  * [68] C. N. Foundation, “Knative,” online; Accessed on 08 Oct. 2021. [Online]. Available: knative.dev
  * [69] C. Foundation, “The Cloud Native Computing Foundation (CNCF) Survey,” online; Accessed on 4 Oct. 2021. [Online]. Available: https://www.cncf.io/wp-content/uploads/2020/11/CNCF_Survey_Report_2020.pdf
  * [70] K. Mahajan, D. Figueiredo, V. Misra, and D. Rubenstein, “Optimal pricing for serverless computing,” in _Proceedings of the IEEE Global Communications Conference_ , ser. GLOBECOM ’19. IEEE, Dec. 2019, pp. 1–6.
  * [71] A. R. Zamani, I. Petri, J. Diaz-Montes, O. Rana, and M. Parashar, “Edge-supported approximate analysis for long running computations,” in _Proceedings of the 5th IEEE International Conference on Future Internet of Things and Cloud_ , ser. Ficloud ’17. IEEE, Aug. 2017, pp. 321–328.
  * [72] L. Ma, S. Yi, N. Carter, and Q. Li, “Efficient live migration of edge services leveraging container layered storage,” _IEEE Transactions on Mobile Computing_ , vol. 18, no. 9, pp. 2020–2033, 2018.
  * [73] R. Urgaonkar, S. Wang, T. He, M. Zafer, K. Chan, and K. K. Leung, “Dynamic service migration and workload scheduling in edge-clouds,” _Performance Evaluation_ , vol. 91, pp. 205–228, 2015.
  * [74] C. Denninnart, “Cost-and qos-efficient serverless cloud computing,” _arXiv preprint arXiv:2011.11711_ , 2020.
  * [75] D. R. Krishnan, D. L. Quoc, P. Bhatotia, C. Fetzer, and R. Rodrigues, “Incapprox: A data analytics system for incremental approximate computing,” in _Proceedings of the 25th International Conference on World Wide Web_ , Apr. 2016, pp. 1133–1144.
  * [76] K. Ha, Z. Chen, W. Hu, W. Richter, P. Pillai, and M. Satyanarayanan, “Towards wearable cognitive assistance,” in _Proceedings of the 12th Annual International Conference on Mobile Systems, Applications, and Services_ , ser. MobiSys ’14, Jun. 2014, pp. 68–81.
  * [77] P. Guo and W. Hu, “Potluck: Cross-application approximate deduplication for computation-intensive mobile applications,” in _Proceedings of the 23rd International Conference on Architectural Support for Programming Languages and Operating Systems_ , Mar. 2018, pp. 271–284.
  * [78] T. Jiang, X. Chen, Q. Wu, J. Ma, W. Susilo, and W. Lou, “Secure and efficient cloud data deduplication with randomized tag,” _IEEE Transactions on Information Forensics and Security_ , vol. 12, no. 3, pp. 532–543, Mar. 2017.
  * [79] D. Arteaga, J. Cabrera, J. Xu, S. Sundararaman, and M. Zhao, “Cloudcache: On-demand flash cache management for cloud computing,” in _Proceedings of the 14th USENIX Conference on File and Storage Technologies_ , ser. FAST ’16, Mar. 2016, pp. 355–369.
  * [80] Y. Mao, E. Kohler, and R. T. Morris, “Cache craftiness for fast multicore key-value storage,” in _Proceedings of the 7th ACM European Conference on Computer Systems_ , Apr. 2012, pp. 183–196.
  * [81] C. Wallenta, J. Kim, P. J. Bentley, and S. Hailes, “Detecting interest cache poisoning in sensor networks using an artificial immune algorithm,” _Applied Intelligence_ , vol. 32, no. 1, pp. 1–26, 2010.
  * [82] Y. Tang and J. Yang, “Secure Deduplication of General Computations.” in _Proceedings of the USENIX Annual Technical Conference_ , ser. USENIC ATC’ 15, Jul. 2015, pp. 319–331.
  * [83] X. Wang, G. Li, X. Dong, J. Li, L. Liu, and X. Feng, “Accelerating deep learning inference with cross-layer data reuse on gpus,” in _Proceedings of the European Conference on Parallel Processing_ , ser. Euro-Par ’20. Springer, Aug. 2020, pp. 219–233.
  * [84] L. Popa, M. Budiu, Y. Yu, and M. Isard, “DryadInc: Reusing work in large-scale computations,” in _Proceedings of 1st USENIX workshop on Hot Topics in Cloud Computing_ , ser. HotCloud ’09, Jun. 2009.
  * [85] I. Casas, J. Taheri, R. Ranjan, L. Wang, and A. Y. Zomaya, “A balanced scheduler with data reuse and replication for scientific workflows in cloud computing systems,” _Future Generation Computer Systems_ , vol. 74, pp. 168–178, Sep. 2017.
  * [86] D. Tiwari and Y. Solihin, “MapReuse: Reusing computation in an in-memory mapreduce system,” in _Proceedings of the 28th IEEE International Parallel and Distributed Processing Symposium_ , ser. IPDPS ’14, May 2014, pp. 61–71.
  * [87] H. Zhang, M. Shen, Y. Huang, Y. Wen, Y. Luo, G. Gao, and K. Guan, “A serverless cloud-fog platform for dnn-based video analytics with incremental learning,” _arXiv preprint arXiv:2102.03012_ , 2021.
  * [88] Y. Wu, Y. Chen, L. Wang, Y. Ye, Z. Liu, Y. Guo, and Y. Fu, “Large scale incremental learning,” in _Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition_ , 2019, pp. 374–382.
  * [89] Z. Huang, S. Wu, S. Jiang, and H. Jin, “Fastbuild: Accelerating docker image building for efficient development and deployment of container,” in _Proceedings of the 35th Symposium on Mass Storage Systems and Technologies_ , ser. MSST ’19. IEEE, May 2019, pp. 28–37.
  * [90] N. Zhao, H. Albahar, S. Abraham, K. Chen, V. Tarasov, D. Skourtis, L. Rupprecht, A. Anwar, and A. R. Butt, “Duphunter: Flexible high-performance deduplication for docker registries,” in _Proceedings of the USENIX Annual Technical Conference_ , ser. USENIX ATC ’20, Jul. 2020, pp. 769–783.
  * [91] V. Rastogi, D. Davidson, L. De Carli, S. Jha, and P. McDaniel, “Cimplifier: automatically debloating containers,” in _Proceedings of the 11th Joint Meeting on Foundations of Software Engineering_ , Aug. 2017, pp. 476–486.
  * [92] N. Saurabh, J. Remmers, D. Kimovski, R. Prodan, and J. G. Barbosa, “Semantics-aware virtual machine image management in iaas clouds,” in _Proceedings of the IEEE International Parallel and Distributed Processing Symposium_ , ser. IPDPS ’19. IEEE, May 2019, pp. 418–427.
  * [93] S. Eismann, J. Scheuner, E. van Eyk, M. Schwinger, J. Grohmann, N. Herbst, C. Abad, and A. Iosup, “Serverless applications: Why, when, and how?” _IEEE Software_ , 2020.
  * [94] R. S. Kannan, L. Subramanian, A. Raju, J. Ahn, J. Mars, and L. Tang, “Grandslam: Guaranteeing slas for jobs in microservices execution frameworks,” in _Proceedings of the 14th EuroSys Conference_ , Mar. 2019, pp. 1–16.
  * [95] J. R. Gunasekaran, P. Thinakaran, N. C. Nachiappan, M. T. Kandemir, and C. R. Das, “Fifer: Tackling resource underutilization in the serverless era,” in _Proceedings of the 21st International Middleware Conference_ , Dec. 2020, pp. 280–295.
  * [96] S. Eismann, J. Scheuner, E. van Eyk, M. Schwinger, J. Grohmann, N. Herbst, C. L. Abad, and A. Iosup, “A review of serverless use cases and their characteristics,” _arXiv preprint arXiv:2008.11110_ , 2020.
  * [97] J. Redmon and A. Farhadi, “Yolov3: An incremental improvement,” _arXiv preprint arXiv:1804.02767_ , 2018.
  * [98] Y. Qu, H. Dai, Y. Zhuang, J. Chen, C. Dong, F. Wu, and S. Guo, “Serverless federated learning for uav networks: Architecture, challenges, and opportunities,” _arXiv preprint arXiv:2104.07557_ , 2021.
  * [99] S. Seneviratne and D. C. Levy, “Task profiling model for load profile prediction,” _Future Generation Computer Systems_ , vol. 27, no. 3, pp. 245–255, 2011.
  * [100] C. Tan, F. Sun, T. Kong, W. Zhang, C. Yang, and C. Liu, “A survey on deep transfer learning,” in _Proceedings of the International conference on artificial neural networks_ , Oct. 2018, pp. 270–279.
  * [101] H. Jayakumar, A. Raha, Y. Kim, S. Sutar, W. S. Lee, and V. Raghunathan, “Energy-efficient system design for iot devices,” in _Proceedings of the 21th Asia and South Pacific Design Automation Conference_ , ser. ASP-DAC ’16. IEEE, Jan. 2016, pp. 298–301.
  * [102] M. Satyanarayanan and D. Narayanan, “Multi-fidelity algorithms for interactive mobile applications,” _Wireless Networks_ , vol. 7, no. 6, pp. 601–607, 2001\.
  * [103] V. K. Chippa, S. T. Chakradhar, K. Roy, and A. Raghunathan, “Analysis and characterization of inherent application resilience for approximate computing,” in _Proceedings of the 50th Annual Design Automation Conference_ , May 2013, pp. 1–9.
  * [104] A. Rahimi, A. Ghofrani, K.-T. Cheng, L. Benini, and R. K. Gupta, “Approximate associative memristive memory for energy-efficient gpus,” in _Proceedings of the Design, Automation & Test in Europe Conference & Exhibition_, ser. Data ’15. IEEE, Mar. 2015, pp. 1497–1502.
  * [105] A. Hepworth, K. Tew, M. Trent, D. Ricks, C. G. Jensen, and W. E. Red, “Model consistency and conflict resolution with data preservation in multi-user computer aided design,” _Journal of Computing and Information Science in Engineering_ , vol. 14, no. 2, 2014.
  * [106] M. Samadi, D. A. Jamshidi, J. Lee, and S. Mahlke, “Paraprox: Pattern-based approximation for data parallel applications,” _ACM SIGPLAN Notices_ , vol. 49, no. 4, pp. 35–50, Apr. 2014.
  * [107] Z. Wen, P. Bhatotia, R. Chen, M. Lee _et al._ , “Approxiot: Approximate analytics for edge computing,” in _Proceedings of the 38th IEEE International Conference on Distributed Computing Systems_ , ser. ICDCS ’18. IEEE, Jul. 2018, pp. 411–421.
  * [108] C. Denninnart and M. A. Salehi, “Harnessing the potential of function-reuse in multimedia cloud systems,” _Transactions on Parallel and Distributed Systems (TPDS)_ , vol. 31, no. 3, pp. 617––629, 2021.
  * [109] A. Gupta, A. Bansal, and V. Khanduja, “Modern lossless compression techniques: Review, comparison and analysis,” in _Proceedings of the 2nd International Conference on Electrical, Computer and Communication Technologies_ , ser. ICECCT ’17. IEEE, Feb. 2017, pp. 1–8.
  * [110] X. Zheng, R. Zarcone, D. Paiton, J. Sohn, W. Wan, B. Olshausen, and H.-S. P. Wong, “Error-resilient analog image storage and compression with analog-valued rram arrays: an adaptive joint source-channel coding approach,” in _Proceedings of the IEEE International Electron Devices Meeting_ , ser. IEDM ’18. IEEE, Dec. 2018, pp. 3–5.
  * [111] J. Paulo and J. Pereira, “Distributed exact deduplication for primary storage infrastructures,” in _Proceedings of the 14th IFIP International Conference on Distributed Applications and Interoperable Systems_ , Jun. 2014, pp. 52–66.
  * [112] V. Balegas, S. Duarte, C. Ferreira, R. Rodrigues, N. Preguiça, M. Najafzadeh, and M. Shapiro, “Putting consistency back into eventual consistency,” in _Proceedings of the 10th European Conference on Computer Systems_ , Apr. 2015, pp. 1–16.
  * [113] P. Pokhilko, E. Epifanovsky, and A. I. Krylov, “Double precision is not needed for many-body calculations: Emergent conventional wisdom,” _Journal of chemical theory and computation_ , vol. 14, no. 8, pp. 4088–4096, 2018.
  * [114] S. Vogel, A. Guntoro, and G. Ascheid, “Efficient hardware acceleration for approximate inference of bitwise deep neural networks,” in _Proceedings of the Conference on Design and Architectures for Signal and Image Processing_ , ser. DASIP ’17. IEEE, Sep. 2017, pp. 1–6.
  * [115] R. Venkatagiri, A. Mahmoud, S. K. S. Hari, and S. V. Adve, “Approxilyzer: Towards a systematic framework for instruction-level approximate computing and its application to hardware resiliency,” in _Proceedings of the 49th Annual IEEE/ACM International Symposium on Microarchitecture_ , ser. MICRO ’16. IEEE, Oct. 2016, pp. 1–14.
  * [116] Z. Du, K. Palem, A. Lingamneni, O. Temam, Y. Chen, and C. Wu, “Leveraging the error resilience of machine-learning applications for designing highly energy efficient accelerators,” in _Proceedings of the 19th Asia and South Pacific Design Automation Conference_ , ser. ASP-DAC ’14. IEEE, Jan. 2014, pp. 201–206.
  * [117] A. Bookstein, V. A. Kulyukin, and T. Raita, “Generalized hamming distance,” _Information Retrieval_ , vol. 5, no. 4, pp. 353–375, 2002.
  * [118] H. Sim, S. Kenzhegulov, and J. Lee, “Dps: dynamic precision scaling for stochastic computing-based deep neural networks,” in _Proceedings of the 55th Annual Design Automation Conference_ , Jun. 2018, pp. 1–6.
  * [119] F. S. Snigdha, D. Sengupta, J. Hu, and S. S. Sapatnekar, “Optimal design of jpeg hardware under the approximate computing paradigm,” in _Proceedings of the 53nd ACM/EDAC/IEEE Design Automation Conference_ , ser. DAC ’16. IEEE, Jun. 2016, pp. 1–6.
  * [120] A. Yazdanbakhsh, D. Mahajan, B. Thwaites, J. Park, A. Nagendrakumar, S. Sethuraman, K. Ramkrishnan, N. Ravindran, R. Jariwala, A. Rahimi _et al._ , “Axilog: Language support for approximate hardware design,” in _Proceedings of the Design, Automation & Test in Europe Conference & Exhibition_, ser. DATE ’15. IEEE, Mar. 2015, pp. 812–817.
  * [121] D. Yin and T. Kosar, “Data-aware approximate workflow scheduling,” _arXiv preprint arXiv:1805.10499_ , 2018.
  * [122] A. Mokhtari, C. Denninnart, and M. A. Salehi, “Autonomous task dropping mechanism to achieve robustness in heterogeneous computing systems,” in _Proceedings of the 34th IEEE International Parallel and Distributed Processing Symposium Workshops_ , ser. IPDPSW ’20. IEEE, May 2020, pp. 17–26.
  * [123] C. Denninnart, J. Gentry, and M. A. Salehi, “Improving robustness of heterogeneous serverless computing systems via probabilistic task pruning,” in _Proceedings of the 33rd IEEE International Parallel and Distributed Processing Symposium Workshops_ , ser. IPDPSW ’19. IEEE, Jun. 2019, pp. 6–15.
  * [124] Amazon, “Fast NoSQL Key-Value Database - Amazon DynamoDB — Amazon Web Services,” online; Accessed on 08 Oct. 2021. [Online]. Available: https://aws.amazon.com/dynamodb
  * [125] ——, “AWS Serverless Application Model — Amazon Web Services,” online; Accessed on 08 Oct. 2021. [Online]. Available: https://aws.amazon.com/serverless/sam/
  * [126] ——, “Amazon RDS — Cloud Relational Database — Amazon Web Services,” online; Accessed on 08 Oct. 2021. [Online]. Available: https://aws.amazon.com/rds
  * [127] C. Li, J. Bai, Y. Ge, and L. Youlong, “Heterogeneity-aware elastic provisioning in cloud-assisted edge computing systems,” _Future Generation Computer Systems (FGCS)_ , vol. 112, pp. 1106 – 1121, 2020.
  * [128] V. Veillon, C. Denninnart, and M. A. Salehi, “F-fdn: Federation of fog computing systems for low latency video streaming,” in _Proceedings of the 3rd IEEE International Conference on Fog and Edge Computing_ , ser. ICFEC ’19, May 2019, pp. 1–9.
  * [129] M. Satyanarayanan, G. Klas, M. Silva, and S. Mangiante, “The seminal role of edge-native applications,” in _Proceedings of the IEEE International Conference on Edge Computing_ , ser. EDGE ’19. IEEE, Jul. 2019, pp. 33–40.
  * [130] K. F. A. Friebel, S. Soldavini, G. Hempel, C. Pilato, and J. Castrillon, “From domain-specific languages to memory-optimized accelerators for fluid dynamics,” in _Proceedings of the FPGA for HPC Workshop, held in conjunction with IEEE Cluster 2021_ , Sep. 2021.
  * [131] V. Tankov, D. Valchuk, Y. Golubev, and T. Bryksin, “Infrastructure in code: Towards developer-friendly cloud applications,” _arXiv preprint arXiv:2108.07842_ , 2021.