On-demand code execution data management

Abstract

Systems and methods are provided for managing provisioning and access to datasets between instances of function code executing in an on-demand manner. An API is provided by which a function may store a data set to be shared with other functions, and by which a function may access a data set shared by other functions.

Description

[0001] Incorporated by Reference

[0002] The following application is incorporated herein by reference and becomes a part of this specification: U.S. patent application No. 17 / 935,900 filed on September 27, 2022 and entitled “ON-DEMAND CODE EXECUTION DATA MANAGEMENT”. Background Art

[0003] A computing system may utilize a communication network to exchange data. In some implementations, a computing system may receive and process data provided by another computing system. For example, a computing system receives data input using another computing system, stores data, processes data, and the like. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] Embodiments of various inventive features will now be described with reference to the following drawings. Throughout the drawings, reference numerals may be reused to indicate the corresponding relationship between the elements referred to. The drawings are provided to illustrate the example embodiments described herein and are not intended to limit the scope of the present disclosure. To easily identify the discussion of any particular element or action, the most significant digit in the reference number generally refers to the figure number in which the element is first introduced.

[0005] Figure 1 is a block diagram of an illustrative computing environment in which an on-demand code execution system may operate in conjunction with a data storage system in accordance with some embodiments.

[0006] Figure 2 is a block diagram of an illustrative computing system configured to provide data management across function calls in an on-demand code execution system, according to some embodiments.

[0007] Figure 3 is a flow diagram of an illustrative routine for managing data access across function calls in an on-demand code execution system, according to some embodiments.

[0008] Figure 4 is a block diagram of illustrative data flow and interactions during sequential invocation of on-demand code and when passing data between functions, according to some embodiments.

[0009] Figure 5 is a block diagram of illustrative data flows and interactions during event-based invocation of on-demand code and when sharing data, according to some embodiments. DETAILED DESCRIPTION

[0010] The present disclosure relates to managing the provisioning of and access to data sets between function code instances executing in an on-demand manner.

[0011] Some data centers may include many interconnected computing systems for providing computing resources to users of the data center. In order to facilitate improved utilization of data center resources, virtualization technology allows a single physical computing device to host one or more instances of virtual machines that appear and operate as independent computing devices for users of the data center. Through virtualization, a single physical computing device can dynamically create, maintain, delete, or otherwise manage virtual machines. In turn, users can request computer resources from a data center that includes a single computing device or a configuration of networked computing devices and is equipped with different numbers of virtual machine resources.

[0012] In addition to computing resources, data centers also provide many other beneficial services to client devices. For example, data centers can provide data storage services that are configured to store data submitted by client devices and enable retrieval of the data over a network. Various types of data storage services can be provided, which generally differ according to their input / output (I / O) mechanisms. For example, a database service may allow I / O based on a database query language such as structured query language (SQL). Block storage services may allow I / O based on modifications to one or more blocks of defined lengths in a manner similar to how an operating system interacts with a local storage device, and may therefore facilitate virtualized disk drives that can be used, for example, for operating systems storing virtual machines. Object storage services may allow I / O at the level of individual objects or resources (such as individual files), which may vary in content and length.

[0013] Some data centers include on-demand code execution systems, sometimes also referred to as serverless function execution systems. According to general descriptions, on-demand code execution systems enable the execution of function codes specified by any user without the need for the user to create, maintain or configure the execution environment (e.g., physical or virtual machine) in which the function code is executed. For example, conventional computing services usually require users to configure specific devices (virtual or physical devices), install operating systems on devices, configure application settings, define network interfaces, etc., while on-demand code execution systems can enable users to submit code and can provide users with application programming interfaces (APIs), which enable users to request the execution of function codes when used. When a call is received through an API, the on-demand code execution system can dynamically generate an execution environment for the code, configure code for the environment, execute the code, and provide results. Therefore, the on-demand code execution system does not require the user to dispose of the environment configuration and management for code execution. Due to the flexibility of the on-demand code execution system to execute any function code, such a system can be used to create various network services. For example, such a system can be used to create a "microservice", that is, to implement a small number of functions (or only one function) and interact with other services to provide network services for applications. In the context of an on-demand code execution system, an instance of function code that is executed to provide this service is often referred to as a "calling function," or simply a "function" for brevity.

[0014] The infrastructure or configuration of the on-demand code execution system may impose certain restrictions on data access and sharing. In some cases, these restrictions may interfere with or prevent the use of the on-demand code execution system to execute various functions that jointly provide applications or otherwise interact with and share data sets. For example, access to large data sets may be required to execute certain functions. However, because each function loads a data set to use with it, and then the execution environment of each function is cleared after each function execution is completed, any subsequent functions used with the same data set must first load the data set as well. In the case of large data sets, this can be disadvantageous due to the cumulative effect on the network bandwidth and function execution time required to repeatedly load large data sets. Application developers using on-demand functions to build applications that need to process large amounts of data or share state across function instances can solve the problem of loading and clearing function data in some cases. However, in order to do this, application developers need to do complex design and implementation work to bring state into the on-demand execution of functions and synchronize that state across multiple functions. Furthermore, in some data center environments, it may not be permitted or possible to transfer extremely large data sets (e.g., 10 or 100 gigabytes) from remote storage for access by instances of function code executing on dynamically provisioned hardware of an on-demand code execution system. Additionally, because function code is loaded and executed by a dynamically selected and provisioned host computing system when the function code is requested or scheduled for execution, it may be difficult or impossible to store the data set locally on the host computing device and ensure that all functions that need to access the data set will be similarly executed by the same host computing device or even on nearby host computing devices (in a physical or logical networking sense).

[0015] Some aspects of the present disclosure solve some or all of the above problems through an improved on-demand code execution system, which automatically manages data movement and access across multiple instances of function code. In some embodiments, an API may be provided, through which a function may store a data set to be shared with other functions, and through which a function may access a data set shared by other functions. The API relieves developers from the work of moving, storing, and controlling access to data sets. In addition, operating an on-demand code execution system in response to an API call may provide features that are difficult or impossible to implement in a function. For example, a function may initiate retrieval of a large data set from a network-based data storage system, and the large data set may be stored in the execution environment of the function so that the large data set is accessible to the function. The function may then make an API call to obtain a reference to the data set. The on-demand code execution system may generate a data reference (e.g., a name, address, or pointer to a data set location), which may be passed to other functions or discovered by other functions, and may allow other functions to access the data set after the function that initially obtained the data set completes execution. In order to facilitate sharing of data sets, the on-demand code execution system may cache a copy of the data set at a network-accessible location. When another function requests access to the data set using the data reference, the on-demand code execution system may copy the data set (or a portion thereof) to a local execution environment accessible to the function.

[0016] Additional aspects of the present disclosure relate to using an API provided by an on-demand code execution system to generate multi-function applications that expand as needed and shrink when processing is completed or no longer needed. In some embodiments, a function or a subset of functions may be configured as a "startup" function. These functions can be executed to load large data sets for access by any number of subsequently executed functions. For example, an on-demand function application may be used to evaluate, process, and / or respond to data startup of an event. Once a data set has been loaded and a sharable reference has been generated, an event handling function can be executed as needed, and the event handling function can access large data sets (or portions thereof) without first loading them. This can save time and computing resources. In addition, the event handling function can change the data in the data set, store the changed data set, and share the changed data set with other functions in a similar manner. In this way, there may be a certain degree of cross-function state sharing.

[0017] Various aspects of the present disclosure will be described with respect to certain examples and embodiments, which are intended to illustrate rather than limit the present disclosure. Although various aspects of some embodiments described in the present disclosure will focus on specific examples of function code, data sets, and on-demand proxy execution system configurations for illustration purposes, these examples are merely illustrative and are not intended to be restrictive. In some embodiments, the technology described herein can be applied to additional or alternative types of function code (e.g., subroutines), data sets, and on-demand code execution system configurations. In addition, any feature used in any embodiment described herein can be used in any combination with any other feature or in any other embodiment without limitation.

[0018] Example network environment

