Tightly coupled parallel application on server-less computing system

Abstract

Systems and methods for executing closely coupled parallel applications on a server-less computing system are described. A server-less computing system executes user submitted code in a sandbox environment, such as a virtual machine or container. To support execution of parallel applications that need to transfer data between instances of the applications, a server-less computing system implements a transient mesh network that allows instances of the parallel applications to communicate with each other when executing in their respective sandboxes. In some embodiments, a controller or parent application can also be connected to the transient mesh network to coordinate execution of parallel applications. In other embodiments, the parent application can be external to the server-less computing system. A server-less computing system can connect and disconnect a sandbox environment from a transient mesh network when a parallel application starts and stops execution, and can remove the network and terminate the parallel application when a parent should stop execution.

Description

Background Art

[0001] Computing devices can utilize communication networks to exchange data. Companies and organizations operate computer networks that interconnect many computing devices to support operations or provide services to third parties. Computing systems can be located in a single geographic location or in multiple different geographic locations (e.g., interconnected via a dedicated communication network or a public communication network). Specifically, a managed computing environment or data processing center, generally referred to herein as a "data center," may include many interconnected computing systems to provide computing resources to users of the data center. A data center may be a private data center operated on behalf of an organization, or may be a public data center operated on behalf of the public or for the public interest.

[0002] To facilitate increased 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 to users of the data center. Through virtualization, a single physical computing device can dynamically create, maintain, delete, or otherwise manage virtual machines. Users can then request computing resources from the data center, such as a configuration of a single computing device or networked computing devices, and be provisioned with different numbers of virtual machine resources.

[0003] In some scenarios, a user may request a data center to provide computing resources to perform a specific task. The task may correspond to a set of computer executable instructions, which the data center may then execute on behalf of the user. The data center may thus further contribute to increased utilization of data center resources. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] Reference numerals may be repeated throughout the drawings to indicate correspondence between reference elements.The drawings are provided to illustrate the exemplary embodiments described herein and are not intended to limit the scope of the present disclosure.

[0005] Figure 1A and Figure 1B is a block diagram depicting an example operating environment in which a serverless computing system can perform tasks corresponding to code that can be submitted by a user of the serverless computing system and can create and manage ephemeral clusters and ephemeral mesh networks according to aspects of the present disclosure.

[0006] Figure 1C , Figure 1D and Figure 1E It is a description of various aspects of the present disclosure Figure 1A and Figure 1B Block diagram of an example ephemeral cluster and an example ephemeral mesh network in an environment of FIG.

[0007] Figure 2Aand Figure 2B is a flow chart depicting example interactions for creating and maintaining an ephemeral cluster of sandbox computing environments in a serverless computing system and creating and maintaining an ephemeral mesh network between sandbox computing environments by processing calls to a request interface of the serverless computing system in accordance with aspects of the present disclosure.

[0008] Figure 3A and 3B is a flow chart depicting example interactions for creating and maintaining ephemeral clusters of sandbox computing environments in a serverless computing system and creating and maintaining ephemeral mesh networks between sandbox computing environments by providing a mechanism for parent tasks executing on the serverless computing system to create child tasks in accordance with aspects of the present disclosure.

[0009] Figure 4A is a flow chart depicting an example routine for generating and maintaining ephemeral clusters and ephemeral mesh networks by processing calls to a request interface of a serverless computing system in accordance with aspects of the present disclosure.

[0010] Figure 4B is a flow chart depicting an example routine for generating and maintaining ephemeral clusters and ephemeral mesh networks by processing requests from tasks executed in a serverless computing environment in accordance with aspects of the present disclosure.

[0011] Figure 5 is a flow chart depicting an example routine for removing an ephemeral mesh network when an associated parent task ceases execution in accordance with aspects of the present disclosure.

[0012] Figure 6 is a block diagram depicting the overall architecture of a computing device configured to manage ephemeral clusters and ephemeral mesh networks in accordance with aspects of the present disclosure. DETAILED DESCRIPTION

[0013] In general, aspects of the present disclosure relate to a serverless computing system. More specifically, aspects of the present disclosure relate to improving the performance of a serverless computing system when executing tightly coupled parallel computing applications. As described in detail herein, a serverless computing system can provide a network-accessible service that enables a user to submit or specify a computer executable code to be executed by a virtual machine instance on a serverless computing system. Each set of code on a serverless computing system can define a "task", and when executed on a virtual machine instance of a serverless computing system, a specific function corresponding to this task can be implemented. Implementing a task separately on a serverless computing system can be referred to as an "execution" task (or "task execution"). In some embodiments, a user can implement a parallel computing application by executing several instances of a task on a serverless computing system, which can process a larger amount of data by dividing the data into smaller amounts and assigning them to tasks that execute and process their corresponding parts of the data in parallel. In other embodiments, these parallel tasks may require coordination or communication between instances of tasks. Applications that require such coordination or communication may be referred to as "tightly coupled" parallel applications in this article.

[0014] However, in a serverless computing system, tasks executed in parallel may be difficult to communicate with each other, and therefore may be difficult to implement tightly coupled parallel computing applications on a serverless computing system. For example, a serverless computing system may execute tasks (as described in more detail below) in a "sandbox" computing environment, which, for security reasons, does not allow these tasks to communicate directly with each other. As another example, tasks executed in parallel on a serverless computing system may have the ability to communicate, but may not have a mechanism for discovering each other or announcing their existence. Further, in some embodiments, a serverless computing system may implement networking or distributed tasks in a manner that may make communication between tasks inefficient. Users of a serverless computing environment can implement workspaces that allow tasks of tightly coupled parallel applications to exchange data, but such workspaces are typically implemented on servers outside the serverless computing environment, which introduces latency and overhead, and therefore reduces the benefits of using a serverless computing system to implement tightly coupled parallel applications.

[0015] To solve these problems, the operator of the serverless computing system can implement a transient cluster manager as described herein. In some embodiments, the transient cluster manager can allow users to create and maintain transient clusters of sandbox computing environments within the serverless computing system, and these transient clusters can communicate between sandbox environments using transient mesh networks, which implement low-latency communication between tasks executed in the environment. In some embodiments, the transient cluster manager can allow tasks executed on the serverless computing system to "fork" subtasks, and can allocate subtasks (and, in some embodiments, parent tasks) addresses created in this way on a transient mesh network that implements discovery and communication. In other embodiments, the transient cluster manager can allow a controller process (which can be executed as a task on the serverless computing system, or as a process on a computing device outside the serverless computing system) to create subtasks by calling the request interface of the serverless computing system, as described in more detail below. Therefore, when tasks that require inter-task communication are executed in parallel, the transient cluster manager can improve the performance of the serverless computing system, and therefore improve the performance of the serverless computing system when executing tightly coupled parallel applications.

[0016] Serverless computing systems can enable users to trigger the execution of tasks based on a variety of potential events, such as the detection of new data at a network-based storage system, the transmission of an application programming interface ("API") call to a serverless computing system, or the transmission of specially formatted hypertext transfer protocol ("HTTP") packets to a serverless computing system. Thus, users can utilize serverless computing systems to 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. In addition, serverless computing systems can be configured to execute tasks in a rapid manner (e.g., in less than 100 milliseconds), thereby achieving "real-time" (e.g., with a delay that is barely perceptible to the end user) execution of tasks.

[0017] Thus, a serverless computing system may allow a user to execute code in a serverless computing environment (e.g., an environment in which the underlying server is not under user control). The term "serverless computing environment" as used herein is intended to refer to an environment in which the responsibility for managing the generation, configuration, and state of the underlying execution environment is abstracted from the user, such that the user does not need to, for example, create an execution environment, install an operating system within the execution environment, or manage the state of the environment in order to execute the desired code in the environment. Similarly, the term "server-based computing environment" is intended to refer to an environment in which, in addition to executing the desired code in the environment, the user is at least partially responsible for managing the generation, configuration, or state of the underlying execution environment. Therefore, those skilled in the art will understand that "serverless" and "server-based" may indicate the degree of user control over the execution environment in which the code is executed, rather than the actual absence or presence of a server.

[0018] As described in more detail below, a serverless computing system may include a worker manager configured to receive user code (threads, programs, etc. in any of a variety of programming languages) and execute the code in a highly scalable, low-latency manner without requiring the user to configure virtual machine instances. Specifically, the worker manager may create and configure virtual machine instances according to a set of predetermined configurations, each corresponding to any one or more of a variety of runtime environments, before receiving user code and before receiving any information from the user about any particular virtual machine instance configuration. Thereafter, the worker manager receives a user-initiated request to execute code and identifies a pre-configured virtual machine instance to execute the code based on the configuration information associated with the request. The worker manager may also allocate the identified virtual machine instance to execute the user's code at least in part by creating and configuring a container within the allocated virtual machine instance and providing the container with the code for the task and any dependent code objects. Various embodiments for implementing a worker manager and executing user code on a virtual machine instance are described in U.S. Patent No. 9,323,556, entitled “PROGRAMMATIC EVENT DETECTION AND MESSAGE GENERATION FOR REQUESTS TO EXECUTE PROGRAM CODE,” filed on September 30, 2014 (the “556 Patent”), the entire contents of which are incorporated herein by reference.

