Serverless Execution Environment Reuse With Memory State Isolation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Serverless computing environments face performance penalties due to the ephemeral nature of execution environments, which are instantiated and released each time a function is triggered, leading to monetary losses and reduced isolation, especially in FaaS implementations.
Innovation Solution
Reusing execution environments for serverless functions while ensuring isolation by swapping memory locations for function states before and after execution to maintain isolation and integrity.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If execution environments are instantiated and released each time a function is triggered to provide isolation, then isolation and stability are improved, but response time and latency increase due to provisioning delays
Solution Approach 1:
The system performs preliminary actions by pre-warming execution environments before they are needed. The orchestrator proactively instantiates execution environments and loads function code in advance, so that when a function trigger occurs, the environment is already ready to execute, eliminating provisioning delays while maintaining isolation through environment swapping.
Solution Approach 2:
The system creates copies of execution environments that can be reused. Instead of releasing and recreating environments, the system maintains multiple isolated environment copies and swaps them between uses. This allows the same environment instance to serve multiple function executions while maintaining isolation through state resetting, thereby reducing response time without sacrificing reliability.
2Loss of time
If execution environments are reused to reduce provisioning delays, then response time is improved, but isolation and stability deteriorate due to potential state contamination
Solution Approach 1:
The system segments the execution environment into distinct components: the persistent environment infrastructure and the transient function state. By separating these, the system can reuse the environment infrastructure while isolating state through swapping mechanisms. The orchestrator manages multiple state snapshots, allowing the same environment to be reused with different isolated states, thus improving response time while maintaining reliability.
Solution Approach 2:
The orchestrator acts as an intermediary between function triggers and execution environments. It manages the swapping of execution environments and state restoration, ensuring that reused environments are properly isolated before each function execution. This intermediary layer coordinates environment lifecycle management, enabling reuse while preventing state contamination through controlled swapping and state restoration processes.
3Productivity
If execution environments are pre-warmed and reused, then productivity is improved by reducing latency, but device complexity increases due to environment management overhead
Solution Approach 1:
The orchestrator is designed as a universal management system that handles multiple functions: environment instantiation, code loading, state management, swapping, and lifecycle coordination. This multi-functional orchestrator consolidates complexity into a single management layer, enabling productive environment reuse without proportionally increasing overall system complexity. The same orchestrator infrastructure manages all aspects of environment reuse, improving productivity while containing complexity through consolidation.
Data Source
AI summary
Systems, methods, and computer-readable media are provided for reusing execution environments and code of serverless functions while ensuring isolation in serverless computing environments. In some examples, a method can include, in response to a first request to run a serverless function, executing, at an execution environment on a network, computer-readable code configured to perform the serverless function; after the computer-readable code has executed, modifying a pointer to an area of memory used to store a first state of the serverless function to reference a different area of memory; in response to a second request to run the serverless function, reusing, at the execution environment, the computer-readable code to perform the serverless function; and based on the pointer referencing the different area of memory, using the different area of memory to store a second state of the serverless function.