[0019] The on-demand code execution system can provide a network-accessible service that enables a user to submit or specify computer executable code to be executed by a virtual machine instance on the on-demand code execution system—also referred to herein as "function code" or simply "code" for simplicity. Each set of function code on the on-demand code execution system can define a "task" and implement a specific function corresponding to the task when executed on the virtual machine instance of the on-demand code execution system. The various implementations of tasks on the on-demand code execution system can be referred to as the "execution" (or "task execution") of the task. In some cases, the on-demand code execution system can enable users to directly trigger the execution of tasks based on various potential events, such as sending an API to the on-demand code execution system or sending a specially formatted hypertext transfer protocol ("HTTP") packet. The on-demand code execution system can therefore execute any specified executable code "on demand" without the need to configure or maintain the underlying hardware or infrastructure on which the code is executed. Further, the on-demand code execution system can be configured to execute tasks in a rapid manner (e.g., in less than 100 milliseconds [ms]), thereby enabling execution of tasks in "real time" (e.g., with little to no perceptible delay to an end user). To achieve such rapid execution, the on-demand code execution system may include one or more virtual machine instances that are "pre-warmed" or pre-initialized (e.g., booted into an operating system and executing a complete or substantially complete runtime environment) and configured to enable execution of user-defined code, such that the code can be quickly executed in response to a request to execute the code without the delay caused by initializing the virtual machine instance. Thus, when execution of a task is triggered, the code corresponding to the task can be executed within the pre-initialized virtual machine in a very short time.

[0020] Specifically, in order to perform tasks, the on-demand code execution system described herein can maintain a pool of execution virtual machine instances, and once a request for performing a task is received, these execution virtual machine instances are ready for use. Due to the pre-initialization nature of these virtual machines, the delay (sometimes referred to as latency) associated with executing task codes (e.g., instance and language runtime startup time) can be significantly reduced, typically to a level below 100 milliseconds. Illustratively, the on-demand code execution system can maintain a pool of virtual machine instances on one or more physical computing devices, wherein each virtual machine instance is loaded with one or more software components (e.g., operating system, language runtime, library, etc.). When the on-demand code execution system receives a request for executing program code ("task"), the on-demand code execution system can select a virtual machine instance for executing the user's program code based on one or more computing constraints (e.g., required operating system or runtime) associated with the task, and cause the task to be executed on the selected virtual machine instance. The task can be executed in an isolated container created on a virtual machine instance, or can be executed in a virtual machine instance isolated from other virtual machine instances used as environments for other tasks. Because the virtual machine instances in the pool have already been booted and loaded with a specific operating system and language runtime when a request is received, the delays associated with finding computing capacity capable of handling the request (e.g., by executing user code in one or more containers created on the virtual machine instance) can be significantly reduced.

[0021] As used herein, the term "virtual machine instance" is intended to refer to the execution of software or other executable code that simulates hardware to provide an environment or platform (example "execution environment") on which the software can be executed. Virtual machine instances are typically executed by hardware devices that may be different from the physical hardware simulated by the virtual machine instance. For example, a virtual machine can simulate a first type of processor and memory while executing on a second type of processor and memory. Therefore, a virtual machine can be used to execute software intended for a first execution environment (e.g., a first operating system) on a physical device that is executing a second execution environment (e.g., a second operating system). In some instances, the hardware simulated by the virtual machine instance may be the same or similar to the hardware of the base device. For example, a device with a first type of processor may implement multiple virtual machine instances, each virtual machine instance emulating an instance of a first type of processor. Therefore, a virtual machine instance can be used to divide the device into a certain number of logical sub-devices (each logical sub-device is called a "virtual machine instance"). Although virtual machine instances can generally provide an abstract level of hardware away from the underlying physical device, this abstraction is not required. For example, assuming that a device implements multiple virtual machine instances, each of the multiple virtual machine instances emulates the same hardware as the hardware provided by the device. In such scenarios, each virtual machine instance can allow software applications to execute code on the underlying hardware without translation, while maintaining logical separation between software applications running on other virtual machine instances. This process, often referred to as "native execution," can be used to increase the speed or performance of the virtual machine instance. Other technologies that allow direct utilization of the underlying hardware, such as hardware pass-through technology, can also be used.

[0022] Although a virtual machine executing an operating system is described herein as one example of an execution environment, other execution environments are possible. For example, a task or other process may be executed within a software "container" that provides a runtime environment without itself providing virtualization of the hardware. Containers may be implemented within a virtual machine to provide additional security, or containers may be run external to a virtual machine instance.

[0023] Figure 1 is a block diagram of an illustrative operating environment 100 in which a service provider system 110 operates to enable a client device 102 to submit or request invocation of user-defined code through an on-demand code execution system 120 .

[0024] By way of illustration, various example client devices 102 are shown in communication with the service provider system 110, including a desktop computer, a laptop computer, and a mobile phone. In general, the client device 102 can be any computing device, such as a desktop, laptop or tablet computer, a personal computer, a wearable computer, a server, a personal digital assistant (PDA), a hybrid PDA / mobile phone, a mobile phone, an e-book reader, a set-top box, a voice command device, a camera, a digital media player, etc.

[0025] Generally described, data storage service 160 is operable to enable clients to read, write, modify, and delete data, such as files, objects, blocks, or records, each of which represents a set of data associated with an identifier ("object identifier" or "resource identifier") that can be interacted with as a separate resource. For example, an object can represent a single file submitted by client device 102 (although data storage service 160 may or may not store such an object as a single file). This object-level interaction can be contrasted with other types of storage services, such as block-based storage in which data is manipulated at the level of individual blocks, or database storage in which data manipulation may occur at the table level.

[0026] The data storage service 160 illustratively includes one or more front ends 162 that provide an interface (a command line interface (CLI), an application programming interface (API), or other programming interface) through which client devices 102 can interact with the service 160 to configure the service 160 on behalf of these client devices and perform I / O operations on the service 160. For example, the client device 102 can interact with the front end 162 to create a collection of data objects (e.g., a "bucket" of objects) on the service 160 and configure permissions for the collection. The client device 102 can then create, read, update, or delete objects within the collection based on the interface of the front end 162. In one embodiment, the front end 162 provides a REST-compatible HTTP interface that supports various request methods, each of which corresponds to a requested I / O operation on the service 160. As non-limiting examples, the request methods may include:

[0027] A GET operation that requests to retrieve an object stored on service 160 by referencing the object's identifier;

[0028] A PUT operation that requests the storage of an object to be stored on service 160, including an identifier of the object and input data to be stored as the object;

[0029] A DELETE operation that requests the deletion of an object stored on service 160 by referencing the object's identifier; and

[0030] A LIST operation that requests the listing of objects within a collection of objects stored on the service 160 by referencing the identifier of the collection.

[0031] Various other operations may also be supported.

[0032] During general operation, front end 162 can be configured to obtain a call to a requested method and apply the requested method to the input data of the method. For example, front end 162 can respond to a request to put (PUT) the input data into service 160 as an object by storing the input data as an object on service 160.

[0033] The data may be stored, for example, on a data store 168, which corresponds to any persistent or substantially persistent storage device (including a hard disk drive (HDD), a solid-state drive (SSD), a network-accessible storage device (NAS), a storage area network (SAN), a non-volatile random access memory (NVRAM), or any of a variety of storage devices known in the art). As a further example, the front end 162 may respond to a request to access a data set or portion thereof from the service 160 by retrieving the requested data (e.g., an object representing input data for a GET resource request) from the storage 168 and returning the object to the requesting client device 102.

[0034] In some cases, a call to a request method may invoke one or more native data manipulations provided by service 160. For example, a SELECT operation may provide a SQL-formatted query to be applied to an object (also identified in the request), or a GET operation may provide a specific byte range of an object to be returned.

[0035] The service provider system 110 illustratively includes a cache service 170 that is configured to cache data sets of code executed by the on-demand code execution system 120. The data can be cached, for example, on a data cache 172 that corresponds to any data storage device, such as a hard disk drive (HDD), a solid-state drive (SSD), a network accessible storage device (NAS), a storage area network (SAN), a non-volatile random access memory (NVRAM), a random access memory (RAM), or various storage devices known in the art. Although shown as separate and external to the data storage service and the on-demand code execution system 120, in some embodiments, the cache service 170 can be implemented within one or both of the data storage service 160 or the on-demand code execution system 120 (e.g., implemented on a physical or logical communication system that is part of the data storage service 160 or the on-demand code execution system 120).

[0036] The client device 102, the data storage service 160, and the on-demand code execution system 120 can communicate via a network 104, which may include any wired network, wireless network, or a combination thereof. For example, the network 104 may be a personal area network, a local area network, a wide area network, an air broadcast network (e.g., for radio or television), a cable network, a satellite network, a cellular telephone network, or a combination thereof. As another example, the network 104 may be a publicly accessible network of a link network that may be operated by various different parties, such as the Internet. In some embodiments, the network 104 may be a private or semi-private network, such as a company or university intranet. The network 104 may include one or more wireless networks, such as a global system for mobile communications (GSM) network, a code division multiple access (CDMA) network, a long-term evolution (LTE) network, or any other type of wireless network. The network 104 may use protocols and components for communicating via any of the Internet or other aforementioned types of networks. For example, the protocols used by the network 104 may include a hypertext transfer protocol (HTTP), HTTP security (HTTPS), a message queue telemetry transmission (MQTT), a constrained application protocol (CoAP), and the like. The protocols and components for communicating via the Internet or any of the other aforementioned types of communications networks are well known to those skilled in the art and, therefore, are not described in further detail herein.

