Serverless Execution Environment Reuse with Memory State Swapping

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Serverless computing in FaaS environments faces performance penalties due to the ephemeral nature of execution environments, which leads to increased latency and monetary losses, as well as reduced isolation and potential vulnerabilities from reusing execution environments without proper state management.

Innovation Solution

Implementing a method to reuse execution environments for serverless functions while ensuring isolation by swapping and refreshing memory states, using a pointer to reference different areas of memory for each function execution, thereby maintaining performance benefits and preventing unauthorized access or corruption.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Loss of time

If execution environments are reused without provisioning on demand, then performance improves (reduced latency), but isolation and stability deteriorate

Engineering Contradiction:

ImprovelatencyVSAvoidisolation

Core Design Contradiction:

Loss of timeVSReliability

Solution Approach 1:

The execution environment is segmented into reusable infrastructure components and isolated state components. The state is separated into function-specific data that must be isolated and general execution context that can be reused. This allows the same execution environment to serve multiple function invocations while maintaining proper isolation through state separation.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

A state management intermediary layer is introduced between the reusable execution environment and the function code. This intermediary handles state initialization, preservation, and isolation, allowing the execution environment to be reused while ensuring each function invocation has its own isolated state through mechanisms like state snapshots or memory isolation.

Inventive Principle:

Principle #24Intermediary (Mediator)

2Reliability

If execution environments are provisioned on demand, then isolation and stability improve, but performance deteriorates (increased latency)

Engineering Contradiction:

ImproveisolationVSAvoidlatency

Core Design Contradiction:

ReliabilityVSLoss of time

Solution Approach 1:

Execution environments are pre-provisioned and kept in a ready state before function invocations occur. The infrastructure is prepared in advance with all necessary runtime components loaded, so when a function needs to execute, the environment is already available and can be quickly activated without full provisioning delays.

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

The state of execution environments is dynamically adjusted between reusable and isolated based on invocation needs. The system changes parameters such as state initialization status, memory allocation, and component activation levels to optimize between performance (reused state) and isolation (fresh state) depending on the specific function invocation context.

Inventive Principle:

Principle #35Parameter changes

3Loss of energy

If execution environments are reused, then computational expenses reduce, but security and stability deteriorate due to potential tainting

Engineering Contradiction:

Improvecomputational expensesVSAvoidtainting

Core Design Contradiction:

Loss of energyVSObject-affected harmful factors

Solution Approach 1:

Function-specific state is discarded after each invocation while preserving the reusable execution environment infrastructure. The state that could be tainted is selectively discarded and recovered in a clean state for the next invocation, allowing the expensive infrastructure to be reused without carrying over potential security contaminants.

Inventive Principle:

Principle #34Discarding and recovering

Solution Approach 2:

Instead of reusing the same state directly, the system creates isolated copies or snapshots of necessary state data for each function invocation. This copying mechanism ensures that even if the underlying execution environment is reused, each function operates on its own clean copy of state data, preventing tainting while maintaining performance benefits.

Inventive Principle:

Principle #26Copying

Data Source

PatentUS11323516B2Reuse of execution environments while guaranteeing isolation in serverless computing

Publication Date: 2022.05.03 CISCO TECHNOLOGY INC

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.