Serverless computing ofers a number of advantages over conventional, Virtual Machine (VM) based deployments on the cloud, e.g., greater elasticity, simplicity of use and management, finer granularity billing, and rapid deployment and start up times. Naturally, there is a growing interest in exploring how to run applications in this new environment and data analytics is not an exception. Unfortunately, current serverless platforms are limited along several dimensions, which makes things quite dificult from the perspective of data analytics. In this paper we explore what serverless has to ofer today, what is missing, and what can be done to make serverless a better computing platform in general and for data analytics in particular.
Function as a Service (FaaS) or serverless represents an
evolution of cloud computing services, where most of the
complexities associated with deploying, starting,
managing, maintaining, and retiring applications and their
associated resources are hidden behind a much simpler
interface. While the details of the commercial oferings
difer somewhat [
In practice, however, serverless means diferent things
depending on how one looks at it: as a user, as a cloud
provider, and as a researcher. These perspectives are
often not entirely aligned so we start by discussing each one
of them. We then provide some background about data
analytics on serverless before proposing an ambitious
research agenda around serverless in general and data
analytics on serverless in particular. This research agenda
takes into account the way the cloud has been
evolving and, importantly, the perspectives on the technology
from both the user and the cloud provider, an essential
aspect to make any proposal around serverless succeed.
larger deployments, providing a low cost and eficient ideas that will help to improve serverless as it evolves and
way to extend existing functionality. A running applica- also expand the use cases where serverless makes sense.
tion only needs to raise an event that triggers the creation However, serverless does not ofer a seamless transition
of functions that perform a given task and then disappear for applications such as data analytics.
when finished. Such a mechanism has been proposed As indicated above, current serverless oferings reflect
as a way to, e.g., provide higher elasticity to data pro- many of the needs of cloud providers while still giving
cessing platforms [
On the other hand, since serverless exposes a higher from a cost point of view, serverless makes sense only at
level of abstraction of the cloud to users, this gives very low throughput (on the order of a few tens of queries
providers the opportunity to better manage the infras- per hour). For more intense workloads, it is cheaper to
tructure by limiting the user’s control over many of the execute queries with standard data processing platforms
aspects of their application’s deployment. It is important on long-running VMs. The cost of serverless oferings is
to keep in mind that many applications and the way they a crucial decision of the provider. We can only speculate
run today in the cloud is a legacy of earlier years when why a unit of computation resources is significantly more
users ran applications on their own servers rather than expensive on serverless platforms than on conventional
on cloud services. The option of renting VMs (Infras- VMs. It could reflect the actual cost, in which case it
tructure as a Service) and many other existing services does not look good for heavy data analytics, or it could
in the cloud are there solely so that users can port their be just a way to prevent cannibalizing the VM business
application systems to the cloud. They are, by far, not the line. Whatever it might be, this is an important factor to
most eficient way to use the cloud. Serverless is a step keep in mind at this stage before investing large eforts in
towards removing part of that legacy and detaching the implementing data analytic platforms on top of current
application from the underlying infrastructure (hence serverless oferings.
the name) so that the infrastructure can be better shared Another approach tries to compensate for the
limitaamong multiple users, with better resource allocation, tions of serverless by building additional infrastructure
more control, tighter security, and less complexity to that replaces missing functionality and provides the
supboth the user and the provider. It is in this sense that port needed to run data analytics as it is understood
serverless has been regarded as the next evolutionary today. This includes creating caching layers to maintain
step in cloud computing [
predecessor services, it is necessarily bound by what is
3. Background available on the provider side and the need to support
an interface compatible with current applications. It
proServerless is part of the cloud and, as such, it cannot vides a higher level of abstraction compared to renting
be understood outside the context of cloud computing. some infrastructure (a machine, a VM, a piece of software)
Before presenting our view, we describe the aspects of and it hides a great deal of the complexities of the cloud
cloud architecture relevant to the discussion here. through automatic starts and shut-downs, automatic
elasticity, finer granularity billing, etc. It also simplifies the
3.1. On the Cloud choices available: instead of having to pick from an ever
growing catalogue of machine configurations and sizes,
Cloud computing has been evolving over the years to- current oferings limit the parameters available to the
wards higher levels of abstraction that hide more and user (e.g., just memory size as in AWS Lambda). Finally,
more of the underlying computing infrastructure [26]. it also restricts the execution environment, allegedly to
Hardware-as-a-Service, Platform-as-a-Service, Software- simplify the management of functions by the provider [
This development is heavily influenced by the ability connected to regular cloud services in the form of storof customers to move their workloads to the cloud. Since age, event management, or message queuing systems. applications evolve slower than hardware, it follows that However, these MicroVMs are still derived from their the cloud cannot make radical changes in its architec- original VM counterparts and do not represent a signifture and the platforms it ofers because otherwise users’ icant departure from them in terms of functionality or applications would not run on the cloud or would have interface. This is helpful for application compatibility but to be ported to the new environment made available by leaves significant opportunities for further performance the provider. Such migration exercises are expensive and and energy eficiency optimizations on the table. For excumbersome so the cloud has always tried to provide a ample, MicroVMs still have significant startup times [ 27], path to move applications with minimal changes. This context switching overheads [28], and memory duplicais why VMs have played and still pay such a crucial role tion [29]. Given the significant diferences in spirit and and why legacy systems like block storage or file systems level of abstraction of serverless, it is worth revisitng are still provided since otherwise there are applications whether the VM model is the correct one. As we will (notably database engines) that will simply not be able propose later, we think that it is not and a far more efito operate in the cloud. cient approach is possible when the underlying support
Yet, over the years, the cloud is evolving as the work- is built with a true serverless model in mind. This new
loads are better understood, cloud native systems start approach might not be adequate for legacy applications
to appear, and users get a better handle of running appli- but it will open up the way to implement serverless native
cations in the cloud. This evolution encompasses many applications.
aspects of the infrastructure: lightweight virtualization
for more eficient bin-packing of securely-isolated tasks 3.3. On Cloud Data Processing
(e.g., Firecracker [
As with many other services in the cloud, alternative designs have appeared that are better suited to the com- 2. From a provider perspective, how to improve the puting environment. Implicit in what we are discussing performance and resource eficiency of the serverin the paper is the idea that data analytics refers to dis- less infrastructure under the hood, which today tributed query processing. In all fairness, that is not is still rooted in a bloated system stack originally the only way to perform data analytics. There are the designed for long-running virtual machines? traditional database engines and data-warehouses, often These two questions are not orthogonal to each other. monolithic engines with limited scalability, less elasticity, Addressing the first one by providing the means to and not really suitable to the highly dynamic environ- run unmodified, existing distributed data processing ment of serverless functions. As pointed out above, these systems on serverless would start to provide insights engines already have issues when operating in the cloud to inform future platform designs. It would also help and it is dificult to see how they could fit on top of server- identify which features of these systems collide with the less. Distributed query processing uses engines diferent serverless model. This information can then be used from traditional ones (e.g., Snowflake [ 30]) or discards to change the way serverless is implemented and the the notion of an engine entirely (e.g., Spark, Hadoop, or interfaces the platform exposes to the application, so that MapReduce can run queries at large scales but are not the second challenge can be addressed while enabling engines in the sense that they do not actually manage a richer and more suitable interface to developers the data in the way a database engine does). The gap of serverless applications in general and serverless between legacy systems and what can be actually run on analytics in particular. the cloud, together with the ever growing demand for data management support, has also led to a proliferation To address the first challenge, we propose to build an of cloud native data management and processing engines overlay system on top of the serverless platform that for a variety of applications and data types. abstracts the FaaS infrastructure and provides the fa
Serverless data analytics is at the same junction as miliar POSIX-like environment of networked processes
database engines were with the cloud. Conventional data that existing distributed data analytics expect. This
apwarehousing architectures are ill suited to the serverless proach should enable running existing of-the-shelf data
model and, conversely, current serverless platforms are analytics engines on serverless platforms. The overlay
less than supportive of large scale data processing [19, 20, system is responsible for filling the gap in
functional21]. One can come up with many diferent ways to try to ity that the application expects (e.g., a distributed data
build analytics engines on serverless today but our own engine like Spark expects to be able to exchange data
experience shows it is a never ending exercise with often directly over the network between workers) and what
only less than optimal options to choose from. If data the underlying serverless platform supports (e.g., AWS
analytics is ever going to run on serverless, a redesign Lambda and other commercial oferings today do not
exfrom the ground up is necessary. In the next section pose direct support for inter-function networking). The
we discuss how such a redesign could look like and its overlay will have to perform several tasks to turn current
serverless functions into something equivalent to regu- isolation. Treating functions as true functions (which
lar VMs. Some of these tasks include: (1) intercepting do not need to interact directly with the OS during their
system calls and redirecting them as needed so that appli- execution) enables adopting more lightweight sandbox
cation code that operates thinking it is running over an designs, which can leverage emerging software and
hardOS or a VM does not need to be modified; (2) establishing ware isolation mechanisms, such as WebAssembly-based
a group of communicating functions that will run the Software Fault Isolation [
Since the starting point is to better understand server- DAG makes no diference) and the inputs and outputs of less analytics by enabling current systems to run on each stage are easily specified in a declarative manner. serverless platforms, we are addressing the first challenge To a large extent, the serverless infrastructure can take by building a prototype of the overlay on top of a current advantage of the declarative nature of the I/O in funccommercial serverless ofering (AWS Lambda). However, tions to implement optimizations tasks that a traditional to address the second challenge (i.e., improve the perfor- database engine performs: pre-fetching, caching, partial mance and resource eficiency of serverless computing result reusing, view materialization, locality aware funcservices), it is necessary to rethink the function execution tion scheduling, etc.; all tasks that are today missing from model and system software stack of current serverless distributed data processing tools. platforms. Hence, as a next step, we propose a new platform design. Importantly, by still leveraging the overlay on top of the platform, the changes we propose to the 5. An Overlay on Serverless platform system software can be implemented transparently to user applications. The motivation to build an overlay on top of current
To address the second challenge, we propose to move serverless platforms arose from the experience
accumuaway from AWS Lambda’s approach of executing func- lated trying to do query processing on serverless. While
tions as MicroVMs. Instead, we advocate to treat server- designing Lambada [21], looking at results from other
less functions as true functions: bodies of code which groups [
The separation of computation and I/O has several of those are properties of analytic queries where
operakey advantages. First, compute tasks can be supported tors create dependencies between the diferent stages of
without the need for system calls, since the platform can the computation, there is a well defined and potentially
prepare data for each function in a dedicated memory complex dataflow defining how and when to invoke the
region before the function starts executing. Avoiding sys- operators, and exchange potentially large amounts of
tem calls removes a large attack surface of the untrusted intermediate results.
user code and allows the platform to move away from Focusing on the obvious limitation of today’s
oferthe traditional VM-based isolation technologies, which ings that forces data exchanges to occur through
storintroduce significant software bloat to provide secure age (S3 in AWS Lambda), we have developed an initial
prototype (Boxer 1.0) of the overlay that addressed ba- High throughput per machine: The platform
sic communication between functions [38]. Using well should serve a high rate of function invocations per
known NAT-punching techniques, Boxer 1.0 was able physical machine (i.e., dense bin-packing) to maximize
to establish TCP-IP connections between functions and throughput at low cost.
enabled us to implement distributed query processing as The current platforms ofered by cloud providers like
done in Lambada but without having to write and read AWS, Google, and Microsoft Azure try to satisfy these
reto storage between stages of the query. This initial proto- quirements based on lightweight VMs or secure
containtype showed the advantages of a more flexible serverless ers [
Encouraged by that initial prototype, we have contin- virtual machines and processes. Current platforms
inued development towards Boxer 2.0, a more extensive troduce high overhead when executing many fine-grain,
implementation that incorporates not only the ability to short-lived tasks at high churn [
We are in the process of porting a variety of data separation, functions now consist of pure computations
processing engines to Boxer 2.0. Doing so enables us and I/O is handled by the platform before/after function
to explore interesting ideas around serverless analyt- execution. The platform provides each function with a
ics like automatic instantiation of query engines on a dedicated memory region prepared with the function’s
per query basis [39]. But more importantly for the pur- inputs and the function does not do any I/O (or in fact
poses here, Boxer 2.0 allows us to start running diferent any system calls) during its execution. Avoiding system
query engines on serverless to identify how they need calls removes a large attack surface (VMs are used today
to be changed to take advantage of the unique features as an isolation mechanism since the OS itself is
considof serverless and also to study how the interface ofered ered too large of a TCB to securely isolate functions from
by serverless can be improved to better facilitate data untrusted users [
Although our first step is prototyping Boxer on top of leverage lighter weight isolation mechanisms optimized existing commercial serverless platforms, such as AWS for performance (e.g., WASM [31], MPK [33], and CHERI Lambda, we next plan to explore how to continue pro- memory capabilities [34]) rather than defaulting to the viding the familiar abstractions that traditional data an- legacy approach of executing each function in a separate alytics engines expect while evolving the underlying virtual machine, bundled with its own operating system. platform under the hood for greater performance and We are currently building a prototype of a serverless resource eficiency. platform, Dandelion, which adopts this declarative function execution model. We design the system software to eficiently schedule functions and execute them with 6. A New Serverless Platform support for a variety of hardware and software isolation mechanisms under the hood through a unified abstracA serverless platform must meet several requirements tion. In our initial prototype, we leverage CHERI memfrom a provider perspective, requirements that also have ory capabilities [34] to isolate function memory regions an impact on how the platform is perceived by users: while running the Dandelion system infrastructure and
Secure isolation: The platform must prevent un- compute functions within a single virtual address space. trusted user code from tampering with the infrastructure We compare Dandelion’s performance to a Firecracker or accessing the data or code of other users.1 system running functions in separate MicroVMs. We
Low latency: A function should complete with low sweep function invocations for each system, with each (ideally ≤ 10%) overhead compared to its execution on a function executing a matrix multiplication computation. dedicated, bare-metal server. Our initial results show that Dandelion achieves 3.4× higher peak throughput per machine and over 14× lower 1Wthee apsrsouvmideerthdeoteyspnicoatltcrluosutducsoerms,puusteinrsg dthorneaott mtroudstele[a4c0h],oitnhewr,hbicuht latency compared to Firecracker. users trust the cloud provider. In addition to enabling lightweight function sandbox 7. Discussion technology for low latency and high-density bin-packing processing systems today. Current systems do not run on without compromising secure isolation, the declarative an actual engine in the sense that systems such as Spark function execution model ofers cloud providers addi- do not maintain permanent data structures and functiontional opportunities to optimize the underlying infras- ality (indexes, lock tables, access statistics, schema, views, tructure. A major benefit of declaring applications as access controls, etc.) across executions. Thus, they do compositions of compute functions (containing untrusted not perform common database optimizations. user code) and I/O tasks (handled by the platform) is that In addition to running of-the-shelf engines on the application dataflow becomes explicit and directly ex- overlay, an optimized platform like Dandelion enables posed to the platform. The cloud provider can leverage building data processing engines directly on top of the information about how data flows between functions declarative function execution model interface, as opand cloud data services to prefetch function inputs and posed to through the overlay. Through the declarative avoid functions wasting CPU cycles while waiting for specification of I/O, function scheduling can be enhanced data by guaranteeing that a function only starts execut- with features such as data pre-fetching from storage if ing when its inputs are available [42]. The provider can that is where the data resides so when the function starts, also leverage dataflow information in applications for the data has already been brought to it. This would siglocality-aware scheduling, i.e., collocating functions that nificantly speed up running, e.g., a join of a base table exchange data on the same nodes. with the intermediate results produced by another join of
Finally, the declarative function execution model and other tables. Similarly, it should be possible to implement strict separation of compute and I/O also lends itself well diferent query execution models beyond the batch mode to hardware acceleration. User functions become easier enforced by today’s serverless platforms. Direct commuto ofload to hardware accelreators such as GPUs when nications should enable vectorized and even volcano style they are pure functions that do not rely on close interac- execution models that are far more suitable to modern tion with the host OS. We also plan to explore ofloading analytics and have much better performance. Providing the I/O tasks performed by the platform to SmartNICs. such functionality would make serverless an excellent We believe this declarative execution model under the vehicle to implement a completely new generation of hood of a serverless platform is a promising way to lever- data analytic engines where the system functionality is age heterogeneous hardware, while the overlay presented directly embedded in the computational model. Such in Section 5 can maintain a convenient abstraction for an architecture is likely to improve performance while user applications. allowing the provider to optimize internal bottlenecks in the cloud like the latency of accessing disaggregated storage or network congestion.
could influence serverless data analytics. We also discuss the interplay between an overlay system like Boxer and our ideas around Dandelion about how to optimize the underlying serverless infrastructure.
What we are proposing, even in the initial use case where we run existing, unmodified query platforms on top of serverless functions, brings query processing closer to the notion of query-as-a-service. As discussed elsewhere [39], the approach makes it possible to create a distributed query engine when a query arrives and dismantle it when it finishes. The resulting functionality is very similar to that of services such as Amazon Athena [43] or Google Big Query [44] except that the user can select the engine where the query runs.
When considering the modified serverless platform we have in mind, the opportunity arises to turn the serverless platform into an actual data processing engine providing much of the functionality missing on distributed query
Data analytics has many decades of experience on optimizing queries, predicting cardinalities, calculating costs of operations, etc. Many of these advantages are lost when operating on the distributed query processing settings found in the cloud today. This leads, in several subtle ways, to a number of ineficiencies that need to be addressed. Among them, the most relevant is overprovisioning: reserving a much larger set of resources than actually needed just in case, e.g., a load spike arrives. Overprovisioning afects all aspects of the system: memory, CPU capacity, number of machines, etc.
For instance, stranded memory [45] results from machines running out of virtual CPUs to allocate before they run out of memory. It is tempting to think that the current configuration of functions based solely on the memory size could be related to this provider-side problem. In the serverless data analytics view we propose, the problem could be addressed diferently: apply traditional query optimization techniques and knowledge of the operators to estimate the amount of memory a function will need to execute. This would yield a far more accurate allocation of resources on a per-query basis and, as a result, a lower budget for running queries than when the size of the functions is chosen on a worst case scenario basis.
Similarly, the notion of declarative interfaces at the function level can be used beyond I/O and be applied to networking and communication. Rather than using sockets as the current Boxer prototypes does, functions would specify a number of other functions and the required topology that the underlying system would automatically instantiate as needed. This opens up the opportunity for the provider to optimize the location of the functions, reuse them when possible, collocate them in the same machine if the opportunity arises, etc. It is not dificult to see how this would benefit parallel query execution and minimize data movement while still preserving the elasticity of serverless and hiding of the underlying infrastructure form the user.
Finally, the declarative nature of functions we propose would support the automatic creation and management of caching layers. The system can observe the declarations of function compositions and and decide which data can be moved to a faster storage layer (whether in memory, on a dedicated key value store, or even in accelerated storage) for faster access if used often enough.
to a radically diferent function execution system like Dandelion will involve exploring how to develop applications under the new interface. In our current prototype of Dandelion, we develop a domain specific language for developers to directly express their applications as compositions of pure compute and platform library I/O functions. However, in the future, we aim to explore how of-the-shelf applications can be automatically transpiled to compositions that strictly separate their compute and I/O tasks under the hood.
Running arbitrary legacy applications on Dandelion can be a challenge but less so for data processing and data analytics. Note that the declarative I/O model closely resembles the execution model of database engines with operators implementing the logic to be applied to supplied by a pre-defined execution model and interface (i.e., volcano, vectorized, or batched). To a first approximation, queries can be expressed as a DAG of functions that are connected through well defined I/O interfaces. An interesting research direction is to define such interfaces so that they fulfill the requirements of the serverless infrastructure while facilitating the execution of distributed query processing. Nevertheless, the ultimate goal of our vision for serverless is to have native engines that take full advantage of the new model rather than being anchored on architectures more suitable for conventional deployments on servers or VMs.
In this short paper we have put forward an alternative view on serverless that accommodates the perspectives of both the users and the providers. It defines a path of migration for existing distributed query processing systems to serverless and proposes a redesign of the interface ofered to function code that truly hides the underlying execution platform. The idea is not exclusive to data analytics but we have show how data processing, even being an application ill suited for serverless, can greatly benefit from this alternative view.
The systems we are developing should help to inform how to better support data analytics on serverless by enabling running of-the-shelf systems on today’s platforms. At the same time, the experience gathered from these initial experiments will help better define what the serverless infrastructure should become, to eliminate a lot of the legacy and bloat present in current systems, and provide an interface that unleashes all the potential of serverless as the next generation of cloud computing. [33] S. Park, S. Lee, W. Xu, H. Moon, T. Kim, libmpk: [39] M. Wawrzoniak, R. Bruno, A. Klimovic, G. Alonso, Software abstraction for intel memory protection Ephemeral per-query engines for serverless analytkeys (intel MPK), in: 2019 USENIX Annual Techni- ics, in: 1st Workshop on Serverless Data Analytics cal Conference (USENIX ATC 19), 2019. (SDA’23) at VLDB 2023, 2023. [34] R. N. Watson, J. Woodruf, P. G. Neumann, S. W. [40] Amazon Web Services, Security overview of Moore, J. Anderson, D. Chisnall, N. Dave, B. Davis, AWS Lambda, https://docs.aws.amazon.com/ K. Gudka, B. Laurie, S. J. Murdoch, R. Norton, whitepapers/latest/security-overview-aws-lambda/ M. Roe, S. Son, M. Vadera, Cheri: A hybrid security-overview-aws-lambda.html, 2021. capability-system architecture for scalable software [41] E. G. Young, P. Zhu, T. Caraza-Harter, A. C. Arpacicompartmentalization, in: 2015 IEEE Symposium Dusseau, R. H. Arpaci-Dusseau, The true cost of on Security and Privacy, 2015. containing: A gVisor case study, in: 11th USENIX [35] J. Jiang, S. Gan, Y. Liu, F. Wang, G. Alonso, Workshop on Hot Topics in Cloud Computing (HotA. Klimovic, A. Singla, W. Wu, C. Zhang, Towards Cloud 19), 2019. demystifying serverless machine learning training, [42] Y. Deng, A. Montemayor, A. Levy, K. Winstein, in: Proceedings of the 2021 International Confer- Computation-centric networking, in: Proceedings ence on Management of Data, 2021, p. 857–871. of the 21st ACM Workshop on Hot Topics in Net[36] Y. Wu, T. T. A. Dinh, G. Hu, M. Zhang, Y. M. Chee, works, HotNets ’22, 2022.
B. C. Ooi, Serverless data science - are we there yet? [43] Amazon Athena, 2023. URL: http://docs.aws. A case study of model serving, in: SIGMOD ’22: amazon.com/athena/, visited 2023-08-9. International Conference on Management of Data, [44] Google BigQuery, 2023. URL: https://cloud.google.
Philadelphia, PA, USA, June 12 - 17, 2022, 2022. com/bigquery/, visited 2023-08-9. [37] S. Fouladi, F. Romero, D. Iter, Q. Li, S. Chatterjee, [45] H. Li, D. S. Berger, L. Hsu, D. Ernst, P. Zardoshti, C. Kozyrakis, M. Zaharia, K. Winstein, From laptop S. Novakovic, M. Shah, S. Rajadnya, S. Lee, I. Agarto lambda: Outsourcing everyday jobs to thousands wal, M. D. Hill, M. Fontoura, R. Bianchini, Pond: of transient functional containers, in: USENIX ATC, Cxl-based memory pooling systems for cloud plat2019. forms, in: Proceedings of the 28th ACM Interna[38] M. Wawrzoniak, I. Müller, R. Bruno, G. Alonso, tional Conference on Architectural Support for ProBoxer: Data analytics on network-enabled server- gramming Languages and Operating Systems, Volless platforms, in: CIDR, 2021. ume 2, ASPLOS 2023, 2023.