[0019] 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 ("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 processor and memory of a first type while executing on a processor and memory of a second type. 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 cases, the hardware simulated by the virtual machine instance may be the same or similar to the hardware of the underlying device. For example, a device having a processor of a first type may implement multiple virtual machine instances, each virtual machine instance simulating an instance of that first type of processor. Therefore, a virtual machine instance may 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 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 simulates 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, generally 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.

[0020] Although a virtual machine instance 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 an isolated runtime environment without itself providing virtualization of the hardware. The container may be implemented within a virtual machine to provide additional security, or the container may be run external to the virtual machine instance.

[0021] Those skilled in the art will appreciate in view of the present disclosure that the embodiments disclosed herein improve the ability of computing systems such as on-demand code execution systems to execute code in an effective manner. Moreover, the embodiments disclosed herein solve the inherent technical problems in computing systems; specifically, when tasks executed in parallel in a serverless computing environment need to communicate with each other, problems of managing delays and other performance problems arise. These problems are more common in serverless computing systems because, as described above, the details of "where" the tasks are executed have been abstracted from the user, so that the user cannot easily program tasks that discover other tasks executed in other sandbox environments within the serverless computing environment and communicate with them. These technical problems are solved by various technical solutions described herein, including providing a transient cluster manager within a serverless computing system to facilitate the creation and management of a transient mesh network, to which parallel computing tasks are dynamically added and removed as tasks are executed. These technical solutions also provide users with many options for creating subtasks (such as forking subtasks from parent tasks or calling request interfaces for creating subtasks), which provide different technical improvements for different needs. For example, a parent task that needs to exchange data with a child task during its respective execution may select a fork / merge implementation that allows the parent task to communicate via an ephemeral mesh network. As another example, the controller processes for individual tasks that need to be "alive" executing on a serverless computing system may be implemented on an external computing device, allowing a user to implement tightly coupled parallel applications with long-lived controller processes. The present disclosure generally represents many improvements over existing data processing systems and computing systems.

[0022] Embodiments of the present disclosure will now be described with reference to the accompanying drawings, wherein like numbers refer to like elements throughout. The terms used in the descriptions presented herein are not intended to be interpreted in any limiting or restrictive manner, simply because the terms are utilized in conjunction with the detailed description of certain specific embodiments of the present invention. In addition, embodiments of the present invention may include several novel features, a single feature of which is not solely responsible for its desired properties or essential to practicing the invention described herein.

[0023] Figure 1A1 is a block diagram of an example operating environment 100 in which a serverless computing system 110 may operate based on communications with a user computing device 102, auxiliary services 106, and a network-based data storage service 108. In general, the user computing device 102 may 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. The serverless computing system 110 may provide one or more user interfaces, command line interfaces (CLIs), application programming interfaces (APIs), and / or other programming interfaces to the user computing device 102 for generating and uploading user executable code (including metadata identifying dependent code objects of the uploaded code), invoking user-provided code (e.g., submitting a request to execute the user code on the serverless computing system 110), scheduling event-based jobs or cron jobs, tracking user-provided code, and / or viewing other logging or monitoring information related to requests for them and / or the user code. While one or more implementations may be described herein as using a user interface, it should be appreciated that these implementations may additionally or alternatively use any CLI, API, or other programming interface.

[0024] The illustrative environment 100 also includes one or more network-based data storage services 108, which are configured to enable the serverless computing system 110 to store and retrieve data from one or more persistent or substantially persistent data sources. Illustratively, the network-based data storage service 108 can enable the serverless computing system 110 to store information corresponding to a task (such as code or metadata), store additional code objects representing dependencies of the task, retrieve data to be processed during the execution of the task, and store information about this execution (such as results). The network-based data storage service 108 can represent (for example) a relational or non-relational database. In another example, the network-based data storage service 108 can represent a network attached storage device (NAS), which is configured to provide access to data arranged as a file system. The network-based data storage service 108 can also enable the serverless computing system 110 to query and retrieve information about data stored in the serverless computing system 110, such as by querying the number of related files or records, the size of these files or records, the file or record name, the file or record creation time, etc. In some cases, the network-based data storage service 108 may provide additional functionality, such as the ability to separate data into logical groups (e.g., groups associated with personal accounts, etc.). Although illustrated as distinct from auxiliary services 106, the network-based data storage service 108 may also represent a type of auxiliary service 106 in some cases.

[0025] The user computing device 102, auxiliary service 106 and network-based data storage service 108 can communicate with the serverless computing system 110 via a network 104, which may include any wired network, wireless network or 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 dedicated or semi-dedicated 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 Hypertext Transfer Protocol (HTTP), HTTP Secure (HTTPS), Message Queuing Telemetry Transport (MQTT), Constrained Application Protocol (CoAP), etc. Protocols and components for communicating via the Internet or any of the foregoing types of communication networks are well known to those skilled in the art and are therefore not described in further detail herein.

[0026] exist Figure 1A In the example of FIG. 1 , serverless computing system 110 is shown as being connected to network 104. In some embodiments, any of the components within serverless computing system 110 can communicate with other components of serverless computing system 110 via network 104. In other embodiments, not all components of serverless computing system 110 are able to communicate with other components of operating environment 100. In one example, only Figure 1B The front end 120 depicted in FIG. 1 (which may represent multiple front ends 120 in some cases) may be connected to the network 104, and other components of the serverless computing system 110 may communicate with other components of the environment 100 via the front end 120. Additionally, in some embodiments, some or all of the environments in which user-submitted code executes (as described in more detail below) may be isolated from each other for security, efficiency, or other reasons.

[0027] exist Figure 1AIn the example, a user may interact with a serverless computing system 110 through a user computing device 102 to provide executable code and establish rules or logic that define when and how such code is executed on the serverless computing system 110, thereby establishing a "task". For example, a user may want to run a piece of code in conjunction with a web or mobile application that the user has developed. One way to run the code would be to obtain a virtual machine instance from a service provider that provides infrastructure as a service; configure the virtual machine instance to suit the needs of the user; and use the configured virtual machine instance to run the code. To avoid the complexity of this process, the user may alternatively provide the code to the serverless computing system 110 and request the serverless computing system 110 to execute the code. The serverless computing system 110 may handle the acquisition and configuration of computing capabilities (e.g., containers, instances, etc., which are described in more detail below) based on the code execution request, and use the computing capabilities to execute the code. The serverless computing system 110 can automatically scale up and down based on capacity, thereby alleviating the burden on users of having to worry about over-utilization (e.g., acquiring too few computing resources and suffering performance issues) or under-utilization (e.g., acquiring more computing resources than required to run the code, and therefore paying too much). According to an embodiment of the present disclosure, and as described in more detail below, the serverless computing system 110 can configure virtual machine instances with a customized operating system to more efficiently execute user code and reduce utilization of computing resources.

[0028] Reference now Figure 1B , the serverless computing system 110 is described as operating in a distributed computing environment that includes the use of one or more computer networks ( Figure 1B The serverless computing system 110 may also be configured to have multiple computer systems interconnected (not shown). Figure 1B , or more than one of the devices shown in FIG. Figure 1B The depiction of the serverless computing system 110 in the embodiment should be considered as illustrative, rather than limiting, of the present disclosure. For example, the serverless computing system 110 or its various components may implement various web service components, hosted or "cloud" computing environments, and / or peer-to-peer network configurations to implement at least a portion of the processes described herein.

[0029] In addition, the serverless computing system 110 can be implemented directly in hardware or in software executed by a hardware device, and can, for example, include one or more physical or virtual servers implemented on physical computer hardware that is configured to execute computer executable instructions for performing the various features described herein. One or more servers can be geographically dispersed or geographically co-located, for example, in one or more data centers. In some cases, one or more servers can operate as part of a system of rapidly provisioned and released computing resources (often referred to as a "cloud computing environment").

[0030] To enable interaction with the serverless computing system 110, the system 110 includes one or more front ends 120 that can enable interaction with the serverless computing system 110. In an illustrative embodiment, the front end 120 serves as a "front door" to other services provided by the serverless computing system 110, enabling users (via the user computing device 102) to provide computer executable code, request execution of the computer executable code, and view the results of the computer executable code. The front end 120 includes various components for enabling interaction between the serverless computing system 110 and other computing devices. For example, each front end 120 may include a request interface that provides the user computing device 102 with the ability to upload or otherwise communicate user-specified code to the serverless computing system 110 and thereafter request execution of this code. In one embodiment, the request interface communicates with an external computing device (e.g., the user computing device 102, auxiliary service 106, etc.) via a graphical user interface (GUI), CLI, or API. The front end 120 processes the request and ensures that the request is properly authorized. For example, front end 120 may determine whether a user associated with the request is authorized to access a user code specified in the request.

[0031] Reference 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" and "program code" may be used interchangeably. For example, such user code may be executed in conjunction with a specific web application or mobile application developed by a user to implement a specific function. As described above, a separate set of user code (e.g., to implement a specific function) is referred to herein as a "task", and the specific execution of that code (including, for example, compiling code, interpreting code, or otherwise enabling code to execute) is referred to as a "task instance", "task execution", or simply "instance" or "execution". Tasks may be written in JavaScript (e.g., node.js), Java, Python and / or Ruby (and / or another programming language) by way of non-limiting examples. Tasks may be "triggered" in various ways to execute on a serverless computing system 110. In one embodiment, a user or other computing device may transmit a request to execute a task, which may generally be referred to as a "call" to execute the task. Such calls may include the user code to be executed (or its location) and one or more arguments for executing the user code. For example, the call may provide the user code of the task and a request to execute the task. In another example, the call may identify the previously uploaded task by the previously uploaded task name or identifier. In yet another example, the code corresponding to the task may be included in the call to the task, and uploaded to a separate location (e.g., a storage device of the auxiliary service 106 or a storage system inside the serverless computing system 110) before the request is received by the serverless computing system 110. As described above, the code of the task may reference additional code objects maintained at the serverless computing system 110 by using the identifiers of those code objects, so that before executing the task, the code object is combined with the code of the task in the execution environment. The serverless computing system 110 may change its execution strategy for the task based on where the task code is available when processing the call to the task. The request interface of the front end 120 may receive a call to execute the task from the user as a Hypertext Transfer Protocol Secure (HTTPS) request. Moreover, when executing the task, any information (e.g., headers and parameters) included in the HTTPS request may also be processed and utilized. As discussed above, any other protocol including, for example, HTTP, MQTT, and CoAP may be used to transmit messages containing task invocations to the request interface.

[0032] The call to perform a task may specify one or more third-party libraries (including local libraries) to be used with the user code corresponding to the task. In one embodiment, the call may provide a file containing the user code corresponding to the task requested for execution and any library (and / or the identification of its storage location) to the serverless computing system 110. In some embodiments, the call includes metadata indicating the program code of the task to be performed, the language of writing the program code, the user associated with the call, and / or the computing resources (e.g., memory, etc.) reserved for executing the program code. For example, the program code of the task may be provided with the call, previously uploaded by the user, provided by the serverless computing system 110 (e.g., standard routines), and / or provided by a third party. Illustratively, by using the URI associated with the code, the code not included in the call or previously uploaded by the user may be referenced in the metadata of the task. In some embodiments, such resource-level constraints are specified for a specific task (e.g., how much memory is to be allocated for executing a specific user code), and will not change each time the task is executed. In this case, the serverless computing system 110 may access such resource-level constraints before receiving each individual call, and an individual call may not specify such resource-level constraints. In some embodiments, the call may specify other constraints, such as permission data indicating the type of permission or authorization that the caller has to perform the task. Such permission data may be used by the serverless computing system 110 to access private resources (e.g., on a private network). In some embodiments, individual code objects may also be associated with permissions or authorizations. For example, a third party may submit a code object and specify that the object is readable only by a subset of users. The serverless computing system 110 may include functionality to enforce these permissions or authorizations for code objects.

[0033] In some embodiments, the call may specify the behavior that should be adopted to handle the call. In such embodiments, the call may include an indicator for enabling one or more execution modes for executing the task referenced in the call. For example, the call may include a flag or header for indicating whether the task should be executed in debug mode, in which debugging and / or logging output that can be generated in connection with the execution of the task is provided back to the user (e.g., through a console user interface). In such an example, the serverless computing system 110 can check the call and find the flag or header, and if it exists, the serverless computing system 110 can modify the behavior of the container in which the task is executed (e.g., logging facilities) and cause the output data to be provided back to the user. In some embodiments, the behavior / mode indicator is added to the call through a user interface provided to the user by the serverless computing system 110. Other features, such as source code performance analysis, remote debugging, etc., can also be enabled or disabled based on the instructions provided in the call.

[0034] To manage requests for code execution, front end 120 may include an execution queue ( Figure 1B ), which can maintain a record of the requested task executions. Exemplarily, the number of tasks executed simultaneously by the serverless computing system 110 is limited, and therefore, new task executions initiated at the serverless computing system 110 (e.g., via an API call, via a call from an already executed or executing task, etc.) can be placed on an execution queue and processed, for example, in a first-in, first-out order. In some embodiments, the serverless computing system 110 may include multiple execution queues, such as a separate execution queue for each user account. For example, a user of the serverless computing system 110 may desire to limit the rate of task execution on the serverless computing system 110 (e.g., for cost reasons). Therefore, the serverless computing system 110 can utilize account-specific execution queues to limit the rate at which tasks are executed simultaneously by a particular user account. In some cases, the serverless computing system 110 can prioritize task executions so that task executions for a particular account or a specified priority bypass the execution queue or are prioritized within the execution queue. In other cases, the serverless computing system 110 can execute the task immediately or substantially immediately after receiving the call for the task, and therefore, the execution queue can be omitted.

[0035] As described above, tasks may be triggered for execution at the serverless computing system 110 based on explicit calls from the user computing device 102 (e.g., calls received at the request interface). Alternatively or additionally, tasks may be triggered for execution at the serverless computing system 110 based on data retrieved from one or more auxiliary services 106 or a network-based data storage service 108. To facilitate interaction with the auxiliary services 106, the front end 120 may include a polling interface (in the Figure 1B 108), the polling interface operates to poll the auxiliary service 106 or data storage service 108 for data. Illustratively, the polling interface may periodically send requests to one or more user-specified auxiliary services 106 or data storage services 108 to retrieve any new available data (e.g., social network "posts", news articles, files, records, etc.) and determine whether this data corresponds to user-established criteria that triggers the execution of a task on the serverless computing system 110. Illustratively, the execution criteria for a task may include, but are not limited to, whether new data is available at the auxiliary service 106 or data storage service 108, the type or content of the data, or timing information corresponding to the data. In some cases, the auxiliary service 106 or data storage service 108 may be used to notify the front end 120 of the availability of new data, and thus, with respect to such services, a polling service may be unnecessary.

[0036] In addition to tasks that are executed based on explicit user calls and data from auxiliary services 106, the serverless computing system 110 operates in certain circumstances to independently trigger the execution of tasks. For example, the serverless computing system 110 may operate (based on instructions from a user) to trigger the execution of a task at each of a plurality of specified time intervals (e.g., every 10 minutes).

[0037] The front end 120 may also include an output interface ( Figure 1B ), the output interface is configured to output information about the execution of the task on the serverless computing system 110. Illustratively, the output interface can transmit data about the execution of the task (e.g., the result of the task, errors related to the execution of the task, or details of the task execution, such as the total time required to complete the execution, the total data processed via the execution, etc.) to the user computing device 102 or the auxiliary service 106, which may include, for example, billing or logging services. The output interface can further enable the transmission of data such as service calls to the auxiliary service 106. For example, the output interface can be used during task execution to transmit API requests to the external service 106 (e.g., to store data generated during task execution).

[0038] In some embodiments, the serverless computing system 110 may include multiple front ends 120. In such embodiments, a load balancer (in Figure 1B 10 (not shown) to distribute incoming calls to multiple front ends 120, for example, in a round-robin manner. In some embodiments, the manner in which the load balancer distributes incoming calls to multiple front ends 120 can be based on the location or state of other components of the serverless computing system 110. For example, the load balancer can distribute calls to front ends 120 that are geographically nearby or have the ability to serve the calls. In the case where each front end 120 corresponds to a separate instance of another component of the serverless computing system 110 (such as the active pool described below), the load balancer can distribute calls based on the capacity or load on those other components. As will be described in more detail below, in some cases, calls can be deterministically distributed among the front ends 120 so that a given call to perform a task will always (or almost always) be routed to the same front end 120. This can (for example) assist in maintaining an accurate record of the execution of the task, thereby ensuring that the task is only executed the desired number of times. Although the distribution of calls via a load balancer is illustratively described, other distribution techniques, such as anycast routing, will be apparent to those skilled in the art.

[0039] In the illustrated embodiment, the serverless computing system 110 also includes a transient cluster manager 130, which is described in detail below. In some embodiments, the transient cluster manager 130 can be a process executed on the worker manager 140, rather than a separate component of the serverless computing system 140. The transient cluster manager 130 manages the creation, update and removal of transient clusters and transient mesh networks between the sandbox computing environments. As shown, the transient cluster manager 130 communicates with a transient cluster data repository 132, which stores information about transient clusters, transient mesh networks and sandbox environments. The transient cluster data repository 132 can generally be any non-transient computer-readable data repository, such as a hard drive, a solid-state device, a magnetic medium, a database, a storage service or other device or service. In some embodiments, the transient cluster data repository 132 can be implemented on a data storage service 108 or an auxiliary service 106 or implemented as a part thereof. In other embodiments, the transient cluster data repository 132 can be omitted, and information about transient clusters and transient mesh networks can be stored in a separate sandbox computing environment.

[0040] To perform tasks, the serverless computing system 110 includes one or more worker managers 140 that manage instances of incoming calls for servicing the execution of tasks. Figure 1BIn the example shown in , each worker manager 140 manages an active pool of virtual machine instances 154A-E, which are assigned to one or more users and implemented by one or more physical host computing devices 150A-C. Physical host computing devices 150A-C and virtual machine instances 154A-E can also implement one or more containers 158A-I, which can contain and execute user-submitted tasks, such as parent tasks 162, 182 and 192 and child tasks 164A-C, 174A, 174B, 184A and 184B. A container is a logical unit created within or on a virtual machine instance or host computing device using resources available on that instance. For example, each worker manager 140 can create a new container or locate an existing container 158A-I based on information specified in a call to execute a task, and allocate a container to handle the execution of the task. Each container can correspond to an execution environment for a task, thereby providing at least some isolation from other execution environments. For example, each container may provide a file system that is isolated from other file systems on the device, and code executing in the container may have limited or no access to other file systems or memory spaces associated with code executing outside the container.

[0041] Containers 156A-I, virtual machine instances 154A-E, and host computing devices 150A-C may also include language runtimes, code libraries, or other supporting functionality that facilitates execution of user-submitted code 160A-G ( Figure 1B ). Physical computing devices 150A-C and virtual machine instances 154A-E may also include an operating system, which may be the same operating system, variations of the same operating system, different operating systems, or a combination thereof.

[0042] Although virtual machine instances 154A-E are described herein as being assigned to specific users, in some embodiments, instances 154A-E may be assigned to a group of users so that the instances are associated with the group of users and any member of the group may utilize resources on the instances. For example, users in the same group may belong to the same security group (e.g., based on their security certificates) so that executing a member's task in another container on the same instance after having executed a member's task in a container on a specific instance does not pose a security risk. Similarly, the worker manager 140 may assign instances and containers according to one or more policies that specify which requests may be executed in which containers and which instances may be assigned to which users. An example policy may specify that instances are assigned to a collection of users that share the same account (e.g., an account for accessing services provided by the serverless computing system 110). In some embodiments, requests associated with the same user group may share the same container (e.g., if the user code associated with the request is the same). In some embodiments, tasks do not distinguish between different users of the group, but simply indicate the group to which the user associated with the task belongs.

[0043] Once the front end 120 successfully processes the triggering event for executing the task, the front end 120 passes the request to the worker manager 140 to execute the task. In one embodiment, each front end 120 can be associated with a corresponding worker manager 140 (e.g., a worker manager 140 co-located with the front end 120 or geographically close to the front end), and therefore, the front end 120 can pass most or all requests to the worker manager 140. In another embodiment, the front end 120 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 to receive the call based on hashing the call, and distribute the call to the worker manager 140 selected based on the hash 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.

[0044] like Figure 1BAs shown, various combinations and configurations of host computing devices 150A-C, virtual machine instances 154A-E, and containers 158A-I can be used to facilitate the execution of user-submitted code. In the example shown, host computing device 150A implements three virtual machine instances 154A, 154B, and 154C. Virtual machine instance 154A in turn implements two containers 158A and 158B that contain parent task 162 and subtask 174A, respectively. Virtual machine instance 154B implements two containers 158C and 158D that contain parent task 182 and subtask 184A, respectively. Host computing device 150B also implements virtual machine instance 154C, and directly implements container 158F that contains subtask 184B. Virtual machine instance 154C in turn implements container 158E that contains subtask 164A, and directly executes subtask 164B. Host computing device 150C implements virtual machine instance 154D, which implements container 158G that contains subtask 164C. The host computing device 150C also implements a virtual machine instance 154E that implements a container 1581 that contains a parent task 192. It will be appreciated that these embodiments are described for purposes of example and that numerous other embodiments are within the scope of the present disclosure.

[0045] Host computing devices 150A-C, virtual machine instances 154A-E, and containers 158A-I may be generally referred to herein as "sandbox environments" or "sandboxes" that implement secure, isolated environments for executing user-submitted code (e.g., tasks 162, 164A-C, 174A, 174B, 182, 184A, 184B, and 192). These sandbox environments may be isolated from each other in terms of networking or communication, for example, except through the use of an ephemeral mesh network described below.

[0046] The ephemeral cluster manager 130 implements and manages ephemeral clusters 160, 170, 180, and 190 of various clusters that include sandbox environments. In the illustrated embodiment, the ephemeral cluster 160 includes a container 158A (which includes a parent task 162), a container 158E (which includes a subtask 164A), a virtual machine instance 154C (which implements subtask 164B), and a container 158G (which includes subtask 164C). The ephemeral cluster 170 includes a container 158B and a container 158H that include subtasks 174A and 174B, respectively. The ephemeral cluster 180 includes containers 158C, 158D, and 158F that include a parent task 182, a subtask 184A, and a subtask 184B, respectively. The ephemeral cluster 190 includes a container 158I that includes a parent task 192. As described below with reference to Figure 1C , Figure 1D and Figure 1EAs described in more detail, the sandbox environments in these ephemeral clusters 160, 170, 180, and 190 can be connected to each other via ephemeral mesh networks that can be created and destroyed as parent and child tasks execute. It will also be understood that these embodiments are described for purposes of example, and many other embodiments are within the scope of this disclosure.

[0047] Although some functionalities are generally described herein with reference to individual components of serverless computing system 110, other components or combinations of components may additionally or alternatively implement these functionalities. For example, worker manager 140 may operate to provide some or all of the functionality associated with implementing an ephemeral cluster or ephemeral mesh network as described herein with reference to ephemeral cluster manager 130.

[0048] Reference Figure 1C , Figure 1D and Figure 1E , describes an example of an ephemeral mesh network that may be implemented by the ephemeral cluster manager 130. Figure 1C In the short-term cluster 160, the sandbox environment is connected by a short-term mesh network 166, thereby realizing the communication between the parent task 162 and the subtask 164A-C. Similarly, the sandbox environment in the short-term cluster 180 is connected by a short-term mesh network 186, thereby realizing the communication between the parent task 182 and the subtask 184A and 184B. As described in more detail below, when subtask 164A-C starts to execute, a short-term mesh network 166 can be dynamically generated and maintained so that when subtasks 164A, 164B and 164C start and end their execution, they are added to the short-term mesh network and removed from the short-term mesh network. Similarly, when subtask 184A starts to execute (or, in some embodiments, when parent task 182 starts to execute), a short-term mesh network 168 can be created, and this short-term mesh network can continue to exist until parent task 182 stops executing or until two of subtasks 184A and 184B stop executing. The ephemeral mesh networks 166 and 186 may be implemented by providing network interfaces, opening ports, assigning Internet Protocol ("IP") addresses, creating or maintaining routing tables, or otherwise configuring a sandbox environment (e.g., container 158A, virtual machine instance 154C, etc.) in which the parent task 162 and subtasks 164A-C execute. It will also be understood that for clarity of description, the sandbox environment itself is not implemented in the Figure 1C , Figure 1D and Figure 1E , although in many embodiments it is a sandbox environment rather than the tasks performed therein that are configured to create, manage, and remove the depicted ephemeral mesh network.

[0049] Figure 1DAn embodiment is depicted in which the user computing device 102 implements a parent process 172 (which may be referred to herein as a "controller process") that communicates with subtasks 174A and 174B via network 104. Subtasks 174A and 174B, in turn, communicate with each other via ephemeral mesh network 176. As described in more detail below, a parent process 172 external to the serverless computing system (or, in some embodiments, executed as a task in the serverless computing system) may invoke an application programming interface ("API") call to create a subtask (e.g., subtask 174A or 174B) and connect the subtask to an ephemeral mesh network (e.g., ephemeral mesh network 176). In such an embodiment, the parent process 172 itself may not be connected to the ephemeral mesh network 176, and may communicate only with subtasks 174A and 174B via the API.

[0050] Figure 1E Such an embodiment is depicted in which a transient cluster 190 contains only a single sandbox environment, which is the environment (i.e., container 158I) in which a parent task 192 executes. Illustratively, a transient cluster such as cluster 190 may be defined or created when a parent task 192 initially executes (i.e., before it has created any subtasks), or when a task that does not create any subtasks executes. In some embodiments, a corresponding transient mesh network may be created when a transient cluster 190 is defined, and the sandbox in which the parent task 192 executes may be connected to this transient mesh network as its only member. If and when the parent task 192 requests the creation of a subtask, then this network may be subsequently extended. In other embodiments, the creation of a transient mesh network may be postponed until there are at least two sandboxes to be connected (e.g., after the parent task 192 has created subtasks), or if the parent task 192 does not create any subtasks, the creation of a transient mesh network may be omitted entirely. Similarly, in some embodiments, for a "cluster" containing only one sandbox, the creation of the ephemeral cluster 190 can be postponed or omitted. In other embodiments, when the serverless computing system 110 receives a request to execute a parent task 192, an ephemeral cluster 190 or a corresponding ephemeral mesh network can be created.

[0051] Figure 2A and Figure 2BFlowcharts depicting example interactions for creating and maintaining a transient cluster of sandbox computing environments and creating and maintaining a transient mesh network between sandbox computing environments in a serverless computing system by processing calls to a request interface of the serverless computing system in accordance with aspects of the present disclosure. As discussed above, the example interactions can allow a serverless computing environment to support faster and more efficient execution of tightly coupled parallel computing tasks by enabling communication between sandbox environments within the serverless computing environment and removing the need for these tasks to communicate indirectly by sending messages to an external server. Now referring to Figure 2A , at (1), a parent process 172 executing on the user device 102 may request a first execution of the subtask. In some embodiments, the parent process 172 may alternatively be a task executing on a serverless computing environment rather than a process executing on the user device 102. As described in more detail above, the parent process 172 may request execution of the subtask by transmitting a call to the front end 120. The call may be transmitted via a GUI, CLI, API, or other interface of the front end 120.

[0052] In some embodiments, the call transmitted at (1) may include a user-defined mesh network identifier. The user-defined mesh network identifier may illustratively be any string, number, hash, token, key, signature, or other identifier. As described in more detail below, the user-defined mesh network identifier may be combined with other information to form a transient mesh network identifier that uniquely identifies the transient mesh network on which the subtask should be assigned an address, and if there is currently no transient mesh network corresponding to the user-defined identifier, the transient mesh network identifier may be used as a request to create the transient mesh network. For example, a user may request execution of the first instance of a subtask, and may include the identifier "abc123" with the request. In other embodiments, as described in more detail below, if the request does not include a transient mesh network identifier, a transient mesh network identifier may be generated for the user. For example, the transient mesh network identifier may be generated based on a user identifier, based on a subtask, based on a request, based on other attributes of a user or task, or randomly generated.

[0053] At (2), as described in more detail above, front end 120 communicates a request to execute the subtask to worker manager 140. In some embodiments, front end 120 may request worker manager 140 to transmit to ephemeral cluster manager 130 an ephemeral mesh network identifier and a sandbox identifier of a sandbox computing environment in which to execute the subtask. The sandbox identifier may illustratively be a network address assigned to the sandbox, a network address assigned to a physical host computing device or virtual machine instance on which the sandbox resides, or another identifier that may be used to uniquely identify a sandbox. At (3), worker manager 140 selects a sandbox in which the subtask will execute (or, in some embodiments, causes its creation).

[0054] At (4), worker manager 140 reserves (or, in some embodiments, causes host computing device 150A or a virtual machine instance to create) a sandbox 202A in which the subtask will execute. In various embodiments, as described in more detail above, sandbox 202A may be a host computing device (e.g., host computing device 150A), a virtual machine instance (e.g., Figure 1B ), a container on a host computing device or a virtual machine instance (e.g., Figure 1B Container 158B depicted in ), or another sandbox computing environment. At (5), the subtask is executed in sandbox 202A.

[0055] At (6), the worker manager 140 generates a transient mesh network identifier based on the user-defined identifier and other information. For example, the worker manager 140 may generate a transient mesh network identifier based on the user-defined identifier and user account information, information contained in the request received at (1), a sandbox identifier of the sandbox 202A, or other information. Illustratively, the user-defined identifier may be combined with other information to prevent two users who both request a transient mesh network using the same user-defined identifier (e.g., "abc123") from connecting to the same transient mesh network. At (7), the worker manager 140 transmits the transient mesh network identifier and the sandbox identifier of the sandbox 202A to the transient cluster manager 130. In some embodiments, the worker manager 140 transmits the sandbox identifier to the front end 120, which then transmits the transient mesh network identifier and relays the sandbox identifier to the transient cluster manager 130.

[0056] At (8), in some embodiments, the ephemeral cluster manager 130 generates an ephemeral mesh network corresponding to the ephemeral mesh network identifier and connects the sandbox 202A to the ephemeral mesh network. Illustratively, the ephemeral cluster manager 130 may determine that the ephemeral mesh network does not yet exist by requesting information from the ephemeral cluster data repository 132 and receiving a response indicating that no such network exists. In other embodiments, the ephemeral mesh network corresponding to the identifier may already exist, and the ephemeral cluster manager 130 may connect the sandbox 202A to the existing ephemeral mesh network. The ephemeral cluster manager 130 may determine that the ephemeral mesh network with this identifier already exists, for example, by requesting and receiving information from the ephemeral cluster data repository 132. In still other embodiments, if the sandbox 202A is created at this time, the ephemeral cluster manager 130 may determine that the sandbox will be the only entity on the ephemeral mesh network, and therefore the creation of the ephemeral mesh network may be postponed until at least two entities are on the network. It will be appreciated that in some embodiments, an ephemeral cluster may be defined as a collection of sandboxes connected to each other via a particular ephemeral mesh network, and therefore the ephemeral mesh network identifier may also be used as the ephemeral cluster identifier. In other embodiments, as described above, creation of an ephemeral mesh network may be deferred until the network is needed (e.g., until there are at least two sandboxes to be placed on the network), and an ephemeral cluster may be defined as a single sandbox 202A that may (or may not) eventually join the ephemeral mesh network and communicate with other sandboxes. At (9), the ephemeral cluster manager 130 may store information about the ephemeral cluster, ephemeral mesh network, and / or sandbox 202A in the ephemeral cluster data store 132. Such information may include, for example, an ephemeral mesh network identifier, a sandbox identifier, a network address of the identified sandbox 202A, an ephemeral mesh network address assigned to the sandbox 202A, or other such information.

[0057] It should be understood that Figure 2A are provided for purposes of example, and many variations of the interactions depicted are within the scope of the present disclosure. For example, the interactions at (6), (7), (8), and (9) may be performed before or in parallel with the interactions at (4) and (5). As another example, upon receiving the request at (1), front end 120 may generate all or part of the ephemeral mesh identifier (e.g., by appending a user identifier or using the user identifier as the ephemeral mesh identifier). Figure 2A The present invention is therefore to be regarded as illustrative rather than restrictive.

[0058] Reference now Figure 2B, an example interaction for handling a second request to execute an instance of a subtask will be described. At (1), parent process 172 transmits a second request to front end 120 to execute a second instance of a subtask. In the second request, parent process 172 transmits the same user-defined mesh network identifier included in the first request. The interactions at (2), (3), (4), and (5) are thus similar to Figure 2A , but a different sandbox 202B is selected and used, and for the sake of brevity, the description of these interactions is not repeated. At (6), the worker manager 140 generates the same input as Figure 2A , and provides the ephemeral mesh identifier and the sandbox identifier of the newly assigned sandbox 202B to the ephemeral cluster manager 130 at (7).

[0059] At (8), the ephemeral cluster manager 130 requests information about the ephemeral mesh network with the specified identifier from the ephemeral cluster data store 132, and at (9), the ephemeral cluster data store 132 responds with the requested information. Illustratively, the information may include a list of sandbox identifiers of sandboxes, such as sandbox 202A, that have been connected to the identified ephemeral mesh network. At (10), the ephemeral cluster manager 130 adds sandbox 202B to the ephemeral mesh network. As discussed above, adding or connecting sandbox 202B to the ephemeral mesh network may include creating a network interface on sandbox 202B, assigning an address to sandbox 202B, opening a port on sandbox 202B, or otherwise connecting sandbox 202B to the ephemeral mesh network. In some embodiments, the ephemeral cluster manager 130 may transmit information to sandboxes 202A and 202B to enable communication between the sandboxes, such as an updated list of sandboxes and their ephemeral mesh network addresses. At (11), the ephemeral cluster manager 130 stores the updated ephemeral mesh information including the address assigned to the new sandbox 202B to the ephemeral cluster data store 132.

[0060] At (12), subtask 174A executing in sandbox 202A and subtask 174B executing in sandbox 202B can communicate with each other via the ephemeral mesh network. Illustratively, subtasks 174A and 174B can exchange information that enables efficient, low-latency execution of tightly coupled parallel applications, as described in more detail above. Subtasks 174A and 174B can also communicate with other subtasks via the ephemeral mesh network, and can communicate with parent process 174 via an API or other interface provided by front end 120 or another component of serverless computing system 110.

[0061] It should be understood that Figure 2Bare provided for purposes of example, and many variations of the interactions depicted are within the scope of the present disclosure. For example, the interactions at (6), (7), (8), (9), (10), and (11) may be performed before or in parallel with the interactions at (4) and (5). As another example, ephemeral cluster manager 130 may generate an ephemeral mesh network rather than obtaining an existing ephemeral mesh network (e.g., where creation of the ephemeral mesh network is deferred until it has at least two participants), and may add both of subtasks 174A and 174B to the ephemeral mesh network. Figure 2B The present invention is therefore to be regarded as illustrative rather than restrictive.

[0062] Figure 3A and 3B is a flow chart depicting example interactions for creating and maintaining an ephemeral cluster of sandbox computing environments and an ephemeral mesh network between sandbox computing environments in a serverless computing system by providing a mechanism for a parent task executing on the serverless computing system to create child tasks in accordance with aspects of the present disclosure. As discussed above, the example interactions can allow a serverless computing environment to support faster and more efficient execution of tightly coupled parallel computing tasks by enabling communication between sandbox environments within the serverless computing environment and removing the need for these tasks to communicate indirectly by sending messages to an external server. Now referring to Figure 3A At (1), the user device 102 may transmit to the front end 120 of the serverless computing system the information in the serverless computing system (eg, Figure 1B 10 ). As described above, the request may be sent via an API or other interface of the front end 120. In some embodiments, the request may specify that task 162 is a parent task and will therefore require an ephemeral mesh network. At (2), the front end 120 passes the request to execute the parent task to the worker manager 140, which selects a sandbox (or, in some embodiments, causes its creation) in which the parent task will execute at (3).

[0063] At (4), worker manager 140 reserves (or, in some embodiments, causes host computing device 150A or a virtual machine instance to create) a sandbox 302A in which parent task 162 will execute. In various embodiments, as described in more detail above, sandbox 302A may be a host computing device (e.g., host computing device 150A), a virtual machine instance (e.g., Figure 1B ), a container on a host computing device or a virtual machine instance (e.g., Figure 1B Container 158A depicted in ), or another sandbox computing environment. At (5), parent task 162 executes in sandbox 302A.

[0064] At (6), the parent task 162 transmits the sandbox identifier of the sandbox 302A in which the parent task is executing to the ephemeral cluster manager 130. In some embodiments, the sandbox identifier of the sandbox 302A can be used to identify the ephemeral mesh network associated with the parent task 162. In other embodiments, the ephemeral mesh network identifier can be generated from information specific to the execution instance of the parent task 162, information derived from the request transmitted at (1), or other information corresponding to the parent task 162. Additionally, in some embodiments, the request to execute the parent task 162 can include a request to generate an ephemeral mesh network. In other embodiments, an ephemeral mesh network or ephemeral cluster can be automatically generated each time the front end 120 receives a request to execute a task.

[0065] At (7), in some embodiments, the ephemeral cluster manager 130 generates an ephemeral mesh network corresponding to the ephemeral mesh network identifier and connects the sandbox 302A to the ephemeral mesh network. In some embodiments, the ephemeral cluster manager 130 may postpone the creation of the ephemeral mesh network until at least two entities will be on the network (e.g., until the parent task 162 requests the creation of a child task). It will be appreciated that in some embodiments, an ephemeral cluster may be defined as a collection of sandboxes connected to each other via a particular ephemeral mesh network, and thus the ephemeral mesh network identifier may also be used as a ephemeral cluster identifier. In other embodiments, an ephemeral cluster may be defined as a single sandbox 302A that may (or may not) eventually join an ephemeral mesh network and communicate with other sandboxes.

[0066] At (8), the ephemeral cluster manager 130 may store information about the ephemeral cluster, ephemeral mesh network, and / or sandbox 302A in the ephemeral cluster data store 132. Such information may include, for example, an ephemeral mesh network identifier, a sandbox identifier, a network address of the identified sandbox 302A, an ephemeral mesh network address assigned to the sandbox 302A, or other such information.

[0067] It should be understood that Figure 3A are provided for purposes of example, and many variations of the interactions depicted are within the scope of the present disclosure. For example, the interactions at (6), (7), and (8) may be performed before or in parallel with the interactions at (4) and (5). As another example, front end 120 may generate all or part of the ephemeral mesh identifier upon receiving the request at (1). Figure 3A The present invention is therefore to be regarded as illustrative rather than restrictive.

[0068] Reference now Figure 3B, an example interaction for handling a request from a parent task 162 to execute an instance of a subtask 164A will be described. In some embodiments, the subtask 164A may be a copy of the parent task 162, and the parent task 162 may specify a function or other entry point into the code of the subtask 164A that causes the execution of the subtask 164A to be different from the execution of the parent task 162. In other embodiments, the subtask 164A may correspond to executable code that is different from the parent task 162.

[0069] At (1), parent task 162 sends a request to ephemeral cluster manager 130 to execute an instance of a child task on serverless computing system 110, and at (2), ephemeral cluster manager 130 forwards this request to worker manager 140. The interactions at (3), (4), and (5) are thus similar to Figure 3A , but a different sandbox 302B is selected and used, and for the sake of brevity, the description of these interactions is not repeated. At (6), the worker manager 140 provides the sandbox identifier of the newly assigned sandbox 302B to the ephemeral cluster manager 130. In some embodiments, as discussed above, each parent task 162 can be associated with a unique ephemeral mesh network identifier, which can be automatically generated when a request to execute the parent task is received. In other embodiments, the ephemeral mesh network identifier can be generated in response to a request to execute a child task or when the parent task 162 registers its sandbox 302A with the ephemeral cluster manager 130.

[0070] At (7), the ephemeral cluster manager 130 requests information about an ephemeral mesh network with a specified identifier from the ephemeral cluster data store 132. In some embodiments, as discussed above, in response to a request to execute a parent task, an ephemeral mesh network may be created, in which case information about an already existing ephemeral mesh network may be returned at (8). The ephemeral cluster manager 130 may then add the sandbox 302B to the ephemeral mesh network corresponding to the parent task 162 at (9). In other embodiments ( Figure 3B 302B), the ephemeral cluster data store 132 may report at (8) that the parent task currently has no ephemeral mesh network associated with it, and the ephemeral cluster manager 130 may create an ephemeral mesh network at (9) and add both sandboxes 302A and 302B to the newly created network. At (10), the ephemeral cluster manager 130 stores updated information about the ephemeral mesh network and the connected sandboxes 302A and 302B to the ephemeral cluster data store 132.

[0071] At (11), the parent task 162 executing in the sandbox 302A and the child task 164A executing in the sandbox 302B can communicate with each other via the ephemeral mesh network. Illustratively, the parent task 162 and the child task 164A can exchange information that enables efficient, low-latency execution of tightly coupled parallel applications, as described in more detail above. The parent task 162 can also spawn additional child tasks that can communicate with their parent task 162 and sibling tasks via the ephemeral mesh network. Thus, Figure 3A and Figure 3B The implementation scheme described in Figure 2A and Figure 2B The embodiment described in differs, among other things, in that the parent task 162 is on an ephemeral mesh network and can communicate with its child tasks via this network, rather than via the front end 120. In some embodiments, the parent task 162 can wait until one or more of its child tasks have completed execution before it completes execution.

[0072] It should be understood that Figure 3B is provided for example purposes, and many variations of the interactions depicted are within the scope of the present disclosure. For example, the interactions at (6), (7), (8), (9), and (10) may be performed before or in parallel with the interactions at (4) and (5). As another example, sandbox 302A and sandbox 302B may be hosted on different host computing devices. Figure 3B The present invention is therefore to be regarded as illustrative rather than restrictive.

[0073] Figure 4A is a flow chart depicting an example routine 400 for generating and maintaining ephemeral clusters and ephemeral mesh networks by processing calls to a mesh network creation interface in accordance with aspects of the present disclosure. The routine 400 may be performed, for example, by Figure 1B . The routine 400 begins at box 402, in which a request to execute an instance of a subtask in a serverless computing environment may be received. The request may illustratively be received from a parent process or a controller process, as discussed in more detail above. The request may include a user-defined mesh network identifier, which, as discussed above, may be a user-generated string or other identifier of a transient mesh network. For example, the request may specify that an instance of the subtask join a transient mesh network associated with a user identifier "abc123". In some embodiments, the user-defined transient mesh network identifier may be omitted, and the routine 400 may generate a default transient mesh network identifier based on attributes of the request, the user making the request, or other information.

[0074] At block 404, an ephemeral mesh network identifier may be generated based on the user-defined identifier received at block 402 and other information associated with the request (or, in some embodiments, information associated with the user making the request). As described in more detail above, the ephemeral mesh network identifier may combine the user-defined identifier with the other information to prevent the user-defined identifiers from inadvertently colliding.

[0075] At decision block 406, it may be determined whether a transient mesh network with the identifier generated at block 404 already exists. If not, then at block 408, a transient mesh network with this identifier may be created. Illustratively, the transient mesh network may initially be created as an empty list, and the sandbox computing environment may be added to the list later (e.g., when block 412 of routine 400 is performed). In some embodiments, it may be determined whether the transient mesh network will include at least two sandbox computing environments, and if not, creation of the network may be postponed until it is needed. If it is determined at decision block 406 that a transient mesh network with the specified identifier exists, then routine 400 instead branches to block 410, where a transient mesh network with the specified identifier may be obtained.

[0076] Routine 400 then continues at box 412, where the subtask can be executed in a sandbox computing environment of a serverless computing system. As described in more detail above, a worker manager or other component of a serverless computing system can create a sandbox computing environment or select an existing sandbox computing environment in which to execute an instance of a subtask. At box 414, a sandbox computing environment can be added to a transient mesh network generated at box 408 or obtained at box 410. Illustratively, a sandbox computing environment can be added to a transient mesh network by allocating addresses on a transient mesh network and establishing one or more routes between a newly added sandbox and other participants in the transient mesh network. A host computing device and / or a virtual machine instance can encapsulate traffic between sandboxes using, for example, GENEVE tunnels or other encapsulation techniques, and a mapping table can be generated for each sandbox computing environment that converts addresses on a transient mesh network into network addresses of devices or instances in a serverless computing environment.

[0077] It should be understood that Figure 4A 400 is provided for example purposes, and many variations on the illustrated procedure 400 are within the scope of the present disclosure. For example, the determination at decision block 404 may be as to whether the request received at block 402 is the first request (or second request) received with the specified mesh network identifier. As another example, block 414 may be performed prior to or in parallel with causing the subtask to begin execution in the sandbox. Figure 4A The present invention is therefore to be regarded as illustrative rather than restrictive.

[0078] Figure 4B 4 is a flowchart depicting an example routine 450 for generating and maintaining ephemeral clusters and ephemeral mesh networks by processing requests from tasks executed in a serverless computing environment in accordance with aspects of the present disclosure. The routine 450 may be performed, for example, by Figure 1B 4. The routine 450 begins at block 452, where a request may be received from a parent task executing in a container in a serverless computing environment. The parent task may illustratively be any task executing on a serverless computing system that requests the creation of a child task. In some embodiments, the parent task may be a child task of a "grandfather" task, and the creation of a "grandchild" task may be requested at block 452.

[0079] In decision box 454, it can be determined whether there is an existing transient mesh network corresponding to the parent task. For example, the transient mesh network corresponding to the parent task may have been generated by a previous execution of routine 450. In some embodiments, it can be determined whether any subtasks have been created previously with respect to the parent task. In other embodiments, when a request to execute the parent task is received, a corresponding transient mesh network can be created, in which case, decision box 454 and box 456 can be omitted. If the determination in decision box 454 is that there is no existing transient mesh network corresponding to the parent task, then in box 456, a transient mesh network can be created, and the container in which the parent task is being executed can be added to the network. If the determination in decision box 454 is that there is a transient mesh network for the parent task instead, then in box 458, a transient mesh network can be obtained. Thereafter, in box 460, an instance of a subtask can be executed in a container in a serverless computing environment, as described in more detail above. In box 462, the container in which the subtask is being executed can be added to the transient mesh network, as described above.

[0080] At block 464, in some embodiments, the routine 450 may set a trigger event for removing the ephemeral mesh network (e.g., by performing an action such as Figure 5 450) to ensure that the short-lived mesh network corresponding to the parent task is removed. In some embodiments, as described in more detail below, the triggering event can be that the parent task has stopped executing, and routine 450 can therefore start the monitoring of the execution of the parent task. In other embodiments, the triggering event can be the garbage collection of the parent task, the amount of time that the parent task starts to execute the beginning or another standard for removing the short-lived mesh network. In other embodiments, the execution of monitoring the parent task can include the execution of monitoring each subtask, and if and when they stop executing, remove their sandboxes from the short-lived mesh network.

[0081] It should be understood that Figure 4B450 is provided for example purposes, and many variations on the illustrated procedure 450 are within the scope of the present disclosure. For example, block 460 may be performed prior to or in parallel with obtaining or generating an ephemeral mesh network. As another example, the determination at decision block 454 may be about whether an attempt to obtain an existing ephemeral mesh network was successful. Figure 4A The present invention is therefore to be regarded as illustrative rather than restrictive.

[0082] Figure 5 is a flow chart depicting an example routine 500 for monitoring the execution of a parent task and cleaning up its ephemeral mesh network in accordance with aspects of the present disclosure. The routine 500 may be performed, for example, by Figure 1B The routine 500 begins at block 502 where a request to monitor execution of a parent task (e.g., a task that has requested execution of a child task) in a serverless computing environment may be received. The request may be received, for example, from Figure 4B Received by routine 450 depicted in . In some embodiments, routine 500 can be automatically performed by the serverless computing system whenever a transient mesh network is created. At box 504, routine 500 can begin monitoring the execution of the parent task. Monitoring the execution of the parent task can illustratively include internal or external monitoring of the sandbox computing environment in which the parent task is executing. For example, routine 500 can monitor "heartbeats", CPU usage, memory usage, or other metrics of activities performed by the parent task. In some embodiments, as discussed above, routine 500 can alternatively monitor whether a garbage collection process has collected the parent task.

[0083] At decision block 506, it may be determined whether the parent task is still executing (or, in some embodiments, whether the parent task has been garbage collected). In various embodiments, decision block 506 may be performed periodically in response to various events (e.g., receiving a message or output from the parent task, CPU usage dropping below a threshold, detecting an indication that the parent task may have been terminated or garbage collected, etc.), or according to other criteria. In some embodiments, it may be determined whether the duration of execution of the parent task has exceeded a threshold, such as an upper limit on how long a task may execute in a serverless computing environment. If the determination at decision block 506 is that the parent task is still executing, the routine 500 branches to block 504 and continues to monitor the execution of the parent task until it is no longer executing.

[0084] If the determination in decision box 506 is that the parent task is no longer executed, then in box 508, the transient mesh network associated with the parent task can be obtained. In some embodiments, there may be a single transient mesh network corresponding to the parent task and identified by a unique identifier of the parent task. In other embodiments, there may be multiple transient mesh networks associated with the parent task, and these networks can be iteratively obtained until there are no more additional transient mesh networks associated with the parent task remaining. In box 510, any subtasks on the transient mesh network are terminated, and their sandboxes are disconnected from the transient mesh network. In box 512, the sandbox in which the parent task is executed is disconnected from the transient mesh network, thereby leaving no entity on the network, and the transient mesh network is removed (e.g., from the data repository from which the transient mesh network was obtained).

[0085] It should be understood that Figure 5 500 is provided for purposes of example, and many variations on the illustrated routine 500 are within the scope of the present disclosure. For example, blocks 508, 512, and 513 of routine 500 may be performed by the serverless computing system as part of post-execution cleanup of a sandbox computing environment associated with a parent task, rather than performing a separate routine to monitor execution of the parent task. As another example, routine 500 may receive a signal indicating that the parent task has stopped executing, rather than receiving a request to monitor execution of the parent task. Figure 5 The present invention is therefore to be regarded as illustrative rather than restrictive.

[0086] Figure 6 The overall architecture of a computing system, referred to as ephemeral cluster manager 130 , that operates to manage ephemeral clusters and ephemeral mesh networks within on-demand code execution system 110 is shown. Figure 6 The overall architecture of the worker manager 130 depicted in FIG. 1 includes an arrangement of computer hardware and software modules that can be used to implement various aspects of the present disclosure. The hardware modules can be implemented using physical electronic devices, as discussed in more detail below. The worker manager 130 can include, for example, Figure 6 More (or fewer) elements than those shown in the drawings. However, it is not necessary to show all of these generally conventional elements to implement the present disclosure. In addition, Figure 6 The overall architecture shown in can be used to implement Figure 1A to Figure 1BOne or more of the other components shown. As shown, the transient cluster manager 130 includes a processor 602, an input / output device interface 604, a network interface 606, and a data repository 608, all of which can communicate with each other through a communication bus 610. The network interface 606 can provide connectivity to one or more networks or computing systems (such as user devices 102, auxiliary services 106, data storage services 108, or other components of the serverless computing system 110). The processor 602 can therefore receive information and instructions from other computing systems or services via the network 104. The processor 602 can also communicate to and from the memory 620, and can also provide output information to an optional display (not shown) via the input / output device interface 604. The input / output device interface 604 can also receive input from an optional input device (not shown).

[0087] The memory 620 may contain computer program instructions (which are grouped into modules in some embodiments) that the processor 602 executes to implement one or more aspects of the present disclosure. The memory 620 typically includes a random access memory (RAM), a read-only memory (ROM), and / or other persistent, auxiliary, or non-transitory computer-readable media. The memory 620 may store an operating system 622 that provides computer program instructions for use by the processing unit 602 in the general management and operation of the ephemeral cluster manager 130. The memory 620 may further include computer program instructions and other information for implementing various aspects of the present disclosure. For example, in one embodiment, the memory 620 includes an interface module 624 that generates an interface (and / or instructions for it) for interacting with the front end 120, the worker manager 140, or other computing devices, for example, via an API, a CLI, and / or a Web interface. In addition, the memory 620 may include one or more data repositories (not shown) and / or communicate with the one or more data repositories, for example, to access user program code and / or libraries.

[0088] In addition to and / or in conjunction with the interface module 624, the memory 620 may include an ephemeral cluster management module 626 that may be executed by the processor 602. In one embodiment, the ephemeral cluster management module 626 implements aspects of the present disclosure, such as generating and managing ephemeral clusters and ephemeral mesh networks, as further described above. Figure 610 is shown as part of the ephemeral cluster manager 130, but in other embodiments, all or part of the ephemeral cluster management module 626 may be implemented by other components of the on-demand code execution system 110 and / or another computing device. For example, in certain embodiments of the present disclosure, another computing device in communication with the on-demand code execution system 110 may include several modules or components that operate similarly to the modules and components shown as part of the ephemeral cluster manager 130.

[0089] The memory 620 may also include ephemeral cluster data 628, ephemeral mesh network data 630, and sandbox data 632, which may be loaded into the memory in conjunction with generating and maintaining ephemeral clusters and ephemeral mesh networks for the on-demand code execution system 110. In some embodiments, the memory 620 may also include, for example, information about a particular host computing device or virtual machine instance, a particular request to perform a subtask, or other information for generating or maintaining an ephemeral mesh network.

[0090] In some embodiments, the ephemeral cluster manager 130 may also include Figure 6 For example, memory 620 may also include information regarding pending requests to perform subtasks, ephemeral mesh network identifiers, or other information that facilitates managing ephemeral clusters and ephemeral mesh networks. Figure 6 The present invention is therefore to be regarded as illustrative rather than restrictive.

[0091] It will be understood that not necessarily all objects or advantages may be achieved in accordance with any particular embodiment described herein. Thus, for example, those skilled in the art will recognize that certain embodiments may be configured to operate in a manner that achieves or optimizes one advantage or group of advantages as taught herein without necessarily achieving other objects or advantages that may be taught or suggested herein.

[0092] All of the processes described herein may be embodied in and entirely automatically via a software code module comprising one or more specific computer executable instructions executed by a computing system. The computing system may include one or more computers or processors. The code module may be stored in any type of non-transitory computer readable medium or other computer storage device. Some or all of the methods may be embodied in dedicated computer hardware.

[0093] Many other variations in addition to those described herein will be apparent in light of the present disclosure. For example, depending on the embodiment, certain actions, events, or functions of any of the algorithms described herein may be performed in a different order, may be added, merged, or omitted entirely (e.g., not all of the described actions or events are necessary for the practice of the algorithm). Furthermore, in certain embodiments, actions or events may be performed simultaneously (e.g., by multithreading, interrupt handling, or multiple processors or processor cores or on other parallel architectures), rather than sequentially. Additionally, different tasks or processes may be performed by different machines and / or computing systems that may run together.

[0094] The various illustrative logic blocks and modules described in conjunction with the embodiments disclosed herein may be implemented or executed by a machine, such as a processing unit or processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof, designed to perform the functions described herein. The processor may be a microprocessor, but in an alternative, the processor may be a controller, a microcontroller or a state machine, a combination thereof, or the like. The processor may include a circuit configured to process computer executable instructions. In another embodiment, the processor includes an FPGA or other programmable device that performs logic operations without processing computer executable instructions. The processor 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 in combination with a DSP core, or any other such configuration. Although this article is primarily described with respect to digital technology, the processor may also primarily include analog components. The computing environment may include any type of computer system, including, but not limited to, a computer system based on a microprocessor, 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).

[0095] Unless expressly provided otherwise, conditional language, such as, inter alia, "can," "may," "might," or "could," should be otherwise understood within the context as being generally used to convey that certain embodiments include certain features, elements, and / or steps, while other embodiments do not. Thus, 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 necessarily include logic for deciding, with or without user input or prompting, whether such features, elements, and / or steps are included or will be performed in any particular embodiment.

[0096] Unless expressly provided otherwise, connective language such as the phrase "at least one of X, Y, or Z" is otherwise understood in context to be 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.

[0097] Any process description, element or box in the flowchart described herein and / or depicted in the accompanying drawings should be understood to potentially represent a module, segment or portion of code including one or more executable instructions for implementing a specific logical function or element in the process. Those skilled in the art will appreciate that alternative implementations are included within the scope of the embodiments described herein, wherein elements or functions may be deleted, executed in an order different from that shown or discussed, including substantially simultaneously or in reverse order, depending on the functionality involved.

[0098] 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. The one or more recited devices may also be collectively configured to perform the recited 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.

[0099] The foregoing may be better understood in light of the following terms:

[0100] Clause 1. A system comprising:

[0101] a data repository configured to store computer-executable instructions; and

[0102] a processor in communication with the data repository, wherein the computer executable instructions, when executed by the processor, configure the processor to perform operations comprising:

[0103] receiving a parent task execution request to execute the parent task on the serverless computing system;

[0104] In response to the parent task execution request, causing the parent task to execute in a first sandbox environment of the serverless computing system;

[0105] receiving a subtask execution request from the parent task to execute a first instance of a subtask on the serverless computing system; and

[0106] In response to the subtask execution request:

[0107] creating an ephemeral mesh network between the first sandbox environment and a second sandbox environment of the serverless computing system;

[0108] causing the first instance of the subtask to execute in the second sandbox environment;

[0109] monitoring execution of the parent task; and

[0110] In response to determining that the parent task has ceased execution, the ephemeral mesh network between the first sandbox environment and the second sandbox environment is removed.

[0111] Clause 2. The system of clause 1, wherein the parent task execution request specifies an Internet Protocol ("IP") address range for the ephemeral mesh network.

[0112] Clause 3. The system of Clause 2, wherein creating the ephemeral mesh network comprises assigning an IP address from the IP address range to at least the second sandbox environment.

[0113] Clause 4. The system of clause 1, wherein the data repository is configured to store additional computer executable instructions that, when executed by the processor, configure the processor to perform additional operations, the additional operations comprising:

[0114] receiving, from the parent task, a second subtask execution request to execute a second instance of the subtask on the serverless computing system; and

[0115] In response to the second subtask execution request:

[0116] updating the ephemeral mesh network to include a third sandbox environment of the serverless computing system; and

[0117] The second instance of the subtask is caused to execute in the third sandbox environment.

[0118] Clause 5. The system of clause 4, wherein the data repository is configured to store additional computer executable instructions that, when executed by the processor, configure the processor to perform additional operations, the additional operations comprising:

[0119] In response to determining that the second instance of the subtask has ceased execution, removing the third sandbox environment from the ephemeral mesh network.

[0120] Clause 6. A computer-implemented method comprising:

[0121] causing the parent task to execute in a first sandbox environment of the serverless computing system;

[0122] receiving a request from the parent task to execute a first instance of a child task on the serverless computing system;

[0123] In response to the request, creating a transient mesh network between the first sandbox environment and a second sandbox environment of the serverless computing system;

[0124] causing the first instance of the subtask to execute in the second sandbox environment;

[0125] monitoring execution of the parent task; and

[0126] In response to determining that the parent task has ceased execution, the ephemeral mesh network is removed.

[0127] Clause 7. The computer-implemented method of clause 6, further comprising:

[0128] In response to determining that the parent task has ceased execution, execution of the child task is terminated.

[0129] Clause 8. The computer-implemented method of Clause 6, wherein the first instance of the subtask communicates with at least one of the parent task or a second instance of the subtask via the ephemeral mesh network.

[0130] Clause 9. The computer-implemented method of Clause 6, wherein creating the ephemeral mesh network comprises establishing a connection between a first network interface in the first sandbox environment and a second network interface in the second sandbox environment.

[0131] Clause 10. The computer-implemented method of Clause 9, further comprising creating the first network interface and the second network interface.

[0132] Clause 11. The computer-implemented method of Clause 6, further comprising, in response to determining that the parent task has ceased execution, removing the first sandbox environment.

[0133] Clause 12. The computer-implemented method of Clause 6, wherein the parent task waits for at least one instance of the child task to complete execution before the parent task completes execution.

[0134] Clause 13. The computer-implemented method of Clause 6, wherein the parent task is associated with a unique ephemeral mesh network identifier.

[0135] Clause 14. The computer-implemented method of Clause 6, wherein the first sandbox environment is on a different host computing device than the second sandbox environment.

[0136] Clause 15. The computer-implemented method of Clause 6, wherein the first sandbox computing environment comprises one or more of a host computing device, a virtual machine instance, or a container.

[0137] Clause 16. A computer-implemented method comprising:

[0138] receiving, from a parent task executing in a first sandbox environment of a serverless computing system, a request to execute a first instance of a child task on the serverless computing system;

[0139] In response to the request, creating a transient mesh network between the first sandbox environment and a second sandbox environment of the serverless computing system; and

[0140] The first instance of the subtask is caused to execute in the second sandbox environment.

[0141] Clause 17. The computer-implemented method of Clause 16, wherein the data repository is configured to store additional computer-executable instructions that, when executed by the processor, configure the processor to perform additional operations, the additional operations comprising:

[0142] In response to determining that the parent task has ceased execution, the ephemeral mesh network is removed.

[0143] Clause 18. The computer-implemented method of Clause 16, wherein the subtask is a first subtask, and wherein the data repository is configured to store additional computer-executable instructions that, when executed by the processor, configure the processor to perform additional operations, the additional operations comprising:

[0144] A request is received from the parent task to execute a first instance of a second subtask on the serverless computing system.

[0145] Clause 19. The computer-implemented method of Clause 18, wherein the data repository is configured to store yet further computer-executable instructions that, when executed by the processor, configure the processor to perform further operations, the further operations comprising:

[0146] In response to the request to execute the first instance of the second subtask on the serverless computing system:

[0147] updating the ephemeral mesh network to include a third sandbox environment of the serverless computing system; and

[0148] The first instance of the second subtask is caused to execute in the third sandbox environment.

[0149] Clause 20. The computer-implemented method of Clause 18, wherein the data repository is configured to store yet further computer-executable instructions that, when executed by the processor, configure the processor to perform further operations, the further operations comprising:

[0150] In response to the request to execute the first instance of the second subtask on the serverless computing system:

[0151] creating a second ephemeral mesh network between the first sandbox environment and a third sandbox environment of the serverless computing system; and

[0152] The first instance of the second subtask is caused to execute in the third sandbox environment.

[0153] Clause 21. A system comprising:

[0154] a data repository configured to store computer-executable instructions; and

[0155] a processor in communication with the data repository, wherein the computer executable instructions, when executed by the processor, configure the processor to perform operations comprising:

[0156] receiving, from a controller process via an application programming interface (“API”), a first request to execute a first instance of a subtask on a serverless computing system, the first request including an ephemeral mesh network identifier;

[0157] In response to the first request, causing the first instance of the subtask to execute in a first sandbox environment of the serverless computing system;

[0158] receiving, from the controller process via the API, a second request to execute a second instance of the subtask on the serverless computing system, the second request including the ephemeral mesh network identifier; and

[0159] In response to the second request:

[0160] creating a transient mesh network between the first sandbox environment and a second sandbox environment of the serverless computing system; and

[0161] The second instance of the subtask is caused to execute in the second sandbox environment.

[0162] Clause 22. The system of Clause 21, wherein the controller process comprises a parent task that executes in a third sandbox environment of the serverless computing system.

[0163] Clause 23. The system of Clause 21, wherein the controller process executes on a computing device external to the serverless computing system.

[0164] Clause 24. The system of Clause 21, wherein the first instance of the subtask communicates with the second instance of the subtask via the ephemeral mesh network.

[0165] Clause 25. The system of clause 21, wherein the data repository is configured to store additional computer executable instructions that, when executed by the processor, configure the processor to perform additional operations, the additional operations comprising:

[0166] In response to determining that the first instance of the subtask has ceased execution, removing the first sandbox environment from the ephemeral mesh network.

[0167] Clause 26. A computer-implemented method comprising:

[0168] receiving, via an application programming interface (“API”), a first request to execute a first instance of a subtask on a serverless computing system, the first request including an ephemeral mesh network identifier;

[0169] In response to the first request, causing the first instance of the subtask to execute in a first sandbox environment of the serverless computing system;

[0170] receiving, via the API, a second request to execute a second instance of a subtask on the serverless computing system, the second request including the ephemeral mesh network identifier; and

[0171] In response to the second request:

[0172] causing the second instance of the subtask to execute in a second sandbox environment of the serverless computing system; and

[0173] An ephemeral mesh network is created between the first sandbox environment and the second sandbox environment.

[0174] Clause 27. The computer-implemented method of Clause 26, further comprising:

[0175] receiving, via the API, an output from the first instance of the subtask; and

[0176] The output is transmitted to the sender of the first request via the API.

[0177] Clause 28. The computer-implemented method of Clause 27, further comprising:

[0178] In response to receiving the output from the first instance of the subtask, removing the first sandbox environment from the ephemeral mesh network.

[0179] Clause 29. The computer-implemented method of Clause 26, further comprising:

[0180] receiving, via the API, a third request to execute a third instance of the first task on the serverless computing system, the third request including the ephemeral mesh network identifier; and

[0181] In response to the third request:

[0182] causing the third instance of the subtask to execute in a third sandbox environment of the serverless computing system; and

[0183] Connecting the third sandbox environment to the ephemeral mesh network.

[0184] Clause 30. The computer-implemented method of Clause 26, wherein the ephemeral mesh network identifier is a first ephemeral mesh network identifier, wherein the ephemeral mesh network is a first ephemeral mesh network, and wherein the first ephemeral mesh network identifier includes a first user identifier and a first user-defined string.

[0185] Clause 31. The computer-implemented method of Clause 30, further comprising:

[0186] receiving, via the API, a third request to execute a third instance of the first task on the serverless computing system, the third request including a second ephemeral mesh network identifier; and

[0187] In response to the third request:

[0188] causing the third instance of the subtask to execute in a third sandbox environment of the serverless computing system;

[0189] creating a second ephemeral mesh network; and

[0190] Connecting the third sandbox environment to the second ephemeral mesh network.

[0191] Clause 32. The computer-implemented method of Clause 31, wherein the second ephemeral mesh network identifier comprises the first user identifier and a second user-generated string.

[0192] Clause 33. The computer-implemented method of Clause 31, wherein the second ephemeral mesh network identifier comprises a second user identifier and a string generated by the first user.

[0193] Clause 34. The computer-implemented method of Clause 26, further comprising:

[0194] A determination is made that the serverless computing system does not have an existing ephemeral mesh network corresponding to the ephemeral mesh network identifier.

[0195] Clause 35. The computer-implemented method of Clause 26, further comprising:

[0196] An address of the second instance of the subtask is transmitted to the first instance of the subtask over the ephemeral mesh network.

[0197] Clause 36. A computer-implemented method comprising:

[0198] causing the first instance of the subtask to execute in a first sandbox environment of the serverless computing system in response to a first request from a controller process to execute a first instance of the subtask on the serverless computing system, wherein the first request includes an ephemeral mesh network identifier; and

[0199] In response to a second request from the controller process to execute a second instance of the subtask on the serverless computing system, wherein the second request includes the ephemeral mesh network identifier:

[0200] causing the second instance of the subtask to execute in a second sandbox environment of the serverless computing system; and

[0201] connecting the second sandbox environment to the ephemeral mesh network corresponding to the ephemeral mesh network identifier; and

[0202] The first sandbox environment is connected to the ephemeral mesh network corresponding to the ephemeral mesh network identifier.

[0203] Clause 37. The computer-implemented method of Clause 36, wherein at least one of the first request or the second request is received via an application programming interface.

[0204] Clause 38. The computer-implemented method of Clause 36, further comprising creating the ephemeral mesh network in response to the first request.

[0205] Clause 39. The computer-implemented method of Clause 36, further comprising creating the ephemeral mesh network in response to the second request.

[0206] Clause 40. The computer-implemented method of Clause 36, wherein connecting the first sandbox environment to the ephemeral mesh network is in response to the first request.

Claims

1. A computer-implemented method comprising: causing the parent task to execute in a first sandbox environment of the serverless computing system; receiving a request from the parent task to execute a first instance of a child task on the serverless computing system; In response to the request, creating a transient mesh network between the first sandbox environment and a second sandbox environment of the serverless computing system; causing the first instance of the subtask to execute in the second sandbox environment; monitoring execution of the parent task; as well as In response to determining that the parent task has ceased execution, the ephemeral mesh network is removed.

2. The computer-implemented method of claim 1 , further comprising: In response to determining that the parent task has ceased execution, execution of the child task is terminated. 3 . The computer-implemented method of claim 1 , wherein the first instance of the subtask communicates with at least one of the parent task or a second instance of the subtask via the ephemeral mesh network.

4. The computer-implemented method of claim 1, wherein creating the ephemeral mesh network comprises establishing a connection between a first network interface in the first sandbox environment and a second network interface in the second sandbox environment. 5 . The computer-implemented method of claim 1 , further comprising, in response to determining that the parent task has ceased execution, removing the first sandbox environment. 6 . The computer-implemented method of claim 1 , wherein the parent task waits for at least one instance of the child task to complete execution before the parent task completes execution.

7. A system comprising: a data repository configured to store computer-executable instructions; as well as a processor in communication with the data repository, wherein the computer executable instructions, when executed by the processor, configure the processor to perform operations comprising: receiving, from a controller process via an application programming interface ("API"), a first request to execute a first instance of a subtask on a serverless computing system, the first request including an ephemeral mesh network identifier; In response to the first request, causing the first instance of the subtask to execute in a first sandbox environment of the serverless computing system; receiving, from the controller process via the API, a second request to execute a second instance of the subtask on the serverless computing system, the second request including the ephemeral mesh network identifier; and In response to the second request: creating a transient mesh network between the first sandbox environment and a second sandbox environment of the serverless computing system; and The second instance of the subtask is caused to execute in the second sandbox environment.

8. The system of claim 7, wherein the controller process comprises a parent task that executes in a third sandbox environment of the serverless computing system.

9. The system of claim 7, wherein the first instance of the subtask communicates with the second instance of the subtask via the ephemeral mesh network.

10. The system of claim 7, wherein the data repository is configured to store additional computer executable instructions that, when executed by the processor, configure the processor to perform additional operations, the additional operations comprising: In response to determining that the first instance of the subtask has ceased execution, removing the first sandbox environment from the ephemeral mesh network.

11. A computer-implemented method comprising: causing the first instance of the subtask to execute in a first sandbox environment of the serverless computing system in response to a first request from a controller process to execute a first instance of the subtask on the serverless computing system, wherein the first request includes an ephemeral mesh network identifier; In response to a second request from the controller process to execute a second instance of the subtask on the serverless computing system, wherein the second request includes the ephemeral mesh network identifier: causing the second instance of the subtask to execute in a second sandbox environment of the serverless computing system; as well as connecting the second sandbox environment to the ephemeral mesh network corresponding to the ephemeral mesh network identifier; as well as The first sandbox environment is connected to the ephemeral mesh network corresponding to the ephemeral mesh network identifier.

12. The computer-implemented method of claim 11, wherein at least one of the first request or the second request is received via an application programming interface.

13. The computer-implemented method of claim 11, further comprising creating the ephemeral mesh network in response to the first request.

14. The computer implemented method of claim 11, further comprising creating the ephemeral mesh network in response to the second request.

15. The computer-implemented method of claim 11, wherein connecting the first sandbox environment to the ephemeral mesh network is in response to the first request.

Images