Abstract
Fine-grained serverless functions power many new applications that benefit from elastic scaling and pay-as-you-go billing models while minimizing infrastructure management overhead. To achieve these characteristics, Functions-as-a-Service (FaaS) platforms separate computation from state, and PraaS improves upon current FaaS by providing data locality, fast invocation, and efficient communication.
1 Introduction
The separation of data and computation in serverless architectures is fundamentally inefficient and cannot be solved by combining FaaS with additional remote cloud systems. Instead, we introduce a new abstraction: cloud processes. Similar to operating system processes that use threads for concurrent computation, a cloud process runs on a single machine and launches functions in a shared environment (where a single function call is equivalent to a single threaded operating system call). The process provides a persistent state that the function can use to cache stored data, retain user sessions, cache results, and save invocation artifacts, PraaS follows traditional OS design and transparently exchanges state consisting of user-defined persistent objects and files stored on disk and cloud storage. The state is loaded into memory on a delayed basis once instances of the same process become active. Inter-process communication defines a simple yet powerful messaging interface based on just two operations: send and receive
2 MOTIVATION
2.1 Serverless State
The stateless nature of FaaS makes it easier for cloud providers to scale and manage resources, but at the same time limits the efficiency of accessing stateful data. Because compute resources are temporary and cannot retain data across calls, many applications that require state must store data in remote cloud storage, which increases latency and decreases performance. Methods exist for preserving data through an automatically managed cache, but these methods only support remote storage and are not applicable to cold starts. In addition, researchers have optimized call locality through grouping and data flow models, but they can only hold data in hot instances and do not address the problem of data loss during shrinkage.
2.2 Serverless Communication
Communication in FaaS has been limited because industrial products don't provide direct communication, forcing users to rely on storage or proxy communication - an expensive solution with high latency and a lack of portable APIs
2.3 Serverless Control and Data Planes
Modern serverless platforms use centralized routing systems to manage the dynamic placement of functions, such as AWS Lambda and OpenWhisk. invocation requests go through multiple steps, including authorization, resource allocation, and routing. Each request must pass through multiple intermediary steps such as front-end servers, controllers, and load balancing, adding latency and complexity, and in the current FaaS model, the function container is "exclusive" to the request until processing is complete, and is unable to receive new requests. While this model is suitable for compute-intensive tasks, it is not efficient for I/O-intensive tasks.
3 CLOUD PROCESSES
The first diagram depicts the structure of a PraaS cloud process, and the second diagram shows the lifecycle of a cloud process, including transitions to different states
3.1 Locality with State
State semantics: a portion of the state of a process needs to be retained locally to ensure low access latency. Persistent data does not disappear when the process sandbox is removed. Functions in a process can share state objects to improve data locality and enable caching, thus reducing request processing time and data reloading costs.
Single-tenant design: PraaS processes are designed to be single-tenant, with all functions sharing the same state data. Functions that handle different user data need to be logically isolated to ensure security and data isolation.
Swapping Mechanism: PraaS introduces a state-swapping mechanism, whereby when a process is idle or needs to release resources, its state is swapped to persistent storage, but still retains the possibility of activation. When the process is reactivated, the state can be loaded back. This mechanism allows processes to restore state when needed without adding to the limitations of the traditional serverless model.
3.2 Invocations with Control and DataPlanes
The simplicity of FaaS relies on auto-scaling, where processes must support the same model for applications that do not have a customized scheduling policy. Thus, functions can be invoked through the control plane, and the call request can provide a process ID to prompt the system as to which process to assign the call to. Orchestrators and load balancers can invoke functions more efficiently by sending payloads through the data plane (inter-process communication), and the underlying assumption behind our process is that it will never scale beyond a single server, as this design radically simplifies the handling of memory and state
3.3 Process Model with Communication
Compared to FaaS, functions executed in cloud processes benefit from local state and fast communication using only six new primitives (Listing 1). We define two message-passing routines to realize all communication tasks handled by the process
4 PRAAS: PROCESS–AS–A–SERVICE
4.1 Process Managemen
In PraaS, processes are grouped together to create scalable applications that span multiple servers, and unlike FaaS, users can control the routing of calls to selected process instances by providing the process identifier pid in the request header. Processes can therefore be used to realize sticky sessions, where a single user's request is always handled by the same process.
4.2 Inter-Process Communication
PraaS provides efficient and decentralized communication by binding mailboxes and channels to process instances. Within the application, processes are aware of each other's existence and can communicate directly. Instead of moving data between functions through a cloud proxy, data is transferred between the cloud processes hosting the functions that wish to communicate, thus improving performance and reducing network traffic
4.3 Function Invocations over Data Plane
In FaaS, operations such as authorization, resource allocation, and redirection are typically required for each invocation, resulting in repetitive control operations. These control operations can be redundant when multiple requests enter the same hot container.PraaS utilizes the data plane to deliver calls directly to the target process, skipping unnecessary control steps. The payload is delivered directly from the user to the process mailbox, reducing latency and increasing call throughput, and PraaS supports complex serverless workflows such as function linking, conditional calls, and input batch processing. Traditional FaaS requires external orchestrators and service triggers to handle these complex interactions.
5 PRAAS IN PRACTICE
Main prototype implementation: PraaS is implemented via a custom control plane running on AWS Fargate, which provides on-demand serverless containers that allow for the attachment of public IP addresses, which are critical for direct communication. This implementation contains approximately 11,500 lines of C++ and Python code with additional process support using the Python runtime. Internal communication is via TCP for binary serialized messages, using the C++ SDK to simplify data-plane and control-plane communication.
Kubernetes Implementation: To further demonstrate compatibility, PraaS is extended to Kubernetes and Knative. in this implementation, the control plane manages processes as pods and stores application and process information in a Redis instance. The shrinkage policy is then based on a threshold of data plane activity, rather than randomly terminating containers. In addition, the communication layer of PraaS is based on a WebSockets implementation and introduces a function storage mechanism that allows users to upload functions as Python wheels and install them dynamically in the process.
EVALUATION
Latency Test: Evaluates the latency of function calls, comparing the latency performance of PraaS and AWS Lambda for remote and local calls.
Process State Access Speed Test: Tests the access speed of PraaS's local persistent state and compares it to the access speed of Redis and S3 storage. Test scenarios include data write and read operations
LaTeX Microservices Case Test: Simulates an Overleaf-like LaTeX microservices environment to compare the performance of PraaS and Lambda. The test focuses on how the local state of PraaS improves the speed of incremental compilation, as well as efficiency during file fetching.
Machine Learning K-Means Algorithm Testing: Apply PraaS to the K-Means algorithm for distributed machine learning and test its performance under large data interactions. Compare the data transfer and processing speeds of PraaS and Knative, with a particular focus on PraaS' ability to reduce reliance on external storage.