[0037] The system 120 includes one or more front ends 130 that can interact with the on-demand code execution system 120. In an illustrative embodiment, the front end 130 serves as a "front door" to other services provided by the on-demand code execution system 120, thereby enabling users to provide computer executable code (via the client device 102), request execution of the computer executable code, and view the results of the computer executable code. The front end 130 includes a variety of components for implementing interactions between the on-demand code execution system 120 and other computing devices. For example, each front end 130 may include a request interface that provides the following capabilities to the client device 102: upload or otherwise transmit user-specified code to the on-demand code execution system 120; and thereafter request execution of the code. In one embodiment, the request interface communicates with an external computing device (e.g., client device 102, front end 162, etc.) via a graphical user interface (GUI), CLI, or API. The front end 130 processes the request and ensures that the request is properly authorized. For example, the front end 130 can determine whether the user associated with the request is authorized to access the user code specified in the request.

[0038] References to user code used herein may refer to any program code (e.g., program, routine, subroutine, thread, etc.) written in a specific programming language. In the present disclosure, the terms "code," "user code," "function code," and "program code" may be used interchangeably. For example, such user code may be executed in conjunction with a specific data transformation developed by a user to implement a specific function. As described above, a separate set of user code (e.g., for implementing a specific function) is referred to herein as a "task," and a specific execution of the code (including, for example, compiling the code, interpreting the code, or otherwise enabling the code to execute) is referred to as "task execution" or simply "execution." Tasks may be written in JavaScript (e.g., node.js), Java, Python, or Ruby (and / or another programming language) by way of non-limiting examples.

[0039] In order to manage the request for code execution, the front end 130 may include an execution queue, which can maintain a record of the requested task execution. Illustratively, the number of tasks that the on-demand code execution system 120 executes simultaneously is limited, and thus, the new task execution initiated at the on-demand code execution system 120 (e.g., via API calls, via calls from tasks being executed or being executed, etc.) can be placed on the execution queue and processed, for example, in a first-in, first-out order. In some embodiments, the on-demand code execution system 120 may include multiple execution queues, such as individual execution queues for each user account. For example, a user of the service provider system 110 may expect to limit the rate of task execution on the on-demand code execution system 120 (e.g., for cost reasons). Therefore, the on-demand code execution system 120 can utilize account-specific execution queues to throttle the rate of simultaneous task execution performed by a specific user account. In some instances, the on-demand code execution system 120 may give priority to task execution, so that the task execution of a specific account or a specified priority is bypassed or given priority in the execution queue. In other examples, the on-demand code execution system 120 may execute a task immediately or substantially immediately after receiving a call for the task, and therefore, an execution queue may be omitted.

[0040] The front end 130 may further include an output interface configured to output information about the execution of a task on the on-demand code execution system 120. Illustratively, the output interface may send data about the execution of the task (e.g., the result of the task, errors associated with the execution of the task, or details of the execution of the task, such as the total time required to complete the execution, the total data processed via the execution, etc.) to the client device 102 or the data storage service 160.

[0041] In some embodiments, the on-demand code execution system 120 may include multiple front ends 130. In such embodiments, a load balancer may be provided to distribute incoming calls to multiple front ends 130, for example, in a round-robin manner. In some embodiments, the way in which the load balancer distributes incoming calls to multiple front ends 130 may be based on the location or state of other components of the on-demand code execution system 120. For example, the load balancer may distribute calls to front ends 130 that are geographically nearby or have the ability to serve the calls. In the case where each front end 130 corresponds to a separate instance of another component of the on-demand code execution system 120 (such as the activity pool 148 described below), the load balancer may distribute calls based on the capabilities or loads on those other components. In some instances, calls may be deterministically distributed between the front ends 130 so that a given call to perform a task will always (or almost always) be routed to the same front end 130. This may, for example, assist in maintaining an accurate record of the execution of the task to ensure that the task is only executed the desired number of times. For example, calls may be distributed to achieve load balancing between the front ends 130. Those skilled in the art will appreciate other distribution techniques, such as anycast routing.

[0042] The on-demand code execution system 120 further includes one or more worker managers 140 that manage execution environments, such as virtual machine instances 150 (illustrated as VM instances 150A and 150B, generally referred to as "VMs"), for servicing incoming calls to perform tasks. Although described below with reference to virtual machine instances 150 as an example of such an environment, embodiments of the present disclosure may utilize other environments, such as software containers. Figure 1 In the example shown, each worker manager 140 manages an active pool 148, which is a group of virtual machine instances 150 (sometimes referred to as a pool) executing on one or more physical host computing devices that are initialized to perform a given task (e.g., by loading the task's code and any dependency data objects into the instance).

[0043] Although virtual machine instance 150 is described as being assigned to a specific task here, in some embodiments, an instance can be assigned to a group task so that the instance is bound to the group task and any task of the group can be executed within the instance. For example, tasks in the same group can belong to the same security group (e.g., based on their security certificates) so that after having executed a task in a container on a specific instance 150, executing another task in another container on the same instance will not cause security risks. Tasks may be associated with permissions covering various aspects of how control tasks can be executed. For example, the permissions of a task can define which network connections (if any) can be initiated by the execution environment of the task. As another example, the permissions of a task can define which authentication information is passed to the task, thereby controlling which network-accessible resources can be used to execute the task (e.g., objects on service 160). In one embodiment, the security group of a task is based on one or more such permissions. For example, a security group can be defined based on a combination of permissions for initiating a network connection and permissions for accessing network resources. As another example, tasks within a group can share common dependencies so that the environment for executing a task of the group can be quickly modified to support the execution of another task within the group.

[0044] Once the front end 130 has successfully processed the triggering event for executing the task, the front end 130 passes the request to the worker manager 140 to execute the task. In one embodiment, each front end 130 can be associated with a corresponding worker manager 140 (e.g., a worker manager 140 that is co-located with the front end 130 or geographically close to the front end), and therefore, the front end 130 can pass most or all requests to the worker manager 140. In another embodiment, the front end 130 may include a location selector that is configured to determine the worker manager 140 to which the execution request is passed. In one embodiment, the location selector can determine the worker manager 140 for receiving the call based on hashing the call, and distribute the call to the worker manager 140 selected based on the hashed value (e.g., via a hash ring). Various other mechanisms for distributing calls between worker managers 140 will be apparent to those skilled in the art.

[0045] Thereafter, the worker manager 140 may modify the virtual machine instance 150 (if necessary) and execute the code of the task within the instance 150. Figure 1As shown, the corresponding instance 150 may have an operating system (OS) 152 (shown as OS 152A and 152B), a language runtime 154 (shown as runtime 154A and 154B), and a user code 156 (shown as user code 156A and 156B). The OS 152, runtime 154, and user code 156 may jointly implement the execution of the user code to implement the task. Therefore, via the operation of the on-demand code execution system 120, the task may be quickly executed within the execution environment.

[0046] According to aspects of the present disclosure, each VM 150 additionally includes staging code 157 executable to facilitate staging input data on VM 150 and handling output data written to VM 150, and a VM data store 158 accessible via a local file system of VM 150. Illustratively, staging code 157 represents a process executing on VM 150 (or potentially on a host device of VM 150) and configured to obtain data from a data storage service 160 or a cache service 170 and place the data into VM data store 158. Staging code 157 may further be configured to obtain data written to a file within VM data store 158 and send the data to data storage service 160 or cache service 170. Because such data is available at VM data store 158, user code 156 does not need to obtain the data over a network, thereby simplifying user code 156 and enabling user code 156 to further restrict network communications, thereby improving security. Instead, as discussed above, user code 156 may interact with input data and output data as files on VM data store 158 by using file handles passed to code 156 during execution. In some embodiments, the input and output data may be stored as files within a kernel space file system of data store 158. In other examples, marshaling code 157 may provide a virtual file system, such as a File System in User Space (FUSE) interface that provides an isolated file system accessible to user code 156 such that user code access to VM data store 158 is restricted.

[0047] As used herein, the term "local file system" generally refers to a file system maintained within an execution environment so that software executing within the environment can access data as files rather than via a network connection. According to aspects of the present disclosure, the data storage device accessible via the local file system may itself be local (e.g., a local physical storage device), or may be remote (e.g., accessed via a network protocol such as NFS, or represented as a virtualized block device provided by a network accessible service). Thus, the term "local file system" is intended to describe the mechanism by which software accesses data, rather than the physical location of the data.

[0048] The VM data store 158 may include any persistent or non-persistent data storage device. In one embodiment, the VM data store 158 is a physical storage device of the host device, or a virtual disk drive hosted on a physical storage device of the host device. In another embodiment, the VM data store 158 is represented as a local storage device, but is actually a virtualized storage device provided by a network accessible service. For example, the VM data store 158 may be a virtualized disk drive provided by a network accessible block storage service. In some embodiments, the data storage service 160 may be configured to provide file-level access to objects stored on the data store 168, thereby enabling the VM data store 158 to be virtualized based on the communication between the assembly code 157 and the service 160. For example, the data storage service 160 may include a file-level interface that provides network access to objects as files within the data store 168. The file-level interface may, for example, represent a network-based file system server (e.g., a network file system (NFS)) that provides access to objects as files, and the assembly code 157 may implement a client of the server, thereby providing file-level access to objects of the service 160.

[0049] In some examples, VM data store 158 may represent virtualized access to another data store executing on the same host device as VM instance 150. For example, active pool 148 may include one or more data aggregation VM instances ( Figure 1 156A), these data aggregation VM instances can be co-tenanted with VM instances 150 on the same host device. The data aggregation VM instance can be configured to support retrieval and storage of data from the service 160 (e.g., data objects or portions thereof, input data passed by the client device 102, etc.), and to store the data on the data storage area of ​​the data aggregation VM instance. For example, the data aggregation VM instance can be designated as unavailable for supporting the execution of user code 156, and therefore has elevated permissions relative to the instance 150 that supports the execution of user code. The data aggregation VM instance can enable other VM instances 150 within its host device (or potentially on a nearby host device) to access the data, such as by using a network-based file protocol (such as NFS). The other VM instances 150 can then act as clients of the data aggregation VM instance, thereby enabling the creation of a virtualized VM data storage area 158, which appears to be a local data storage area from the perspective of the user code 156A. Advantageously, given that the data aggregation VM and VM instance 150 are co-located within or on a nearby host device, it can be expected that network-based access to data stored at the data aggregation VM will occur very quickly.

[0050] Although some examples are provided herein regarding the use of IO stream handles to read from or write to VM data store 158, IO streams may additionally be used to read from or write to other interfaces of VM instance 150 (while still not requiring user code 156 to perform operations beyond stream-level operations, such as creating a network connection). For example, staging code 157 may "pipe" input data as an input stream to an execution of user code 156, whose output may be "piped" as an output stream to staging code 157. As another example, a staging VM instance or a hypervisor of VM instance 150 may pass input data to a network port of VM instance 150, which may be read by staging code 157 and passed to user code 157 as an input stream. Similarly, data written to the output stream by task code 156 may be written to a second network port of instance 150A for retrieval by the staging VM instance or the hypervisor. In yet another example, the hypervisor of instance 150 may pass input data as data written to a virtualized hardware input device (e.g., a keyboard), and marshaling code 157 may pass a handle to an IO stream corresponding to the input device to user code 156. The hypervisor may similarly pass a handle to an IO stream corresponding to a virtualized hardware output device to user code 156 and read the data written to the stream as output data. Thus, the examples provided herein regarding file streams may generally be modified to involve any IO stream.

[0051] The data storage service 160, the cache service 170 and the on-demand code execution system 120 are Figure 1 is depicted as operating in a distributed computing environment that includes the use of one or more computer networks ( Figure 1 The data storage service 160, the cache service 170, and the on-demand code execution system 120 may also be connected to a plurality of computer systems having a plurality of Figure 1 The device shown in FIG. 1 may be operated in a computing environment with fewer or more devices. Therefore, Figure 1The depiction of the data storage service 160, the cache service 170, and the on-demand code execution system 120 in the description is considered to be illustrative and not limiting of the present disclosure. For example, the on-demand code execution system 120 or its various components may implement various Web service components, hosted or "cloud" computing environments, or peer-to-peer network configurations to implement at least a portion of the processes described herein. In some instances, the data storage service 160, the cache service 170, and the on-demand code execution system 120 may be combined into a single service. Further, the data storage service 160, the cache service 170, and the on-demand code execution system 120 may be implemented directly in hardware or software executed by a hardware device, and may, for example, include one or more physical or virtual servers implemented on physical computer hardware configured to execute computer executable instructions for executing various features to be described herein. One or more servers may be geographically dispersed or geographically co-located, for example, in one or more data centers. In some instances, one or more servers may operate as part of a system of rapidly provisioned and released computing resources (commonly referred to as a "cloud computing environment").

[0052] exist Figure 1 , the data storage service 160, the cache service 170, and the on-demand code execution system 120 are shown as connected to the network 104. In some embodiments, any of the components within the data storage service 160, the cache service 170, and the on-demand code execution system 120 can communicate with other components of the on-demand code execution system 120 via the network 104. In other embodiments, not all components of the data storage service 160, the cache service 170, and the on-demand code execution system 120 are able to communicate with other components of the virtual environment 100. In one example, only the front ends 130 and 162 (which may represent multiple front ends in some instances) of the on-demand code execution system 120 and the data storage service 160, respectively, can be connected to the network 104, and other components of the data storage service 160 and the on-demand code execution system 120 can communicate with other components of the environment 100 via the respective front ends 130 and 162.

[0053] Although some functions are generally described herein with reference to individual components of the data storage service 160, cache service 170, and on-demand code execution system 120, other components or combinations of components may additionally or alternatively implement such functions. Figure 1 The specific configuration of elements in are intended to be illustrative.

[0054] Figure 2 Describing the implementation Figure 1 The overall architecture of the computing device of the front-end server 200 of the front-end 162. Figure 2The overall architecture of the front-end server 200 depicted in FIG. 1 includes an arrangement of computer hardware and software that can be used to implement various aspects of the present disclosure. The hardware can be implemented on a physical electronic device, as discussed in more detail below. The front-end server 200 may include Figure 2 More (or fewer) elements are shown in the drawings. However, in order to provide an enabling disclosure, it is not necessary to show all of these generally conventional elements. In addition, Figure 2 The overall architecture shown in can be used to implement Figure 1 One or more of the other components shown.

[0055] As shown, the front-end server 200 includes a processing unit 290, a network interface 292, a computer-readable medium drive 294, and an input / output device interface 296, all of which can communicate with each other via a communication bus. The network interface 292 can provide connectivity to one or more networks or computing systems. The processing unit 290 can therefore receive information and instructions from other computing systems or services via the network 104. The processing unit 290 can also communicate with the main memory 280 or the auxiliary memory 298 and further provide output information to an optional display (not shown) via the input / output device interface 296. The input / output device interface 296 can also receive input from an optional input device (not shown).

[0056] The main memory 280 or the secondary memory 298 may contain computer program instructions (grouped into units in some embodiments) that are executed by the processing unit 290 to implement one or more aspects of the present disclosure. These program instructions are stored in the processor 290. Figure 2 280, but may be stored additionally or alternatively in the auxiliary memory 298. The main memory 280 and the auxiliary memory 298 correspond to one or more layers of memory devices, including (but not limited to) RAM, 3DXPOINT memory, flash memory, magnetic storage devices, etc. For the purpose of description, it is assumed that the main memory 280 represents the main working memory of the worker manager 140, which has a higher speed than the auxiliary memory 298 but a lower total capacity.

[0057] The main memory 280 may store an operating system 284 that provides computer program instructions used by the processing unit 290 in the general management and operation of the front-end server 200. The memory 280 may further include computer program instructions and other information for implementing various aspects of the present disclosure. For example, in one embodiment, the memory 280 includes a user interface unit 282 that generates a user interface (or instructions for the user interface) for display on a computing device, for example, via a navigation or browsing interface such as a browser or application installed on the computing device.

[0058] The memory 280 may include a control plane unit 286 and a data plane unit 288, each of which is executable to implement aspects of the present disclosure. Illustratively, the control plane unit 286 may include code that is executable to implement the definition or submission of function code to be executed. The data plane unit 288 may illustratively include code that enables processing of I / O operations on the data storage service 160 or the cache service 170, including retrieving data sets, generating data references for other functions to use to access data sets, caching data sets, etc.

[0059] Figure 2 The front-end server 200 is an illustrative configuration of such devices, wherein other configurations are also possible. For example, although shown as a single device, in some embodiments, the front-end server 200 can be implemented as a logical device hosted by multiple physical host devices. Illustratively, a first device of such a front-end server 200 can implement a control plane unit 286, and a second device can implement a data plane unit 288.

[0060] Although in Figure 2 200, but similar components may be used to implement Figure 1 100. For example, similar devices may implement worker manager 140, as described in more detail in U.S. Patent No. 9,323,556, filed on September 30, 2014, entitled “PROGR AMMATIC EVENT DETECTION AND MESSAGE GENERATION FOR REQUESTS TO EXECUTE PROGRAM CODE” (“the '556 patent”), the entire contents of which are hereby incorporated by reference herein.

[0061] Example cross-function data management

[0062] Figure 3An example routine 300 for cross-function data management is shown. Advantageously, a component or subsystem of the on-demand code execution system 120 (such as the front end 130, the worker manager 140, some other component, or a combination thereof) can execute routine 300 to call shared data across on-demand functions and implement low-latency, data-intensive workloads. For example, a user can start a function with a reference to a shared data set, thereby facilitating the separation of data extraction code from business code. APIs for data abstraction allow functions to be chained together and references to previously acquired or generated data to be passed as part of the function call. In addition, applications can be expanded by downloading data to a local cache and then having other function instances obtain the data from the local cache or cache service 170. This "stateful serverless" approach allows users to build and support complex workflows that share content between calls for performance reasons without requiring round-trips to a database for compute-intensive processing.

[0063] The routine 300 starts at block 302. The routine may start in response to an event such as the on-demand code execution system 120 receiving a request to invoke a function defined by a function code. For example, the front end 130 may receive the invocation request from the client device 102, a VM instance, a previously invoked function executed within the on-demand code execution system 120, etc. In the following description, in order to distinguish the function currently being invoked from other functions (e.g., a previously invoked function, a subsequently invoked function, a concurrently invoked function running in a parallel instance of the routine 300, etc.), the function currently being invoked will be referred to as the "current function".

[0064] At block 304, the on-demand code execution system 120 may provide a provisioning environment for the function to be executed. In some embodiments, as described in more detail above, the worker manager 140 may identify a VM instance on which the function is to be executed. The assembly code within the VM instance may assemble the execution environment for the function, and the function code may eventually be loaded and may begin execution.

[0065] At decision block 306, the on-demand code execution system 120 may determine whether the request to call a function includes a data reference to a data set previously obtained or generated by a different function executed by the on-demand code execution system 120. In some embodiments, the data reference may be or include a name, address, or pointer to a location where previously obtained or generated data is stored. When a call request is issued for a particular function, the call request may include a data reference that the function may use to access the data set. For example, a function call request may include a data reference as a parameter. If the call request includes a data reference, the routine 300 may proceed to block 308. Otherwise, the routine may proceed to block 310.

[0066] At box 308, the on-demand code execution system 120 may make the data set referenced by the data reference available to the current function. To make the data set available to the current function, the on-demand code execution system 120 or a component thereof (such as a worker manager 140, an execution instance of the assembled code 157, etc.) may determine whether the data set referenced by the data reference is available within the execution environment of the current function. For example, the data may be available within an input directory assigned to the current function, the input directory corresponding to the VM data store 158 used by the VM instance 150 in which the current function will be executed or is being executed. If the data is not available (e.g., not currently stored in an input directory within a VM data store local to the VM instance in which the current function will be executed), the data reference may be used to retrieve the data set from a network-accessible data cache 172 and copy the data set to the VM data store.

[0067] At decision block 310, the on-demand code execution system 120 may determine whether execution of the current function has completed. The current function may perform operations, access data, generate data, etc. If the function continues to execute, the routine may continue to block 312 or 316 to process the API request (if any) to access or store data. Once the function completes execution, the routine 300 may end at block 320.

[0068] At decision block 312, the on-demand code execution system 120 may determine whether an API call has been made to store data obtained or generated during execution of the current function, such data being available for use by other functions executed by the on-demand code execution system 120. If so, the routine 300 may proceed to block 314. Otherwise, if there is no such pending API call, the routine 300 may proceed to decision block 316.

[0069] At block 314, the on-demand code execution system 120 may store the data set so that the data set is available to other functions executed by the on-demand code execution system 120. A function may be programmed to obtain a data set during execution. For example, a function may obtain a data set from a data storage service 160. A data set may be a set of one or more objects, files, blocks, records, etc. A function may or may not perform processing on the data set before storing it.

[0070] In some embodiments, if a data set is available for use by other functions, the function may request to store the data set and generate a data reference. The request may be an API request processed by a component of the on-demand code execution system 120, such as the front end 130, the worker manager 140, etc. Table 1 below shows an example definition of an API call for generating a data reference to a data set that can be shared by other functions.

[0071]

[0072] Table 1 – Example Data Reference Creation API

[0073] In the example data reference creation API, the parameter "data_path" is used to provide a locally accessible directory where the function will store the dataset to be shared. The component of the on-demand code execution system 120 executing the current function may copy the dataset from the locally accessible directory to a network accessible location, such as the cache service 170, from where the dataset can be shared by other functions. The on-demand code execution system 120 may generate a data reference that is uniquely associated with the dataset. For example, the data reference may be an alphabetic or alphanumeric string that uniquely identifies the dataset.

[0074] In some embodiments, the parameter "namespace_scope" is used to specify a namespace corresponding to the accessible scope of the data set. For example, if the namespace is set to a specific domain, the account under which another function is executing can be evaluated to determine whether the account is within the domain authorized to access the data set. If authorized, the data set can be provided to the local accessible data store of other functions, as described in more detail below. Otherwise, if not authorized, an error or exception may be returned. In some embodiments, "namespace_scope" can be optional and can default to the account under which the current function is executing (for example, all other functions attempting to access the data set must be executed under the same account as the current function).

[0075] At decision block 316, the on-demand code execution system 120 may determine whether an API call has been made during execution of the current function to access data associated with the data reference. If so, the routine 300 may continue to block 318. Otherwise, if there is no pending API call to access data associated with the data reference, the routine may return to decision block 310.

[0076] At block 318, the on-demand code execution system 120 may use the data reference to obtain the data. The function may be programmed to use the data reference at various points after the function begins execution to obtain the data. For example, the function may include a coded data reference in the function code, or the function may dynamically obtain or determine a data reference for the data to be accessed during execution. The data reference may reference a data set previously generated or accessed by another function (such as a previously executed or concurrently executed function).

[0077] In some embodiments, if a data reference is used to obtain a data set, the current function may access the data set through an API request, which may be handled by a component of the on-demand code execution system 120 (such as the front end 130, the worker manager 140, etc.).

[0078] Table 2 shows an example definition of an API call for accessing data using a data reference.

[0079]

[0080] Table 2 – Example Extraction API

[0081] In the example extraction API, the parameter "data_ref" is used to provide a data reference for the requested data set. In some embodiments, the parameter "target_dir_name" is used to specify the name of the target directory into which the requested data will be placed for access by the function. "target_dir_name" may be optional and may default to the default input directory for the function (e.g., a local storage directory of the VM instance in which the function is executing).

[0082] The on-demand code execution system 120 may use the passed data reference to obtain the requested data set for the function. For example, the cache service 170 may maintain a cached version of the data set specified by the function executed by the on-demand code execution system 120 for access by other functions executed by the on-demand code execution system 120, as described above. The data set may be obtained from the cache service 170 and placed in a data store (such as the VM data store 158) that is locally accessible to the function.

[0083] In some embodiments, if the data reference is generated with a namespace parameter set, the component of the on-demand code execution system 120 that handles the API request can evaluate the request to determine whether the request is associated with the specified namespace. For example, if the namespace is set to a specific account, the account under which the current function is executing can be evaluated to determine whether the account is within the namespace authorized to access the data set. If authorized, the data set can be provided to the local accessible data storage area of ​​the current function. Otherwise, if not authorized, an error or exception may be returned.

[0084] In some embodiments, a function may discover a data reference that can be used to access a data set. For example, instead of receiving a data reference as a parameter (or in addition) when calling, the function may issue an API request to the on-demand code execution system 120 to provide a data reference to a data set that the function is allowed to access. Table 3 below shows an example definition of an API call for discovering a data reference.

[0085]

[0086] Table 3 – Example Discovery API

[0087] In the example discovery API, the parameter "namespace_scope" is used to provide a namespace or availability scope for requesting a data reference. The component of the on-demand code execution system 120 that handles the API request can evaluate the namespace_scope and obtain a list of all in-scope data references. For example, the on-demand code execution system 120 can maintain a list of data references that have been generated and are still valid and their corresponding namespaces. The on-demand code execution system 120 can return a list of all in-scope data references to the current function in response to the API request. In some embodiments, the referenced in-scope data can be mapped to additional metadata about the data reference, which is also returned, such as the name of a file or object in the data set. The current function can use the output of the discovery API to access the data set, as described above.

[0088] Example Embodiments

[0089] Figure 4 An example implementation is shown in which on-demand functions are called and executed in sequence and each function operates on data generated by the previously called function. This implementation can be used for various applications, such as image processing, execution of MapReduce operations, etc.

[0090] In some embodiments, the first function can be used as a startup function 400, which obtains data and makes the data available to subsequently called functions, such as processing functions 410 and finalization functions 420. In the case where the initial data set to be operated is large or may take a lot of time to load, this operation of separating the startup function 400 from the subsequently called functions is very important. This solution is particularly advantageous in the case where resource usage is monitored and users are charged based on execution time or where each function is only allowed to execute for a limited time. By having a function serve as a startup function 400, the call of any subsequent function that will operate on the data set obtained by the startup function 400 can be delayed until the data set is available.

[0091] As shown, the start function can be associated with an input data store 402 and an output data store 404. Each of the input data store 402 and the output data store 404 can be implemented using the same physical or logical data store (e.g., VM data store 158), or they can be implemented using separate physical or logical data stores. In some embodiments, the input data store 402 can be a directory mapped to a virtualized data store, and the output data store 404 can be the same or different directories mapped to the same or different virtualized data stores.

[0092] At [A], the launch function may retrieve an initial data set from the data storage service 160. For example, the initial data set may be an image to be processed (e.g., transformed, enhanced, analyzed), a set of images, a video, a MapReduce data set, etc.

[0093] At [B], the startup function 400 may write the initial data set to the local storage device. For example, the startup function 400 may write the obtained data set or a substantially obtained data set (eg, with little processing) to the output data storage area 404.

[0094] At [C], the startup function 400 may obtain a data reference to the initial data set. For example, the startup function 400 may make an API call, such as a call to the above-mentioned data reference creation API, to obtain a data reference to the initial data set. In response, the on-demand code execution system 120 may generate and return a data reference and copy the initial data set to a location (e.g., cache service 170) where the subsequently called function can access it.

[0095] At [D], the launch function 400 or some other source may call a subsequent function, such as a processing function 410. The call request to the processing function 410 may include a data reference generated for a data set obtained by the launch function 400.

[0096] At [E], the processing function 410 may read an initial data set from the local input data store 412. Illustratively, invoking the processing function 410 using a data reference may cause the on-demand code execution system 120 to load the data set (e.g., from the cache service 170) into the input data store 412 for the processing function 410. Such loading, when executed as part of an execution environment that marshals the processing function 410 and when executed to load a data set that was previously retrieved by another function and stored specifically for sharing by other functions, may reduce the time and computing resources required for the processing function 410 to be ready to perform its substantive processing operations.

[0097] At [F], the processing function 410 may perform a processing operation using the data set initially retrieved by the initiation function 400. During the course of performing the processing operation, the processing function 410 may modify the initial data set or generate additional data. In some embodiments, the data set initially obtained or generated by one function is immutable; it cannot be modified by another function in a local storage device, or modifications to the data set in a local storage device will not be synchronized to the cache service 170 for use by other functions. Therefore, in order to make the modifications generated by the processing function 410 available to subsequent functions, a separate data set will be stored and shared. To do this, the processing function 410 may first store the processed data set in a locally accessible storage device (such as the output data storage area 414).

[0098] At [G], the processing function 410 may obtain a data reference to the processed data set. For example, the processing function 410 may make an API call, such as a call to the above-mentioned data reference creation API, to obtain a data reference to the processed data set. In response, the on-demand code execution system 120 may generate and return a data reference and copy the processed data set to a location where a subsequently called function can access it (e.g., cache service 170).

[0099] At [H], the processing function 410 or some other source may call a subsequent function, such as the finalization function 420. The call request to the finalization function 420 may include a data reference generated for the data set obtained by the processing function 410.

[0100] At [I], finalizer 420 may read the processed data set from local input data store 422. Illustratively, invoking finalizer 420 using a data reference may cause on-demand code execution system 120 to load the data set (e.g., from cache service 170) into input data store 422 for finalizer 420. Such loading, when executed as part of an execution environment that marshals finalizer 420 and when executed to load a data set that was previously retrieved or generated by another function and stored specifically for sharing by other functions, may reduce the time and computing resources required for finalizer 420 to prepare to perform its substantial processing operations.

[0101] At [J], the finalization function 420 may perform a processing operation using the processed data set previously generated by the processing function 410. During the course of performing the processing operation, the finalization function 420 may modify the processed data set or generate additional data. In some embodiments, in order to make the output generated by the finalization function 420 available for use, a separate data set is stored and shared. To do this, the finalization function 420 may first store the finalization data set in a locally accessible storage device (such as the output data storage area 424).

[0102] At [K], the finalizer function 420 may obtain a data reference to the finalized data set. For example, the finalizer function 420 may make an API call, such as a call to the above-mentioned data reference creation API, to obtain a data reference to the finalized data set. In response, the on-demand code execution system 120 may generate and return a data reference and copy the finalized data set to a location accessible to subsequently called functions (e.g., cache service 170).

[0103] Figure 4 The example functions, data flows, and interactions shown in and described herein are illustrative only and are not intended to be limiting, necessary, or exhaustive. In some embodiments, additional, fewer, or alternative functions, data flows, or interactions may be implemented. For example, there may be two or more processing functions between the startup function and the termination function.

[0104] Figure 5 An example implementation is shown in which on-demand functions are called and executed in response to events and each function operates on data generated by a previously called startup function set. This implementation can be used for applications in which large data sets are used to process events, such as data analysis and data processing. In some cases, the data set may be so large (e.g., several gigabytes, terabytes, or more) that computing resource constraints make it impractical or impossible to obtain the data set in response to an event. For example, bandwidth usage or execution time may be limited, which prevents some large data sets from being fully obtained. As another example, even if bandwidth and execution time are not systematically constrained, usage fees based on execution time can make it impractical to obtain a data set in response to each event. By having a function (or a group of functions) serve as a startup function and utilizing an API for cross-function data sharing disclosed by the on-demand code execution system 120, the startup function can make a large number of data sets available to any number of other functions.

[0105] In some embodiments, a set of startup functions are executed to collectively obtain a large data set as a collection of subsets, which can be used by subsequent executor functions to process or respond to events. For example, to start the startup process, an orchestration function 500 can be called. The orchestration function 500 can call a set of startup function instances 502. The startup function instance 502 can be a call instance of the same function code, or can be a call instance of different function code. For example, the orchestration function 500 can determine that n startup functions are to be executed to obtain a large data set as a collection of n smaller subsets. The orchestration function 500 can call each of the n startup functions using different parameters, which specify the subset to be obtained, or the startup function instance can determine the subset to be obtained from the parameter.

[0106] The startup function instance 502 can download its corresponding subset and create a data reference (e.g., by calling a data reference creation API). In response, the on-demand code execution system 120 can copy the subset from each startup function from the local storage device to the cache service 170, where these subsets will be available for use by subsequent functions. In some implementations, the startup function instance 502 can also return the created data reference to the orchestration function 500.

[0107] Once the startup function instance 502 obtains its subset and makes it available, the executor function can use these subsets to respond to or otherwise process events. In some embodiments, the orchestration function 500 can call the event queue function 510 and pass its reference to the subset obtained by the startup function instance 502. The event queue function 510 can maintain or access an event queue in which various events are stored for processing. For example, an event may be a transaction to be processed based on a large data set. The event queue function 510 can dequeue an event from the event queue and call an executor function instance 512. The executor function instance 512 can be a calling instance of the same function code, or it can be a calling instance of a different function code. For example, the event queue function 510 can call an executor function instance 512 for each event dequeued from the event queue, so that if there are n events in the queue, n executor function instances 512 are called. The event queue function 510 can call a given executor function instance 512 using parameters that identify or detail the event to be processed by the executor function instance 512. In some embodiments, if the event data is too large to be passed as a parameter, the event queue function 510 may save the event data as a data set, obtain a data reference, and provide the data reference to the executor function instance 512 .

[0108] The event queue function 510 may also provide a data reference for a subset to be used by the executor function instance 512. In some embodiments, the executor function instance 512 may determine the data reference without the event queue function 510 providing the data reference. For example, the executor function instance 512 may use a discovery API to determine the data reference of a subset to be used by the executor function instance 512 when processing an event.

[0109] The executor function instance 512 can use the data set as needed to process or respond to events without first obtaining a large data set.

[0110] Figure 5 The example functions, data flows, and interactions shown in and described herein are illustrative only and are not intended to be limiting, required, or exhaustive. In some embodiments, additional, fewer, or alternative functions, data flows, or interactions may be implemented.

[0111] Terminology and additional considerations

[0112] Some inventive aspects of the present disclosure are set forth in the following clauses:

[0113] Clause 1. A system comprising:

[0114] a data storage service, the data storage service comprising a first set of computing devices, wherein the data storage service stores a plurality of data objects;

[0115] a cache service comprising a second set of computing devices, wherein the cache service stores a cached version of the data set; and

[0116] An on-demand code execution service, the on-demand code execution service comprising a third set of computing devices for on-demand execution of function codes, wherein the on-demand code execution service is configured to at least:

[0117] receiving a first request to execute a startup function defined by a startup function code;

[0118] In response to the first request, configuring the startup function code to a first computing device in the third group of computing devices;

[0119] executing the startup function on the first computing device, wherein the startup function obtains a data set from the data storage service;

[0120] receiving, from the initiation function, a second request to generate a data reference associated with the data set;

[0121] generating the data reference;

[0122] storing a cached version of the data set at the cache service;

[0123] receiving, after completing execution of the startup function, a third request to execute an executor function defined by the executor function code, wherein the third request is received in response to an occurrence of a data processing event, and wherein the third request includes the data reference;

[0124] In response to the third request, configuring the executor function code to a second computing device in the third group of computing devices;

[0125] storing a local copy of the cached version of the data set from the cache service in a local cache on the second computing device based on the data reference; and

[0126] The executor function is executed on the second computing device, wherein the executor function accesses the local copy of the cached version of the set of data.

[0127] Clause 2. A system as described in Clause 1, wherein the local copy of the cached version of the data set is immutable, and wherein the executor function stores a modified data set in a local output data storage area of ​​the second computing device based on applying modifications to at least a portion of the local copy of the cached version of the data set.

[0128] Clause 3. The system of clause 2, wherein the on-demand code execution service is further configured to:

[0129] receiving, from the executor function, a fourth request to generate a second data reference associated with the modified data set;

[0130] generating the second data reference; and

[0131] A cached version of the modified data set is stored at the cache service.

[0132] Clause 4. The system of clause 1, wherein the on-demand code execution service is further configured to:

[0133] determining the account under which the executor function is to be executed; and

[0134] A determination is made as to whether the cached version of the data is within the scope of the account.

[0135] Clause 5. A computer-implemented method comprising:

[0136] Under the control of a computing system including one or more computer processors configured to execute specific instructions:

[0137] configuring a code execution system to execute a first instance of a first function code, wherein the code execution system provides on-demand execution of the function code on dynamically selected hardware;

[0138] executing the first instance using the code execution system;

[0139] determining that a data set used by the first instance is available for use by one or more other instances of a function code executed by the code execution system;

[0140] generating a data reference, the data reference comprising a reference for accessing the data set;

[0141] Receiving a call request to execute a second function code;

[0142] configuring the code execution system to execute a second instance of the second function code;

[0143] executing the second instance using the code execution system;

[0144] receiving, from the second instance, a data access request including the data reference; and

[0145] Access to the data set is provided to the second instance based on the data reference.

[0146] Clause 6. The computer-implemented method of Clause 5, wherein determining that the data set is available for use by one or more other instances of the function code executed by the code execution system comprises receiving a request from the first instance to generate the data reference, wherein the request comprises:

[0147] location data representing a location of the data set in a local storage location associated with the first instance; and

[0148] Namespace data indicating a namespace for accessing the data set.

[0149] Clause 7. The computer-implemented method of Clause 6, further comprising determining, based on the namespace data, to provide the second instance with access to the data set.

[0150] Clause 8. The computer-implemented method of Clause 5, further comprising storing a cached version of the data set in a network-accessible cache in response to determining that the data set is available for use by one or more other instances of the function code executed by the code execution system.

[0151] Clause 9. A computer-implemented method as described in Clause 8, wherein providing access to the data set to the second instance includes copying at least a portion of the cached version of the data set from the network-accessible cache to a local cache of a host computing device on which the second instance is executing.

[0152] Clause 10. The computer-implemented method of Clause 5, further comprising:

[0153] determining that a second data set used by the second instance is available for use by the one or more other instances of the function code executed by the code execution system; and

[0154] A second data reference is generated, the second data reference comprising a reference for accessing the second data set.

[0155] Clause 11. The computer-implemented method of Clause 10, further comprising:

[0156] receiving a third request to execute a third function code;

[0157] configuring the code execution system to execute a third instance of the third function code;

[0158] executing the third instance using the code execution system;

[0159] receiving a discovery request from the third instance; and

[0160] A determination is made based on a namespace associated with the second data set that the third instance is permitted to access the second data set.

[0161] Clause 12. The computer-implemented method of clause 11, further comprising:

[0162] determining an account under which the third instance is to execute; and

[0163] The second data set is determined to be within the scope of the account based on the namespace associated with the second data set.

[0164] Clause 13. A system comprising a computer readable memory and one or more processors, wherein the system is configured to:

[0165] configuring a code execution system to execute a first instance of a first function code, wherein the code execution system provides on-demand execution of the function code on dynamically selected hardware;

[0166] executing the first instance using the code execution system;

[0167] determining that a data set used by the first instance is available for use by one or more other instances of a function code executed by the code execution system;

[0168] generating a data reference, the data reference comprising a reference for accessing the data set;

[0169] receiving a call request for executing a second function code, wherein the call request includes the data reference;

[0170] configuring the code execution system to execute a second instance of the second function code;

[0171] executing the second instance using the code execution system; and

[0172] Access to the data set is provided to the second instance based on the data reference.

[0173] Clause 14. The system of clause 13, wherein to determine that the data set is available for use by one or more other instances of the function code executed by the code execution system, the system is further configured to receive a request to generate the data reference from the first instance, wherein the request comprises:

[0174] location data representing a location of the data set in a local storage location associated with the first instance; and

[0175] Namespace data indicating a namespace for accessing the data set.

[0176] Clause 15. The system of Clause 14, further configured to determine to provide access to the data set to the second instance based on the namespace data.

[0177] Clause 16. The method of clause 13, further configured to store a cached version of the data set in a network-accessible cache in response to determining that the data set is available for use by one or more other instances of the function code executed by the code execution system.

[0178] Clause 17. A system as described in Clause 16, wherein in order to provide access to the data set to the second instance, the system is further configured to copy at least a portion of the cached version of the data set from the network-accessible cache to a local cache of a host computing device on which the second instance is executing.

[0179] Clause 18. The system of clause 13, further configured to:

[0180] determining that a second data set used by the second instance is available for use by the one or more other instances of the function code executed by the code execution system; and

[0181] A second data reference is generated, the second data reference comprising a reference for accessing the second data set.

[0182] Clause 19. The system of clause 18, further configured to:

[0183] receiving a third request to execute a third function code;

[0184] configuring the code execution system to execute a third instance of the third function code;

[0185] executing the third instance using the code execution system;

[0186] receiving a discovery request from the third instance; and

[0187] A determination is made based on a namespace associated with the second data set that the third instance is permitted to access the second data set.

[0188] Clause 20. The system of clause 19, further configured to:

[0189] determining an account under which the third instance is to execute; and

[0190] The second data set is determined to be within the scope of the account based on the namespace associated with the second data set.

[0191] All methods and tasks described herein can be performed by a computer system and fully automated. In some cases, a computer system may include multiple different computers or computing devices (e.g., physical servers, workstations, storage arrays, cloud computing resources, etc.) that communicate and interoperate over a network to perform the functions described. Each such computing device typically includes a processor (or multiple processors) that executes program instructions or modules stored in a memory or other non-temporary computer-readable storage medium or device (e.g., a solid-state storage device, a disk drive, etc.). The various functions disclosed herein may be embodied in such program instructions, or may be implemented in a dedicated circuit (e.g., an ASIC or FPGA) of a computer system. In the case where a computer system includes multiple computing devices, these devices may, but need not, be in the same position. The results of the disclosed methods and tasks may be stored persistently by converting a physical storage device such as a solid-state memory chip or disk into a different state. In some embodiments, the computer system may be a cloud-based computing system, and the processing resources of the cloud-based computing system are shared by multiple different business entities or other users.

[0192] Depending on the embodiment, certain actions, events, or functions of any process or algorithm described herein may be performed in a different order, may be added, combined, or omitted entirely (e.g., not all described operations or events are required to practice the algorithm). In addition, in some embodiments, operations or events may be performed simultaneously rather than sequentially, for example, through multithreading, interrupt handling, or multiple processors or processor cores or on other parallel architectures.

[0193] The various illustrative logic blocks, modules, routines, and algorithmic steps described in conjunction with the embodiments disclosed herein may be implemented as electronic hardware or a combination of electronic hardware and computer software. In order to clearly illustrate this interchangeability, various illustrative components, blocks, modules, and steps have been generally described above in terms of their functions. Whether such functions are implemented as hardware or software running on hardware depends on the specific application and design conditions imposed on the entire system. For each specific application, the described functions may be implemented in different ways, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure.

[0194] In addition, the various illustrative logic blocks and modules described in conjunction with the embodiments disclosed herein may be implemented or executed by a machine designed to perform the functions described herein, such as a processor device, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, a discrete gate or transistor logic component, a discrete hardware component, or any combination thereof. The processor device may be a microprocessor, but in an alternative, the processor device may be a controller, a microcontroller or a state machine, a combination thereof, or the like. The processor device may include an electronic circuit configured to process computer executable instructions. In another embodiment, the processor device includes an FPGA or other programmable device that performs logic operations without processing computer executable instructions. The processor device may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors together with a DSP core, or any other such configuration. Although this article is primarily described with respect to digital technology, the processor device may also primarily include analog components. For example, some or all of the algorithms described herein may be implemented in analog circuits or mixed analog and digital circuits. The computing environment may include any type of computer system including, but not limited to, a microprocessor-based computer system, a mainframe computer, a digital signal processor, a portable computing device, a device controller, or a computing engine within an appliance, to name a few examples.

[0195] The elements of the methods, processes, routines or algorithms described in conjunction with the embodiments disclosed herein may be embodied directly in hardware, software modules executed by a processor device, or a combination of the two. The software module may reside in a RAM memory, a flash memory, a ROM memory, an EPROM memory, an EEPROM memory, a register, a hard disk, a removable disk, a CD-ROM, or any other form of non-temporary computer-readable storage medium. An exemplary storage medium may be coupled to a processor device so that the processor device may read information from the storage medium and write information to the storage medium. In an alternative, the storage medium may be integrated with the processor device. The processor device and the storage medium may reside in an ASIC. The ASIC may reside in a user terminal. In an alternative, the processor device and the storage medium may reside in a user terminal as discrete components.

[0196] Unless specifically stated otherwise, or understood otherwise within the context as used, conditional language used herein (such as, among other things, "can", "might", "can", "may", "for example", etc.) is generally intended to convey that certain embodiments include and other embodiments do not include certain features, elements or steps. Therefore, such conditional language is generally not intended to imply that one or more embodiments require features, elements and / or steps in any way, or that one or more embodiments must include features, elements and / or steps for deciding whether to include or perform these features, elements and / or steps in any particular embodiment with or without other input or prompts. The terms "including", "comprising", "having", etc. are synonymous and are used inclusively in an open manner and do not exclude additional elements, features, actions, operations, etc. In addition, the term "or" is used in its inclusive sense (and not in an exclusive sense) so that when used, for example, to connect a list of elements, the term "or" means one, some, or all of the elements in the list.

[0197] Unless specifically stated otherwise, disjunctive language, such as the phrase "at least one of X, Y, or Z," is understood in context as generally used to present that an item, term, etc. can be X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z). Thus, such disjunctive language is generally not intended to, and should not, imply that certain embodiments require the presence of at least one of X, at least one of Y, or at least one of Z, respectively.

[0198] Unless expressly provided otherwise, articles such as 'a' or 'an' are generally understood to include one or more of the described items. Thus, phrases such as "a device configured to..." are intended to include one or more of the recited devices. Such one or more of the described devices may also be collectively configured to perform the stated statements. For example, "a processor configured to perform statements A, B, and C" may include a first processor configured to perform statement A working in conjunction with a second processor configured to perform statements B and C.

[0199] Although the above detailed description has been shown, described and pointed out as novel features applied to various embodiments, it is understood that various omissions, substitutions and changes in the form and details of the illustrated devices or algorithms can be made without departing from the spirit of the present disclosure. As can be appreciated, certain embodiments described herein may be embodied in a form that does not provide all of the features and benefits set forth herein, because some features can be used or practiced separately from other features. The scope of certain embodiments disclosed herein is indicated by the appended claims rather than by the preceding description. All changes that fall within the meaning and scope of the equivalents of the claims will be included within the scope of the claims.

Claims

1. A computer-implemented method comprising: Under the control of a computing system including one or more computer processors configured to execute specific instructions, configuring a code execution system to execute a first instance of a first function code, wherein the code execution system provides on-demand execution of the function code on dynamically selected hardware; executing the first instance using the code execution system; determining that a data set used by the first instance is available for use by one or more other instances of a function code executed by the code execution system; generating a data reference, the data reference comprising a reference for accessing the data set; Receiving a call request to execute a second function code; configuring the code execution system to execute a second instance of the second function code; executing the second instance using the code execution system; receiving, from the second instance, a data access request including the data reference; as well as Access to the data set is provided to the second instance based on the data reference.

2. The computer-implemented method of claim 1 , wherein determining that the data set is available for use by one or more other instances of function code executed by the code execution system comprises receiving a request from the first instance to generate the data reference, wherein the request comprises: location data representing a location of the data set in a local storage location associated with the first instance; as well as Namespace data indicating a namespace for accessing the data set.

3. The computer-implemented method of claim 2, further comprising determining to provide access to the data set to the second instance based on the namespace data.

4. The computer-implemented method of claim 1, further comprising storing a cached version of the data set in a network-accessible cache in response to determining that the data set is available for use by one or more other instances of the function code executed by the code execution system.

5. A computer-implemented method as described in claim 4, wherein providing access to the data set to the second instance includes copying at least a portion of the cached version of the data set from the network-accessible cache to a local cache of a host computing device on which the second instance is executing.

6. The computer-implemented method of claim 1 , further comprising: determining that a second data set used by the second instance is available for use by the one or more other instances of the function code executed by the code execution system; as well as A second data reference is generated, the second data reference comprising a reference for accessing the second data set.

7. The computer-implemented method of claim 6, further comprising: receiving a third request to execute a third function code; configuring the code execution system to execute a third instance of the third function code; executing the third instance using the code execution system; receiving a discovery request from the third instance; as well as A determination is made based on a namespace associated with the second data set that the third instance is permitted to access the second data set.

8. The computer-implemented method of claim 7, further comprising: determining an account under which the third instance is to execute; as well as The second data set is determined to be within the scope of the account based on the namespace associated with the second data set.

9. A system comprising a computer readable memory and one or more processors, wherein the system is configured to: configuring a code execution system to execute a first instance of a first function code, wherein the code execution system provides on-demand execution of the function code on dynamically selected hardware; executing the first instance using the code execution system; determining that a data set used by the first instance is available for use by one or more other instances of a function code executed by the code execution system; generating a data reference, the data reference comprising a reference for accessing the data set; receiving a call request for executing a second function code, wherein the call request includes the data reference; configuring the code execution system to execute a second instance of the second function code; executing the second instance using the code execution system; as well as Access to the data set is provided to the second instance based on the data reference.

10. The system of claim 9, wherein to determine that the data set is available for use by one or more other instances of the function code executed by the code execution system, the system is further configured to receive a request from the first instance to generate the data reference, wherein the request comprises: location data representing a location of the data set in a local storage location associated with the first instance; as well as Namespace data indicating a namespace for accessing the data set.

11. The system of claim 10, further configured to determine to provide access to the data set to the second instance based on the namespace data.

12. The method of claim 9, further configured to store a cached version of the data set in a network-accessible cache in response to determining that the data set is available for use by one or more other instances of the function code executed by the code execution system.

13. A system as described in claim 12, wherein in order to provide access to the data set to the second instance, the system is further configured to copy at least a portion of the cached version of the data set from the network-accessible cache to a local cache of a host computing device on which the second instance is executing.

14. The system of claim 9, further configured to: determining that a second data set used by the second instance is available for use by the one or more other instances of the function code executed by the code execution system; and A second data reference is generated, the second data reference comprising a reference for accessing the second data set.

15. The system of claim 14, further configured to: receiving a third request to execute a third function code; configuring the code execution system to execute a third instance of the third function code; executing the third instance using the code execution system; receiving a discovery request from the third instance; determining that the third instance is permitted to access the second data set based on a namespace associated with the second data set; determining an account under which the third instance is to execute; as well as The second data set is determined to be within the scope of the account based on the namespace associated with the second data set.

Images