Streaming analysis using server-less computing system

Abstract

Systems and methods for performing streaming analysis on a server-less computing system are described. A user may specify a data stream for which analysis should be performed, a server-less function for analysis, and criteria for analysis, such as windowing criteria and aggregation criteria. The windowing criteria may specify windows of items within the stream that should be co-analyzed. The aggregation criteria may specify how items within each window are grouped during analysis. A poller device may read data items from the stream, windowing and grouping the items according to windowing criteria and aggregation criteria, and invoking a server-less function to stream the data items. The poller device may also maintain a state between calls.

Description

[0001] This application is a divisional application of the patent application with the application number 2022800457344, the application date of June 29, 2022, and the invention title of "Streaming Analysis Using a Serverless Computing System". Background Art

[0002] 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 geographical location or in multiple different geographical locations (e.g., interconnected by private or public communication networks). Specifically, a data center or data processing center (commonly referred to herein as a "data center") can include many interconnected computing systems to provide computing resources to users of the data center. The data center can be a private data center operating on behalf of an organization or can be a public data center operating on behalf of or for the public good.

[0003] 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, which appear to 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. Subsequently, users can request computer resources from a data center that includes a configuration of single or networked computing devices and is equipped with different amounts of virtual machine resources.

[0004] In some scenarios, virtual machine instances can be configured according to several virtual machine instance types to provide specific functionality. For example, various computing devices can be associated with different combinations of operating systems or operating system configurations, virtualized hardware resources, and software applications, such that the computing devices can provide different desired functionality or more effectively provide similar functionality. These virtual machine instance type configurations are typically contained in a device image, which includes static data (e.g., an OS and applications along with their configurations and data files, etc.) that contains the software that the virtual machine will run once it is started. The device image is typically stored on a disk used to create or initialize an instance. Thus, a computing device can process the device image to implement the desired software configuration.

[0005] An example use of a data center is to process or analyze large data sets, which may be impractical to analyze using a single computing device. A particular type of data analysis is streaming data analysis, which processes or analyzes a data stream. In this context, a data "stream" is a set of data that is updated periodically or continuously and is not available as a collection. A common goal of streaming analysis is to process data "in real time" - that is, with minimal latency as the data is added to the stream. Thus, streaming analysis can be used to maintain real-time statistics on the data points on the stream, rather than, for example, waiting for all data points to be present before performing statistical analysis. Description of the Drawings

[0006] Figure 1 is an illustrative visualization of a data stream on which streaming analysis can be performed, including visualizations of windows and aggregation groups applied to the data stream for streaming analysis;

[0007] Figure 2 is a block diagram depicting an illustrative environment in which streaming analysis can be performed on a data stream by invoking a serverless function on a serverless computing system;

[0008] Figure 3 depicts providing Figure 2 of a polling device, the general architecture of a computing device configured to invoke a serverless function to perform streaming analysis on a data stream;

[0009] Figure 4 is a flowchart depicting an illustrative interaction for initiating streaming analysis of a data stream, including the specification of a serverless function to be invoked for such streaming analysis;

[0010] Figure 5 is a flowchart depicting an illustrative interaction for initiating an aggregation function on a serverless computing system to perform analysis on data items within a data stream;

[0011] Figure 6 is a flowchart depicting an illustrative interaction for initiating a target function on a serverless computing system to provide the results of streaming analysis performed on data items within a data stream using status information obtained from a call to the aggregation function; and

[0012] Figure 7 is an illustrative routine for performing streaming analysis on a data stream by invoking a serverless function on a serverless computing system. Detailed Description

[0013] Generally, aspects of the present disclosure relate to performing streaming analysis on a serverless computing system. More specifically, the present disclosure enables code execution on a serverless computing system to analyze items (e.g., “messages”) within a data stream and maintain “running” computations regarding those items, such as counts, averages, etc. Specific analyses can be established within user-defined code and are thus customized to the needs of an individual user. Embodiments of the present disclosure can enable a user to specify various criteria for streaming analysis, such as a time window for performing the analysis, a data size of a maximum number of items to be analyzed, etc. These embodiments can then facilitate submission of items within the stream to the serverless computing system such that the analysis is performed according to the various criteria established by the user (as specified in the user-defined code). In this way, embodiments of the present disclosure can facilitate rapid development and deployment of streaming analysis.

[0014] As described herein, a serverless computing system (also referred to as a “serverless code execution system” or “on-demand code execution system”) is capable of rapidly executing code that can be provided by a user of the serverless computing system. Upon submission of the code, the serverless computing system can enable the user to submit a “call” or “invoke” to execute the code, at which point the serverless computing system will generate an execution environment for the code and execute the code within the environment to provide the desired functionality. The environment can then be destroyed shortly after providing the desired functionality such that the user is only responsible for the resources used during execution. These execution times are typically very short, making serverless computing very efficient, especially for tasks with varying levels of demand. However, since the serverless computing system (as opposed to the end user) typically handles the management of the execution environment, including selection of the host device on which to place the environment, the end user generally cannot guarantee that a particular call will result in execution within a particular environment. For this reason, serverless execution is typically designed to be stateless, or even restricted to being stateless, such that the result of one code execution does not depend on the processing completed during a previous code execution.

[0015] In the context of streaming analysis, the stateless nature of serverless execution can be problematic because many streaming analyses rely specifically on state. For example, performing a running count or average of data items in a stream requires the system to know the state regarding the count or average of old data items when evaluating one or more new data items. When the system can alternatively only process data items in batches (e.g., without considering the state associated with previous items), this effectively converts the analysis to batch analysis rather than streaming analysis. Thus, in a default configuration, it may not be possible to perform streaming analysis on a serverless computing system.

[0016] Embodiments of the present disclosure address the above problems by enabling typical stateful processing, such as streaming analytics, to be implemented within a stateless execution environment, such as that provided by a serverless computing system. As will be described in more detail below, embodiments of the present disclosure enable an intermediate device to maintain state information related to iterative data processing (e.g., streaming analytics) and submit the state information in each request for code execution on a serverless computing system. The intermediate device can obtain updated state information in response to each invocation and include the updated state information in the next invocation. In this way, the execution environment on the serverless computing system is relieved of the obligation to maintain state information and can continue to operate statelessly. However, state information can still be maintained when processing a set of data, enabling successful stateful analysis of streaming data. As described below, the intermediate device can be configured to ensure the resilience of operations such that failures within the system processing the data set can be identified and corrected. Additionally, the intermediate device can be configured to ensure efficient resilience such that providing resilience does not have a substantial negative impact on the system's ability to process streaming data.

[0017] In one embodiment, the intermediate device is a poller device that is used to retrieve items from a data stream and pass the items for processing to code execution on a serverless computing system. Illustratively, a poller device according to an embodiment of the present disclosure can determine initial state information (e.g., as an empty state) for processing data items on the stream, retrieve an initial set of items from the stream, and iteratively submit these items along with current state information representing the state of the stream processing to the serverless computing system. The poller device can be configured to receive updated state information in response to each invocation, which can be included in subsequent invocations. Since the state information of the stream is passed in each invocation, the environment itself on the serverless computing system does not need to maintain state information. For this reason, there is generally no need for correlation between the poller device and the environment handling the invocation. Instead, the serverless computing system can route the invocation from the poller device to any suitable environment, thereby increasing the flexibility of the serverless computing system when executing code corresponding to the invocation. The poller device can be configured to periodically save the state information to a resilient storage system (e.g., a network storage location with built-in redundancy) and resume processing based on the saved state information in the event of a failure. Thus, maintaining state information on the poller device provides an effective mechanism for implementing stateful data processing on a serverless computing system.

[0018] Although other mechanisms for implementing stateful data processing at a serverless computing system are envisioned herein, these other mechanisms are generally less satisfactory than maintaining state information at an intermediate (e.g., poller) device. For example, it can be imagined that a serverless computing system is configured to provide correlation for multiple invocations of a given code set such that each invocation is routed to the same execution environment. Further, it can be imagined that the serverless computing system enables each such environment to maintain local state information, thereby enabling stateful execution of code within the environment. However, this approach significantly reduces the flexibility with which the serverless computing system operates and requires the system to maintain an execution environment for a long time. In addition, this approach may not be well-suited to addressing problems that often arise in distributed processing systems, such as the need to provide resiliency of operations or the need to scale up or down multiple environments in response to changing operational loads. For example, to address these problems, it may be necessary for the serverless computing system to frequently save the state information of each environment, thereby significantly increasing the resource usage of the system. The system may also need to provide transmission of state information between environments during scale-up or scale-down events, thereby increasing the complexity of managing such environments. Another possible mechanism for retaining state information between invocation processing is to configure each execution environment during invocation processing to write its state information to a persistent external location, such as a network data store. Thus, subsequent executions can retrieve the state information from the persistent location to facilitate processing of subsequent invocations. However, in a distributed system, writing to an external storage location is generally considered a "heavyweight" operation because it significantly increases the computing resources used to process an invocation. For example, writing to a network location may require initiating a Transmission Control Protocol (TCP) session with the network location, a process that may require a significant amount of time and resources (in terms of the resources required to process a single invocation). In cases where the number of invocations is large (e.g., when there is a high-throughput data stream), the additional overhead required for such heavyweight operations can be substantial.

[0019] Embodiments of the present disclosure enable state information to be maintained between invocation processing without these drawbacks. For example, an intermediate device can pass the state information of an invocation at the same time the invocation is submitted to the serverless computing system and, in response to the invocation, can receive updated state information. Thus, the serverless computing system does not require additional network communication. In addition, the intermediate device can provide resiliency by periodically saving the state information, the period of which can be adjusted based on the resources available to the device and the overhead required to resume operations in the event of a failure. Specifically, because the intermediate device is able to "look at" the processing of a data item stream "over time", there is no need for the device to ensure that state information is saved after each invocation, as might be the case with a serverless computing system or an external data store.

[0020] As described in detail herein, a serverless computing system can provide network-accessible services that enable a user to submit or specify computer-executable code to be executed by virtual machine instances (or other execution environments, such as containers that provide operating system-level virtualization) on the serverless computing system. Each set of code on the serverless computing system can define a "task" or "function" and, when executed on a virtual machine instance of the serverless computing system, implement a specific function corresponding to that function. The separate implementation of a function on the serverless computing system can be referred to as an "execution" (or "function execution") of the function. The serverless computing system can further enable the user to trigger the execution of a function based on a variety of potential events, such as detecting new data at a network-based storage system, transmitting an application programming interface ("API") invocation to the serverless computing system, or transmitting a hypertext transfer protocol ("HTTP") packet in a special format to the serverless computing system. Thus, a user can utilize the serverless computing system 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, the serverless computing system can be configured to execute functions in a rapid manner (e.g., in less than 100 milliseconds [ms]), thus enabling functions to be executed "in real time" (e.g., with latency that is barely perceptible to an end user).

[0021] Because a serverless computing system can provide the ability to execute functions on demand without the need to configure the underlying apparatus on which the code is executed, the serverless computing system can provide an excellent platform for implementing streaming analytics. For example, a serverless computing system can enable a user to effectively implement streaming analytics without regard to the volume of data published to an input data stream because the scaling of computing resources for processing the data can be handled by the serverless computing system rather than being preconfigured by the user. The present disclosure can use the serverless computing system for streaming analytics by providing an effective way to maintain state information for such data analysis without the need for such state information to be maintained within the environment of the serverless computing system or persisted by such environment to other external locations.

[0022] According to embodiments of the present disclosure, in addition to or instead of providing a mechanism for maintaining state between serverless function calls, a poller apparatus as disclosed herein can also provide various scheduling and work assignment functions to enable streaming analytics.

[0023] For example, in many cases of streaming analytics, an end user may wish to analyze certain subsets of data on a stream, which can be specified relative to a window. For example, the end user may wish to analyze items in each window of 30 seconds, 1 minute, 5 minutes, 15 minutes, etc. The windows can be fixed so that they occur at set intervals. For example, the user may wish to know the average error count indicated at every 5-minute interval on the data stream. Additionally or alternatively, the windows can be sliding such that the streaming analytics logically considers all possible windows of a given length. For example, the end user may wish to know if the average error count within any possible 5-minute span exceeds a threshold. Embodiments of the present disclosure can enable a poller device to provide such windowing. More specifically, the poller device can group items within a data stream into sets of windows and pass these sets of windows to a serverless computing system for processing via a processing function, which is sometimes referred to herein as an "aggregation" function. The processing function can analyze the set of windows and return status information to the poller device. At the end of each set of windows, the poller device can pass the final status information of the windows to a window finalization function, sometimes referred to herein as a "sink" function, which can act on the final status of the set of windows, such as by reporting that status to the end user. To facilitate fixed windowing, the poller device can initialize each window based on an attribute of each item in the stream, such as a timestamp indicating the time the item was added to the stream. For example, to implement a 5-minute fixed window, the poller device can group any item on the stream with a timestamp between 00:00:00 and 00:05:00 (in HH:MM:SS format, where HH represents hours, MM represents minutes, and SS represents seconds) into the first window, have these items processed by the aggregation function to produce a status, and at the end of the time window, pass the status to the sink function for final processing. To implement a sliding window, the poller device can create new, possibly overlapping windows for each item on the stream. For example, if an item with a timestamp of 00:00:30 is added to the stream, the poller device can initialize a window from 00:00:30 to 00:05:30 (for a 5-minute window) and consider the item to be included in that window. If a second item with a timestamp of 00:00:45 is added to the stream, the poller device may consider the second item to be present in the first window and also initialize a second window from 00:00:45 to 00:05:45, with the second item also included in the second window. The poller device can then maintain the status information for each window and, similar to what was mentioned above, pass the items from each window to the aggregation function and the sink function for processing.

[0024] In some cases, the in-stream data during a given window may exceed the capacity of a single function call on a serverless computing system. For example, each call on a serverless computing system may be limited in computing resources such as memory, processing cycles, network bandwidth, etc. In some cases, each call on a serverless computing system may be limited in computing time. For example, each call may be allowed to execute for no more than a threshold time period, such as 15 minutes. To address these limitations, it may be preferable to partition a set of windows (items in the stream corresponding to a specific time window) for processing. For example, it may be preferable to limit the number of items processed by an instance of an aggregation function, such as by specifying a maximum number of data items, a maximum data size of these items, etc. In an embodiment of the present disclosure, a poller device may provide such partitioning by accepting grouping criteria that indicate when a subset of data items from a set of windows is to be submitted to an aggregation function. Illustratively, if an end user specifies that each instance of an aggregation function will process a maximum of 3 data items, the poller device may detect when a specific set of windows has three data items and submit those data items for processing. In the above manner, the poller device may maintain the state information resulting from processing 3 data items and pass that state information to the next aggregation function call for the set of windows. This batching may continue until all data items in the set of windows have been processed, at which point the target function of the window may be called. Thus, the state information of the window may be passed to the target function without requiring the aggregation function to support an infinite data input.

[0025] To better illustrate the scheduling and work assignment functions that may be implemented by a poller device as disclosed herein, Figure 1 illustrates an illustrative set of data items and the relative timing at which these data items are pushed into three data streams 10, the three data streams being represented as stream 10A, 10B, and 10N in Figure 1 Each stream includes a plurality of data items, starting from data item 1 and increasing monotonically. In Figure 1 each stream 10, the first data item (data item "1") is shown on the far right, with additional data items being added to the stream 10 from the left. Thus, time starts from a given starting point (t = 0) and increases to the left. Thus, Figure 1 the relative positions of the data items in each show the time of the data items in the stream. Illustratively, the time may be a timestamp added to the data items by the operation of a data streaming system, indicating the time of receipt of the data items, a timestamp field included in the data items published to the stream by an upstream device, etc. In Figure 1 it is assumed that each stream 10 adheres to the same analysis criteria, including criteria for calling an aggregation function and window criteria for establishing a window. Specifically, in Figure 1 it is assumed that a fixed window of a given length is established (corresponding to Figure 1), and the aggregate function supports up to three data items per call. In practice, different streams can be associated with different analysis criteria, including different window lengths, different window types (e.g., sliding windows), and different aggregate function restrictions.

[0026] The operation of the polling device causes the processing of each stream 10 to Figure 1 . Specifically, grouping the data items of a stream into "aggregates" means that these data items are passed to the call of the aggregation function on the serverless computing system together with the state information maintained for the current window (if any). Illustratively, with respect to stream 10A, the poller device detects three data items during window A, which corresponds to the maximum number of data items for each call to the aggregation function. Therefore, the poller device passes data items 1-3 to the call of the aggregation function. Since these are the first data items in the associated window, the poller device may not pass any state to the aggregation function, or may pass an empty state indicator. The poller device also detects two other data items in stream 10A - numbers 4 and 5. Although these data items do not exceed the maximum call of the aggregation function, they represent the final data items in window A. Therefore, the poller device submits data items 4 and 5 to the aggregation function together with the state information of the window (e.g., information returned as a result of processing data items 1-3). The poller device then obtains the final state information of the window. When the window is closed, the poller device then calls the target function of the window and passes the final state information of the window to it. At this point, the data analysis of the window is completed.

[0027] Similar interactions can occur with respect to other streams 10B and 10N (which can represent any number of streams). For example, with respect to stream 10B, the poller device can pass data items 1-3 to the execution of the aggregate function because the data items represent the maximum number of calls to the aggregate function each time. Since there are no additional data items in window A after data item 3 of stream 10B, the poller device calls the target function using the state information returned from the aggregate function. With respect to stream 10C, the poller device can detect the end of window A before submitting any data items for processing. Therefore, the poller device can submit all unprocessed data items (specifically, items 1 and 2) to the aggregate function for processing. After obtaining the result, the poller can pass the result to the target function as the final window state.

[0028] Similar interactions as those described above can occur for each time window. For example, with respect to stream 10A, the aggregation functions can be iteratively invoked for items 6 - 8 and 9, where the result of the second aggregation function is passed to the target function. With respect to streams 10B and 10N, the aggregation functions can be invoked for data items 4 - 6 and 3 - 5 respectively, where the result of each aggregation function is passed to the corresponding target function of the stream. Thus, as data items are published to the stream, the poller device can continue to provide analysis for each stream 10.

[0029] while Figure 1 is described with respect to different aggregation functions and target functions, and in some cases, these two functions may be combined. For example, a single function can be provided that implements both the aggregation function and the target function, and accepts a flag that differentiates these functions as input. Thus, the poller device can use a first flag value (e.g., 0) to call the function to implement the aggregation function, and a second flag value (e.g., 1) to call the function to implement the target function. As another example, a single function can be provided to implement both the aggregation function and the target function, and the single function accepts a flag indicating whether the current set of data items is the final set of the window. The function can then be configured to process the set of data items (if any) and implement the target function for the window. Thus, the separate descriptions of the aggregation function and the target function should not be taken to imply that these functions must be distinct.

[0030] Those skilled in the art will appreciate, given the present disclosure, that the embodiments disclosed herein improve the ability of computing systems, such as serverless computing systems, to perform streaming data analysis. More specifically, the embodiments of the present disclosure enable state information to be effectively maintained between code executions on a serverless computing system, without the need to maintain such state information in the execution environment of the system. The embodiments of the present disclosure further provide a mechanism for passing data items to serverless code execution by using a poller device that provides scheduling and work allocation for serverless code execution based on data items within the data stream. Additionally, the presently disclosed embodiments address technical problems inherent within computing systems; specifically, the need to maintain state information when performing data analysis, the difficulty of maintaining such information without increasing the computing resources used to process the data stream or reducing the flexibility in which such processing occurs, and the need to orchestrate a serverless computing system to perform streaming analysis at different time windows. These technical problems are solved by the various technical solutions described herein, including using a poller device to orchestrate serverless computing execution to perform streaming analysis while maintaining state information to facilitate such analysis. Thus, the present disclosure generally represents an improvement over existing systems and computing systems.

[0031] Figure 2FIG. 0 is a block diagram of an illustrative operating environment 100 of a serverless code execution system 110, where a poller fleet 130 can provide poller devices 132 that facilitate streaming analysis of data items of a message stream 172 published to a stream data system 170 on behalf of client devices 102.

[0032] By way of illustration, various exemplary client devices 102, including desktop computers, laptop computers, and mobile phones, are shown as communicating with a serverless code execution system 110. Generally, client device 102 can be any computing device, such as a desktop computer, laptop computer, or tablet computer, personal computer, wearable computer, server, personal digital assistant (PDA), hybrid PDA / mobile phone, mobile phone, e-book reader, set-top box, voice command device, camera, digital media player, etc. The serverless code execution system 110 can provide one or more user interfaces, command line interfaces (CLIs), application programming interfaces (APIs), and / or other programming interfaces for the following operations: generating and uploading user-executable source code (e.g., as part of a disk image); invoking user-provided source code (e.g., submitting a request to execute source code on the serverless code execution system 110); scheduling event-based or timed code execution; tracking user-provided source code; and / or viewing other logging or monitoring information related to their requests and / or source code. Although one or more embodiments may be described herein as using a user interface, it should be understood that additionally or alternatively, such embodiments may use any CLI, API, or other programming interface.

[0033] The illustrative environment 100 further includes one or more auxiliary services 106 that can interact with the serverless code execution environment 110 to implement the desired functionality on behalf of the user. The auxiliary services 106 can correspond to network-connected computing devices such as servers that generate data accessible by the serverless code execution environment 110 or otherwise communicate with the serverless code execution environment 110. For example, the auxiliary services 106 can include web services (e.g., associated with the user computing device 102, associated with the serverless code execution system 110, or associated with a third party), databases, Really Simple Syndication (“RSS”) readers, social networking sites, or any other source of network-accessible services or data sources. In some instances, the auxiliary services 106 can be invoked through code execution on the serverless code execution system 110, such as by an API call to the auxiliary service 106. In some instances, the auxiliary services 106 can be associated with the serverless code execution system 110, e.g., providing billing or logging services to the serverless code execution system 110. In some instances, the auxiliary services 106 actively transmit information to the serverless code execution system 110, such as API call or other task trigger information. In other instances, the auxiliary services 106 can be passive, such that data is made available for access by the serverless code execution system 110. For example, components of the serverless code execution system 110 can periodically poll such passive data sources and trigger the execution of code within the serverless code execution system 110 based on the provided data. Although Figure 2 depicted as being different from the user computing device 102 and the serverless code execution system 110 in

[0034] The illustrative environment 100 also includes a stream data system 170. As described above, the stream data processing system can provide an upstream device with the ability to place data onto a message stream 172, such as by “publishing” a “message” onto the stream 172, which can be specified based on a particular “topic”. Although Figure 1A single stream 172 is shown, but system 170 can represent multiple streams provided by multiple parties. System 170 can make the messages within stream 172 available to downstream devices, typically in a “first in, first out” (“FIFO”) or near-FIFO order. In some cases, the stream data system 170 “pushes” messages to downstream devices. In other cases, downstream devices “pull” messages from the message stream 172 on request. Generally, the stream data system 170 is configured to provide resilience such that data successfully published to the stream is unlikely to be lost due to a device failure of the stream data system 170. For example, system 170 can replicate messages placed on stream 172 to multiple computing devices (e.g., physical computing devices or virtual devices implemented on a physical host) that implement the stream. Additionally, the stream data system 170 can be configured to provide parallelization of the devices that maintain message stream 172. For example, a user configuring a message stream can specify a partition key for the stream to divide the stream into multiple sub-streams, each sub-stream being processed by one or more parallel devices. The sub-streams are shown as message shards 174A - 174N in Figure 1 which. Each message shard 174 can generally represent one or more computing devices that are configured to obtain and make available a subset of the messages on the message stream, selected by system 170 based on the partition key and the volume of messages on stream 170 (e.g., such that additional shards are created or redundant shards are destroyed based on the capacity of the shard 174 to service messages on stream 172). In some cases, stream 172 may contain only a single shard. Examples of stream data processing systems known in the art include AMAZON TM KINESIS TM web services and APACHE TM KAFKA TM systems.

[0035] The client device 102, the auxiliary service 106, the streaming data system 170, and the serverless code execution system 110 may communicate via the 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 over-the-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 linked networks that may be operated by various different parties, such as the Internet. In some embodiments, the network 104 may be a private or semi-private network, such as a corporate 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 the Internet or any of the other aforementioned types of networks. For example, the protocols used by the network 104 may include the Hypertext Transfer Protocol (HTTP), HTTP Secure (HTTPS), Message Queuing Telemetry Transport (MQTT), Constrained Application Protocol (CoAP), and the like. The protocols and components for communicating via the Internet or any of the other aforementioned types of communication networks are well known to those of ordinary skill in the art and are not described in more detail herein.

[0036] The serverless code execution system 110 and the streaming data system 170 are depicted as operating in a distributed computing environment that includes a number of computer systems interconnected using one or more computer networks (not shown in Figure 1 ). The serverless code execution system 110 and / or the streaming data system 170 may also operate in a computing environment having fewer or more devices than the devices shown in Figure 1 . Accordingly, the depiction of the serverless code execution system 110 and the streaming data system 170 in Figure 1 should be considered illustrative and not limiting of the present disclosure. For example, the serverless code execution system 110 and the streaming data system 170 or their 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. Figure 1

[0037] ​Additionally, the serverless code execution system 110 and the streaming data system 170 may be implemented directly in hardware or software executed by a hardware device, and may (for example) include one or more physical or virtual servers implemented on physical computer hardware configured to execute computer-executable instructions to perform the various features described herein. The one or more servers may be geographically dispersed or co-located, for example, in one or more data centers. In some instances, the one or more servers may operate as part of a system of rapidly provisioned and released computing resources, commonly referred to as a “cloud computing environment”.

[0038] In Figure 1 the example of, the serverless code execution system 110 and the streaming data system 170 are shown connected to the network 104. In some implementations, any of the components within the serverless code execution system 110 and the streaming data system 170 may communicate with other components of the serverless code execution system 110 and the streaming data system 170 via the network 104. In other implementations, another network, such as Figure 1 a private network not shown in, may enable communication between components within each of the serverless code execution system 110 and the streaming data system 170 or between those systems.

[0039] In Figure 2In [the system], a user can interact with a serverless code execution system 110 through a client computing device 102 to provide source code and establish rules or logic that define when and how such code should be executed on the serverless code execution system 110, thereby establishing a "task" or "function". For example, a user may wish 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 offers infrastructure as a service; configure the virtual machine instance to meet the user's needs; and use the configured virtual machine instance to run the code. To avoid the complexity of this process, the user can alternatively provide the code to the serverless code execution system 110 and request that the serverless code execution system 110 use one or more execution environments managed by the system 110 to execute the code. The serverless code execution system 110 can handle the acquisition and configuration of computing capacity (e.g., containers, instances, etc., described in more detail below) based on the code execution request and use the computing capacity to execute the code. The serverless code execution system 110 can automatically scale up and down based on the volume of code execution requests, thereby relieving the user of having to worry about overutilization (e.g., obtaining too few computing resources and suffering performance issues) or underutilization (e.g., obtaining more computing resources than are needed to run the code and thus paying too much). According to an embodiment of the present disclosure, a function established by a user can correspond to executable code for performing a streaming analysis of data items on a data stream 172, including an aggregation function for generating status information of data items within a time window and a target function for processing the results corresponding to the time window.

[0040] To enable interaction with the serverless code execution system 110, the system 110 includes a plurality of front-ends 120 that implement the interaction with the serverless code execution system 110. In an illustrative embodiment, the front-ends 120 serve as the "front door" to other services provided by the serverless code execution system 110, enabling a user (via the user computing device 102) to provide computer-executable source code, request execution of the computer-executable source code, and view the results of the computer-executable source code. The front-ends 120 include a variety of components for implementing the interaction between the serverless code execution 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 transfer a user-specified code and an associated data set to the serverless code execution system 110 (e.g., in the form of a disk image); and subsequently request execution of the code. In one embodiment, the request interface communicates with external computing devices (e.g., the user computing device 102, auxiliary service 106, etc.) via a graphical user interface (GUI), a command-line interface (CLI), or an application programming interface (API). The front-end 120 processes the request and ensures that the request is properly authorized. For example, the front-end 120 may determine whether the user associated with the request is authorized to access the source code specified in the request.

[0041] References to source code used herein can refer to any program code written in a particular programming language (e.g., programs, routines, subroutines, threads, etc.). In this disclosure, the terms "source code", "user code", and "program code" may be used interchangeably. Source code compiled for execution on a particular device is generally referred to herein as "machine code". Both "source code" and "machine code" are representations of the same instructions and may be collectively referred to as "code". For example, such code may be executed in conjunction with a particular web application or mobile application developed by a user to implement a particular function. As described above, an individual collection of code (e.g., to implement a particular function) is referred to herein as a "task" or "function", and a particular execution of the code is referred to as "task execution", "function execution", "code execution", or simply "execution". The source code of a task may be written in, by way of non-limiting example, JavaScript (e.g., node.js), Java, Python, and / or Ruby (and / or another programming language). A task may be "triggered" in a variety of ways for execution on the serverless code execution system 110. In one embodiment, a user or other computing device may transmit a request to execute a task, which request is generally referred to as an "invocation" of the task (e.g., "task invocation", "function invocation", etc.). Such invocations may include an identifier of the task to be executed and one or more arguments to be used for task execution. The request interface of the front end 120 may receive an invocation from a user to execute a task as a Hypertext Transfer Protocol Secure (HTTPS) request. Moreover, any information included in the HTTPS request (e.g., headers and parameters) may also be processed and utilized when the task is executed. As discussed above, messages containing task invocations may be transmitted to the request interface using any other protocol, including, for example, HTTP, MQTT, and CoAP.

[0042] Before invoking function execution, an end user may submit (e.g., to the front end 120) the function code and associated data to be used for function execution. In one embodiment, the code is provided in the form of a disk image containing the code and other data that the code may use during execution. Illustratively, the creation of a function may cause the front end 120 to create metadata for the function, which metadata defines, for example, the user who created the function, the disk image used to facilitate function execution, the trigger conditions for the function, etc. In one embodiment, functions may be versioned, where function metadata identifies available versions and at least some other metadata for the function may vary across versions. For example, different versions may be associated with different disk images. Function data and metadata are illustratively stored in the function data store 160. The function data store 160 corresponds to any persistent data store. In one embodiment, the function data store 160 is implemented as a logical store on a cloud storage service, such as an object storage system. An example of such an object storage system is AMAZONTM of SIMPLE STORAGE SERVICE TM (or “S3 TM ”).

[0043] According to an embodiment of the present disclosure, the code submitted by a user may correspond to functions for performing streaming analysis, such as aggregation function 162 and target function 164. These functions may be embodied in computer-executable code submitted to execution system 110. In one embodiment, aggregation function 162 performs data analysis, accepts data items in a data stream and state information of the current window (if any), and generates new state information for the window. The specific function of the aggregation function may vary depending on the data to be processed and the desired result. However, generally speaking, the aggregation function may aggregate data items within a window and provide an aggregation result. For example, the aggregation function may count instances of field values within a data item, provide an average of numeric field values, provide another statistical measure of matching field values, etc. According to an embodiment of the present disclosure, the aggregation function maintains a state within a window, such as a fixed window or a sliding window. The final execution of the aggregation function for a given window provides the final state of that window, which may be passed to target function 164, representing executable code to process that final state. For example, the target function may evaluate the state to determine a result (e.g., whether an alert should or should not be sent), publish the state to a network target, etc. Thus, target function 164 enables the streaming analysis result provided for a given window. Although shown as different functions, aggregation function 162 and target function 164 may be combined into a single function in some cases. Both functions 162 and 164 may be stored in function data store 160.

[0044] After a user has created a function on the serverless code execution system 110, the system 110 can accept an invocation to execute the function. To execute an invocation of a function, the front end 120 can include an execution queue that can maintain a record of the requested task execution. Illustratively, the number of functions that the serverless code execution system 110 can execute simultaneously is limited, and thus, new function executions initiated at the serverless code execution system 110 (e.g., via an API invocation, via an invocation from a function being executed or executing) can be placed on the execution queue and processed, for example, in a first-in, first-out order. In some embodiments, the serverless code execution system 110 can include multiple execution queues, such as individual execution queues for each user account. For example, a user of the serverless code execution system 110 may desire to limit the rate of function execution on the serverless code execution system 110 (e.g., for cost reasons). Thus, the serverless code execution system 110 can utilize an account-specific execution queue to throttle the rate of simultaneous function execution by a particular user account. In some instances, the serverless code execution system 110 can prioritize function execution such that function execution for a particular account or a specified priority bypasses or is prioritized within the execution queue. In other cases, the serverless code execution system 110 can execute the function immediately or substantially immediately after receiving an invocation of the function and thus, can omit the execution queue.

[0045] In addition to functions executed based on explicit user invocations and data from the auxiliary service 106, the serverless code execution system 110 can, in some cases, operate to independently trigger function execution. For example, the serverless code execution system 110 can operate (based on an instruction from the user) to trigger the execution of a function at each of a number of specified time intervals (e.g., every 10 minutes).

[0046] The front end 120 can also include an output interface that is configured to output information about the execution of functions on the serverless code execution system 110. Illustratively, the output interface can transmit data about function execution (e.g., the result of the function, an error associated with the function execution, or details of the function 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 can include, for example, a billing or logging service. The output interface can further enable the transmission of data such as service invocations to the auxiliary service 106. For example, the output interface can be utilized during function execution to transmit an API request to the external service 106 (e.g., to store data generated during the function execution).

[0047] In Figure 1Code execution triggered on the serverless code execution system 110 is executed by an execution environment hosted by a set of workers 181 within the worker cluster 180. Each worker 181 is illustratively a host device configured to host multiple execution environments. In Figure 1 the case of virtual machine instances 183A - 183N. The execution environment may alternatively include software containers, sometimes referred to as "OS-level virtualization", which is another virtualization technology known in the art. Thus, in instances where a VM instance 183 is referred to herein, it should be understood (unless otherwise indicated) that a container may substitute for such an instance 183.

[0048] As used herein, the term "virtual machine instance" is intended to refer to the execution of software or other executable code that emulates hardware to provide an environment or platform ("execution environment") on which software can execute. Since they emulate hardware, these virtual machine instances are sometimes referred to as "system virtual machines". Virtual machine instances are typically executed by a hardware device, which may be different from the physical hardware emulated by the virtual machine instance. For example, a virtual machine may emulate a first type of processor and memory while executing on a second type of processor and memory. Thus, virtual machines can be utilized to execute software intended for a first execution environment (e.g., a first operating system) on a physical device that is executing a second execution environment (e.g., a second operating system). In some instances, the hardware emulated by a virtual machine instance may be the same as or similar to the hardware of the underlying device. For example, a device having a first type of processor may implement multiple virtual machine instances, each virtual machine instance emulating an instance of the first type of processor. Thus, virtual machine instances can be used to divide a device into a number of logical sub-devices (each logical sub-device being referred to as a "virtual machine instance"). While virtual machine instances typically provide a level of abstraction from the hardware of the underlying physical device, such abstraction is not required. For example, assume a device implements multiple virtual machine instances, each of which emulates the same hardware as the hardware provided by the device. In such a scenario, each virtual machine instance can allow a software application to execute code on the underlying hardware without translation while maintaining logical separation between software applications running on other virtual machine instances. This process, commonly referred to as "native execution", can be used to increase the speed or performance of the virtual machine instance. Other techniques that allow direct utilization of the underlying hardware, such as hardware passthrough techniques, can also be used.

[0049] As Figure 1As shown, each worker 181 can host multiple instances 183. Each instance 183 can be isolated from other instances 183, thus ensuring the security of code execution on the serverless code execution system 110. For example, each instance 183 can be demarcated by a virtualization boundary because the instance 183 is a virtual machine hosted by the worker 181. In addition, each instance 183 can exist within a partitioned user space on the worker 181, which logically divides the resources of the worker 181 among the instances 183. For example, each user space may represent a "chroot" jail, which is a known isolation technique for the LINUX TM operating system.

[0050] To facilitate the rapid execution of code, each worker 181 can be configured to maintain a set of instances 183 in a "warm" state, at least partially configured to initiate the execution of code. For example, instances can be created on the worker and configured to have access to computing resources (CPU, RAM, drive storage, etc.). In some cases, it may be impractical or impossible to keep the instances 183 in a fully warm state for all possible code executions because the execution may be associated with a wide variety of at least partially different data sets (e.g., disk images and / or snapshots). Thus, for a given set of tasks, the instances 183 can be maintained in "maximum commonality", such as being provided with a set of computing resources common to those tasks, being configured to accept the type of operating system used by those tasks, and so on.

[0051] Upon receiving an instruction to provide an instance 183 to support task execution, the worker 181 can adjust the configuration of the instance 183 to support that execution. Specifically, the worker 181 can provide the instance 183 with access to a disk image or snapshot corresponding to the task. In some cases, the worker 181 can retrieve the disk image of the task and store the complete image locally. In other cases, the worker 181 can provide the instance 183 with full local access to the disk image or snapshot while "lazily" retrieving portions of the image or snapshot in response to requests to read those portions. Techniques for providing lazy retrieval of image portions are discussed in U.S. Patent Application No. 17 / 105,250, filed on November 25, 2020, and titled "LOW LATENCY ACCESS TO DATA SETS USING SHARED DATA SET PORTIONS" ("the '250 application"), the entire content of which is incorporated herein by reference.

[0052] In addition, system 110 includes multiple components for facilitating the distribution of invocations from front end 120 to a particular VM instance 183 for function execution. For example, the serverless code execution system 110 includes one or more worker managers 140 configured to manage execution environments (e.g., virtual machine instances) hosted by workers 181 in worker fleet 180. Worker managers 140 (each of which is illustratively implemented as a physical device or a physically virtual device) illustratively "rent" a particular VM instance 183 within fleet 180 to obtain operational control to, for example, direct the virtual machine instance 183 to execute code for a function. Thus, upon receiving an invocation to execute a function, front end 120 can distribute the invocation to worker manager 140, which can identify the currently rented VM instance 183 in which the function is implemented and cause instance 183 to implement the function.

[0053] In the case where worker manager 140 does not currently rent a VM instance 183 corresponding to the invoked function, worker manager 140 can contact placement service 160 to request renting an additional instance 183, which is illustratively configured to grant worker manager 140 a rental of respective VM instances 183. Illustratively, placement service 160 can maintain status information of VM instances 183 across fleet 180 and information indicating which manager 140 has rented a given instance 183. When worker manager 140 requests to rent an additional instance 183, placement service 160 can identify a suitable instance 183 (e.g., pre-warmed with software and / or data required to support execution of the function invocation) and grant manager 140 a rental of that instance 183. In the case where such an instance 183 does not exist, placement service 160 can instruct worker 181 to create such an instance 183 (e.g., by creating an instance 183 or identifying an existing unused instance 183, providing the instance 183 with access to a set of data required to support execution, etc.), and subsequently grant worker manager 140 a rental of that instance 183 to facilitate execution.

[0054] To facilitate interaction with external data sources such as stream data system 170 or auxiliary service 106, system 110 includes polling fleet 130 for polling external data sources for data. Illustratively, polling fleet 130 can include one or more computing devices ( Figure 1shown as poller devices 132A - 132N), the computing device is configured to periodically transmit requests to the streaming data system 170 to retrieve any new available data (e.g., social network "posts", news articles, documents, records, etc.), and determine whether the data corresponds to user - established criteria that trigger the execution of a function on the serverless code execution system 110. Illustratively, the execution criteria for a function can include, but are not limited to, whether new data is available at the auxiliary service 106 or the streaming data system 170, the type or content of the data, or timing information corresponding to the data. In some cases, the auxiliary service 106 or the streaming data system 170 can be used to notify the front - end 120 of the availability of new data, and thus, for such services, the polling fleet 130 may be unnecessary.

[0055] According to an embodiment of the present disclosure, based on the number of message shards 174 within the message stream 172, the polling fleet 130 can be configured to include a dynamic number of poller devices 132A - 132N (e.g., implemented as virtual machine instances on an underlying computing system). For example, as Figure 1 shown by the dashed lines, the message shard 174A can correspond to the poller device 132A, the message shard 174B can correspond to the poller device 132B, and so on. Thus, as the number of message shards 174 changes (e.g., due to the volume of the message stream), the number of poller devices 132 can also change. In this way, the polling fleet 130 can communicate with the streaming data system 170, and the system 170 can notify the polling fleet 130 of changes to the message shards 174. In such a configuration, each poller device 132A can be configured to poll the message shard 174 to retrieve messages in the sub - stream corresponding to the message shard. Messages can be retrieved individually or in batches (e.g., batches of 10 messages, 50 messages, 100 messages, 500 messages, etc.). Thereafter, the poller device 132 can call the aggregation function 162 or the target function 164 for the message as needed. In some cases, the calls from each poller device 132 to the corresponding function execution can be synchronized such that the poller device 132 waits for confirmation of successful execution before making the next call.

[0056] Although some functions are described herein generally with reference to separate components of the serverless code execution system 110 or the streaming data system 170, other components or combinations of components can additionally or alternatively implement such functions. For example, although the poller device 132A can be used to poll the message shards 174 of messages, the message shards 174 can be additionally or alternatively configured to notify the serverless code execution system 110 (e.g., the front - end) of new messages on the shard 174.

[0057] Figure 3Depicts the general architecture of the poller device 132. Figure 3 The general architecture of the poller device 132 depicted in Figure 3 includes an arrangement of computer hardware and software modules that can be used to implement aspects of the present disclosure. The hardware modules can be implemented using physical electronic devices, as will be discussed in more detail below. The poller device 132 can include more (or fewer) elements than those Figure 3 shown in Figure 3 . However, in order to provide a disclosure of what can be achieved, it is not necessary to show all of these generally conventional elements. Additionally, Figure 3 the general architecture shown in Figure 3 can be used to implement one or more of the other components Figure 1 shown in Figure 1 . As shown, the poller device 132 includes a processing unit 190, a network interface 192, a computer-readable medium drive 194, and an input / output device interface 196, all of which can communicate with each other via a communication bus. The network interface 192 can provide connectivity to one or more networks or computing systems. The processing unit 190 can thus receive information and instructions from other computing systems or services via the network 104. The processing unit 190 can also communicate with the memory 180 and further provide output information to an optional display (not shown) via the input / output device interface 196. The input / output device interface 196 can also accept input from an optional input device (not shown).

[0058] The memory 180 can contain computer program instructions (grouped into modules in some embodiments) that the processing unit 190 executes to implement one or more aspects of the present disclosure. The memory 180 generally includes random access memory (RAM), read-only memory (ROM), and / or other persistent, auxiliary, or non-transitory computer-readable media. The memory 180 can store an operating system 184 that provides computer program instructions used by the processing unit 190 in the general management and operation of the worker manager 140. The memory 180 can further include computer program instructions and other information for implementing aspects of the present disclosure. For example, in one embodiment, the memory 180 includes a user interface unit 182 that generates a user interface (and / or instructions for the user interface) for display on the computing device, for example, via a navigation and / or browsing interface such as a browser or an application installed on the computing device. Additionally, the memory 180 can 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.

[0059] In addition to and / or in conjunction with the user interface unit 182, the memory 180 can include a polling unit 186, a data analysis unit 188, and a serverless interface unit 189. In one embodiment, the polling unit 186, the data analysis unit 188, and the serverless interface unit 189 implement various aspects of the present disclosure, either individually or jointly. For example, the polling unit 186 can represent executable code to poll the message flow 172 to identify and obtain data items from the flow 172. The data analysis unit 188 can represent executable code to analyze those data items to determine whether criteria for invoking an aggregation function or a target function associated with the flow are met. The serverless interface unit 189 can represent executable code to invoke such an aggregation function or a target function and maintain state information between such invocations.

[0060] Although the polling unit 186, the data analysis unit 188, and the serverless interface unit 189 are shown in Figure 3 as part of the poller device 132, in other embodiments, all or part of the polling unit 186, the data analysis unit 188, and the serverless interface unit 189 can be implemented by the serverless code execution system 110 and / or other components of another computing device. For example, in certain embodiments of the present disclosure, another computing device communicating with the serverless code execution system 110 can include several modules or components that operate similarly to the modules and components shown as part of the poller device 132.

[0061] Referring to Figure 4 , an illustrative interaction for initiating a streaming analysis of data items in the message flow 172 using the Figure 2 serverless code execution system 110 is depicted. Specifically, Figure 4 the interaction illustrates those interactions that the system 110 can take to receive and respond to a user request to perform a streaming analysis according to aggregation functions and target functions provided by the user.

[0062] Figure 4 The interaction of Figure 3In the illustrative interaction, the aggregation function and the target function are specified as serverless functions within the serverless code execution system 110, which may have been previously created by the user device 102 as part of configuring the stream analysis or may be created by the serverless code execution system 110 (e.g., as part of configuring these functions for implementing the stream analysis, the user can submit code for the aggregation function and the target function). In other embodiments, the user may specify other aggregation functions and target functions, such as functions available to the serverless code execution system 110 or other users. In addition to the specification of the aggregation function and the target function, Figure 4 the illustrative configuration generally includes a specification of the data stream (e.g., Figure 1 the message stream 172), including the data items (or "messages") to be processed by the aggregation function and the target function, and the criteria for invoking the aggregation function and the target function. Such criteria may include windowing criteria, which specify the window (e.g., sliding and / or fixed window) over which messages should be analyzed, including, for example, the window duration or the criteria for establishing such a duration. The target function may illustratively be executed at the end of each such window, thereby using the state information associated with the data items that occurred within the processing window. The criteria for invoking the aggregation function and the target function may also include aggregation criteria, which specify when to run the aggregation function to process the data items within the window. For example, the aggregation criteria may include the maximum number of items or the data size to be processed by a single invocation of the aggregation function. As described below, the criteria for invoking the aggregation function and the target function may then be applied by the poller devices 132 within the poller fleet 132 to perform a stream analysis of the message stream 172 by invoking the aggregation function and the target function.

[0063] Accordingly, the front end 120 transmits the provided aggregation function and target function (if required) to the task data store 160 at (2) for later retrieval and execution. In addition, at (3), the front end 120 instructs the poller fleet to initialize the stream analysis specified by the client device 102. The front end 120 may illustratively pass to the poller fleet an identification of the message stream 172 containing the data to be analyzed, an identification of the aggregation function and the target function, and the criteria for invoking the aggregation function and the target function. The poller fleet 130 then initializes the poller devices 132 at (4) for the stream analysis. Illustratively, the poller fleet 130 may initialize one or more poller devices for each shard 174 of the message stream 172.

[0064] Referring to Figure 5 , an illustrative interaction for performing a stream analysis of messages within the message stream 172 by invoking an aggregation function on the serverless code execution system 110 is shown. For example, Figure 5 the interaction may respond to Figure 4occurs due to the interaction as described above.

[0065] Figure 5 The interaction starts at (1), where one or more messages are published to message stream 172 on stream data system 170. The messages can be published by multiple data sources, such as client device 102, auxiliary service 106, or other network devices. For example, messages can be published during the operation of a computing system to record data about the operation of the computing system to stream 172. The messages can contain any of a variety of types of data, which correspond to data analyzed by performing aggregation functions and target functions.

[0066] At (2), polling fleet 130 (e.g., using polling device 132) retrieves messages from stream 172. In one implementation, the retrieval utilizes a "pull" mechanism, whereby fleet 130 periodically (e.g., every second, 10 seconds, 30 seconds, etc.) pulls new messages from stream 172. In another implementation, the retrieval uses a "push" mechanism, whereby stream 172 notifies fleet 130 of new messages.

[0067] At (3), polling fleet 130 assigns the retrieved messages to one or more windows according to windowing criteria. For example, the timestamp associated with each message can be used to assign the message to a corresponding window. In the case of fixed non-overlapping windows, each message can be assigned to a single window. In the case of sliding or overlapping windows, each message can be assigned to multiple windows. For example, each message can trigger the creation of a new sliding window of a given duration.

[0068] Thereafter, at (4), polling fleet 130 determines that the retrieved messages for a given window meet the criteria for invoking an aggregation function for those messages. Such criteria can include, for example, the number of messages or the total data size of the messages. Such criteria can further include the closing of the window that includes the messages, which can be determined, for example, based on the presence of messages in the stream having timestamps after the closing time of the window.

[0069] Accordingly, at (5), the poller fleet 130 invokes an aggregation function to process messages. In one embodiment, the invocation passes the messages to the aggregation function execution 402. In another embodiment, the invocation identifies the messages on the message stream 172 such that the execution 402 can obtain the messages during execution. In the invocation, the poller fleet 130 also passes the status information of the window to which the messages are assigned to the aggregation function. Illustratively, the poller fleet 130 may pass initial status information during the first invocation of the aggregation function for a given window, which may be empty. During subsequent invocations, the aggregation function may be passed updated status information of the window, as described below. The invocation may illustratively be a synchronous execution such that the operations of the fleet 130 or a particular poller device 132 are paused and wait for the execution to complete before proceeding with additional operations.

[0070] At (6), the serverless code execution system 110 initiates the aggregation function execution 402. The execution 402 illustratively represents the execution of code that analyzes the messages corresponding to the invocation using the incoming status information (if any). For example, the execution 402 may determine the count, average, minimum, or maximum of one or more field values in each message for a given window. Those skilled in the art will understand that these functions are provided for illustration only, and user-defined aggregation functions may implement any number of functions.

[0071] At (7), as a result of processing the messages corresponding to the invocation, the aggregation function execution 402 returns a result to the poller fleet 130 as the status information for the corresponding window. For example, the execution 402 may pass the count, average, minimum, or maximum identified during the message processing of the window to the poller fleet 130. At (8), the fleet updates the status information of the corresponding window with the returned result. Accordingly, the status information can be used to invoke future invocations of the aggregation function such that such an execution is stateful and does not require maintaining such a state in the execution environment of the aggregation function execution 402.

[0072] Although a single interaction sequence is shown in Figure 5 , those skilled in the art will understand that these interactions may occur multiple times, and some of the interactions may occur simultaneously. For example, messages may be published to the stream independently of the operation of the system 110. Similarly, messages may be retrieved from the stream independently of Figure 5 the remaining interactions and, for example, cached at the poller fleet 130 for analysis according to the stream analysis criteria. In addition, the interactions (3)-(8) may occur repeatedly with respect to the messages in a given window such that multiple aggregation function executions 402 occur within that window. Similarly, these interactions may be repeated for each message window. Although Figure 5The interactions are generally described with reference to the poller fleet 130, but these interactions can be repeated among the poller devices 132. For example, each device 132 can be configured to perform interactions (3)-(8) for different shards 174 of the stream 172. In some embodiments, multiple devices 132 can be configured to perform interactions (3)-(8) for a single shard 174. For example, the windowing criteria can include partitioning criteria, such as the attributes of messages within the shard 174 to be used as a partitioning key for partitioning the messages (e.g., according to a consistent hashing algorithm), as well as windowing and aggregation criteria. Each poller device 132 among the multiple devices 132 can then apply the windowing and aggregation criteria to their respective message portions to implement the above interactions.

[0073] Reference Figure 6 , illustrates illustrative interactions for performing a streaming analysis of messages within the message stream 172 by invoking a target function on the serverless code execution system 110. The interactions can illustratively occur Figure 5 after or simultaneously with the interactions of Figure 6 As shown, the interaction begins at (1), where a message is published to the stream 172, and continues at (2), where the poller fleet 130 retrieves one or more messages from the stream. These interactions are substantially similar to Figure 5 the interactions (1) and (2) of Figure 5 and Figure 6 and will not be described in detail herein. In some cases, Figure 5 and Figure 6 the interactions (1) and (2) of

[0074] After retrieving messages, at (3), the poller fleet 130 detects that the window has closed. As described above, each window can be associated with a given start and end period. Thus, detecting that the window has closed can correspond to detecting that the end period of the window has occurred. In one embodiment, detecting that the window has closed corresponds to detecting that a message in the stream has a timestamp after the window end period. For example, this can indicate that all messages within the window have been published to the stream 172 and are thus available to the poller fleet 130. In the case where the stream 172 does not guarantee ordering (e.g., where a message with an earlier timestamp is not guaranteed to exist in the stream before a message with a later timestamp), the poller fleet 130 can treat unordered messages as part of a later window. For example, any message with a timestamp corresponding to the closed window can be treated by the fleet 130 as part of the earliest open window. In other embodiments, the poller fleet 130 can be configured to attempt to place unordered messages into the correct window. For example, the poller fleet 130 can be configured to treat unordered messages as included within their appropriate window (based on the timestamp on the message), as long as the objective function for that window has not been called. The poller fleet 130 can in some cases be configured to delay the calling of the objective function for each window to account for unordered messages. For example, upon detecting that the window has closed, the poller fleet 130 can delay the calling of the objective function for a given period (e.g., 1 second, 10 seconds, 30 seconds, etc.) such that unordered messages obtained during that period can be processed as part of the closed window.

[0075] Thereafter, at (4), the poller fleet 130 calls the objective function with the final state of the window, where the final state corresponds to the state returned by executing an aggregation function after processing the messages corresponding to the window. In one embodiment, the poller fleet 130 is configured to confirm that all messages within the window have been processed by the execution of the aggregation function before calling the objective function. If there are messages that have not been processed, the poller fleet 130 can call the aggregation function (e.g., in the manner described with respect to Figure 6 to obtain the final state of the window at the time the window closes. The poller fleet 130 can then call the objective function and pass the final window state to the function. In response to the call, the serverless code execution system 110 initiates the objective function execution 602, which executes at (5) to process the final window state. For example, the objective function execution 602 can evaluate the state to determine what action (if any) to take and take the relevant action. Relevant actions may include, for example, recording the final state, sending an alert if the final state matches a given criterion, etc. Since the evaluation and relevant actions are defined in the user-defined objective function, these can include a wide variety of functions.

[0076] At (6), the objective function 602 returns an indication of success to the poller fleet. The poller fleet 130 then marks the window as processed at (7). Thus, since the aggregation function and the objective function have been called for each message within the window, the requested streaming analysis has been applied to the window. Based on the above interactions, the streaming analysis can be performed without deploying specific resources for performing the streaming analysis, enabling the end user to enjoy the benefits associated with serverless computing during such analysis. Additionally, such an analysis can run statelessly without the need to maintain such a state in the execution environment of the serverless code execution system 110, thus not inhibiting the flexibility of the system 110 when executing user-defined code.

[0077] Various modifications can be made to the Figure 5 and Figure 6 interactions. For example, while Figure 5 and Figure 6 discussed separate aggregation and objective functions, as described above, these functions may represent a single function in some cases. Thus, Figure 5 and Figure 6 calls can refer to calling the same function with, for example, a flag or other input specifying which function (aggregation or objective) to call. In some cases, a single call can be used to call both the aggregation function and the objective function. For example, when a window is detected to be closed, the poller fleet can call a single function to process the remaining (unprocessed) messages of the window and use the result of such processing as the final state for performing the objective processing. Thus, Figure 5 the interaction (5) of Figure 6 and Figure 5 the interaction (4) can be combined into a single call, and

[0078] the interactions (7) and (8) of Figure 5 and Figure 6 can be omitted.

[0079] Furthermore, although not shown in Figure 5 and Figure 6Interactions typically consider the processing of a single continuous set of messages (e.g., within a given stream 172 or shard 174), but in some cases, streams and / or shards can be split or merged. For example, the stream data system 170 can be configured to split or merge streams according to the requests of the users who own such streams, or split or merge shards according to the message volume on those shards. In some embodiments, the poller fleet 130 can be configured to handle such splits or merges. For example, when detecting a split stream or shard, the poller fleet 130 can apply the streaming analysis criteria of the unsplit stream or shard to the two resulting streams or shards. The user who configures the streaming analysis can specify which set of the two sets of criteria (if different) should be applied to the merged stream or shard, so that the poller fleet 130 applies the specified criteria to the merged stream or shard. In one embodiment, the poller fleet 130 treats the split or merge as a window boundary, so that no state information is maintained between the split or merge. In another embodiment, the poller fleet 130 can maintain a window that spans the split / merge boundary and process the state information accordingly. For example, in the case of a split, the fleet 130 can copy the state information of the unsplit shard or stream to the two resulting shards or streams. In such an example, the aggregation and / or target function can include executable code to determine the relevant state information of the corresponding shard or stream. In the case of a merge, the fleet 130 can combine or concatenate the state information of the merged stream or shard. Various additional modifications can be made to the Figure 5 and Figure 6 interactions.

[0080] Referring Figure 7 to, an illustrative routine 700 for performing streaming analysis using a serverless code execution system will be described. The routine 700 can be implemented, for example, on the poller device 132 of the poller fleet 130.

[0081] The routine 700 begins at block 702, where the poller device 132 obtains streaming analysis parameters, including the specification of the aggregation function and the target function to be used for performing the streaming analysis. The streaming analysis parameters also illustratively include windowing criteria, which specify the criteria for identifying the window on which the analysis is performed and the target function is invoked, and aggregation criteria, which specify when the aggregation function is invoked to produce the state information for the window to be passed to subsequent aggregation functions or target functions.

[0082] Thereafter, the poller device 132 enters a window loop 710 and an aggregation loop 720, as Figure 7As shown. Window loop 710 illustratively represents operations taken for a given window in a data stream such that, for example, each iteration of the loop occurs for a different message window on the stream. Aggregation loop 720 represents operations taken on a subset of messages within a window to perform intermediate processing on those messages and facilitate the generation of state information that is to be used during subsequent instances (if any) of loop 720 or passed to a target function at the end of window loop 710.

[0083] Within loops 710 and 720, poller device 132 obtains messages from the stream. Illustratively, poller device 132 may obtain messages by reading messages from the stream. Alternatively, poller device 132 may include a separate process to read messages from the stream and place the messages in a local cache of device 132, and the messages may be read from the local cache during the implementation of routine 700.

[0084] At block 706, poller device 132 assigns each message to a window. Illustratively, device 132 may examine attributes of each message, such as a timestamp, to identify one or more windows corresponding to the message. In the instance of non-overlapping windows, the device may calculate a single window for each message based on window boundaries calculated from a fixed point in time. For example, the start time (t = 0) may be the first boundary, where additional boundaries created at fixed intervals correspond to the duration of each window. In the instance of sliding windows, poller device 132 may assign each message to a new window having a start time corresponding to the attributes of the message, as well as any previous windows that include the timestamp of the message and have not yet closed.

[0085] At block 708, poller device 132 determines whether the message satisfies the aggregation criteria for any open window. For example, poller device 132 may determine for each open window whether the set of unprocessed messages for that window collectively satisfy the aggregation criteria for that window. The aggregation criteria may be satisfied, for example, based on the total number of unprocessed messages, the total size of the unprocessed messages, or detecting that the window should close (e.g., based on detecting a message with a timestamp attribute after the close time of the window). If the aggregation criteria are not satisfied, routine 700 returns to block 704, where additional messages are obtained and routine 700 continues as described above.

[0086] When the aggregation criteria are met, routine 700 proceeds to block 712, where the aggregation function is called for those unprocessed messages of the streams that meet the aggregation criteria. When the aggregation function is called, the poller device 132 may pass the previous state information of the window to the aggregation function, if any. The previous state information may include, for example, an initial state value (e.g., a null value) or state information returned as a result of a previous invocation of the aggregation function. As described above, the previous state information can then be used to execute the aggregation function on the serverless computing system 110, and the execution of the aggregation function illustratively returns a result to the poller device 132. The poller device 132 in turn updates the state of the window corresponding to the invocation at block 714.

[0087] Routine 700 then proceeds to block 716, where the poller device 132 determines whether the closing criteria for any open window are met and whether all messages of the window have been processed by the aggregation function. As described above, each window may be associated with a time span on the stream, and the closing criteria may thus indicate that the window will close after that time span has elapsed. For example, the poller device 132 may determine that the window should close after detecting a message with a timestamp after the window time span, a threshold period after detecting such a message, etc. If the closing criteria are not met, or if messages remain unprocessed within the window, routine 700 returns to block 704 and proceeds as described above. If the window is to be closed and all messages have been processed, routine 700 exits the aggregation loop 720 for that window and proceeds to block 718, where the poller device 132 calls a target function (e.g., generated based on calling the aggregation function for the messages in the window) with the final state of the window. As described above, the target function illustratively processes the final state of the window to determine the action (if any) to be taken for that state, such as reporting the state to an end user, reporting the state to a logging endpoint, etc. Then routine 700 exits the window loop 710 and returns to block 704, where additional messages for other windows are obtained and processed in the manner described above. Then routine 700 may continue to process additional messages, thereby providing a streaming analysis for the messages within the data stream.

[0088] Although Figure 7Illustrates an example routine 700, but various additions or modifications can be made to routine 700. For example, as described above, the poller device 132 can implement checkpoint operations or other functions in some instances to provide resiliency in operations, such as by recording the state of the poller device 132 at different times. As another example, although the calls to the aggregation function and the target function are discussed separately, in some cases, these calls may be combined. For example, routine 700 can be modified to combine boxes 712 and 718 in the case where the aggregation function is called due to window closure. The receive function (e.g., representing the combination of the aggregation function and the target function) can then process any unprocessed messages to generate a final state and implement the target function based on that final state. In the case where this function is called due to window closure, this can obviate the need for box 714 regarding the final call to the aggregation function. Various additional modifications can be made.

[0089] The various exemplary embodiments of the present disclosure can be described by the following clauses:

[0090] Clause 1. A system for performing streaming analysis using serverless code execution, the system comprising:

[0091] A streaming data system comprising a set of computing devices configured to host a data stream including messages, wherein each message within the data stream is associated with a timestamp corresponding to a relative position within the data stream;

[0092] A serverless computing system configured to obtain a call to a serverless function and initiate execution of the serverless function in response, wherein the serverless function comprises:

[0093] An aggregation function representing executable code to process one or more input messages from the data stream and generate state information representing an analysis of the one or more input messages; and

[0094] A target function representing executable code to process the state information from the aggregation function; and

[0095] A poller device configured to:

[0096] Iteratively retrieve messages from the data stream;

[0097] Using window criteria, assign each retrieved message to one of a plurality of windows; and

[0098] For each of the plurality of windows:

[0099] Group the messages assigned to the window according to aggregation criteria to produce at least a first group of messages and a second group of messages;

[0100] Invoke a first execution of the aggregation function to process the first set of messages;

[0101] Obtain first status information from the first execution;

[0102] Invoke a second execution of the aggregation function to process the second set of messages, at least in part by passing the first status information to the second execution of the aggregation function, wherein the second execution of the aggregation function produces second status information; and

[0103] Invoke an execution of the target function, at least in part by passing the second status information to the execution of the target function, wherein the execution of the target function provides processing of the results of the streaming analysis of the messages assigned to the window.

[0104] Clause 2. The system according to clause 1, wherein the aggregation function represents executable code to provide at least one of a count, an average, a maximum, or a minimum of fields within the one or more input messages.

[0105] Clause 3. The system according to any one of the preceding clauses, wherein the windowing criterion specifies non-overlapping windows of a fixed length.

[0106] Clause 4. The system according to any one of clauses 1 and 2, wherein the windowing criterion specifies a sliding window, and wherein the poller device is further configured to add a new window to the plurality of windows for each message retrieved from the data stream.

[0107] Clause 5. The system according to any one of the preceding clauses, wherein the data stream is divided into a plurality of shards, and wherein the poller device is included within a plurality of poller devices, the plurality of poller devices including at least one poller device assigned to each of the plurality of shards, and wherein iteratively retrieving messages from the data stream includes iteratively retrieving messages from the shard to which the poller device is assigned.

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

[0109] Iteratively retrieve messages from a data stream;

[0110] Using a windowing criterion, assign each retrieved message to one of a plurality of windows; and

[0111] For each of the plurality of windows:

[0112] Group the messages assigned to the window according to an aggregation criterion to produce at least a first set of messages and a second set of messages;

[0113] The first execution of an aggregation function is invoked on a serverless computing system, where the aggregation function represents executable code to process a set of input messages and provide status information as a result, where the first set of messages represents an input set for the first execution, and where the result of the first execution is first status information;

[0114] Obtain the first status information from the first execution; and

[0115] A second execution of the aggregation function is invoked on the serverless computing system, where the second set of messages represents an input set for the second execution, where invoking the second execution includes passing the first status information to the second execution, and where the result of the second execution is second status information; and

[0116] An execution of a target function is invoked on the serverless computing system, where the target function represents executable code to process input status information from the aggregation function and provide a result, and where the second status information represents input status information for executing the target function.

[0117] Clause 7. The computer-implemented method according to clause 6, wherein the aggregation function and the target function represent a single function on the serverless computing system, wherein invoking the aggregation function includes invoking the single function with an input request function of the aggregation function, and wherein invoking the target function includes invoking the single function with an input request function of the target function.

[0118] Clause 8. The computer-implemented method according to any one of clauses 6 and 7, wherein invoking the aggregation function includes passing existing status information of a window associated with the invocation of the aggregation function, and wherein the method further includes generating initial status information for each of the plurality of windows.

[0119] Clause 9. The computer-implemented method according to any one of clauses 6-8, wherein passing the first status information to the second execution includes passing the first status information as a parameter during the invocation of the second execution.

[0120] Clause 10. The computer-implemented method according to any one of clauses 6-9, further comprising: before invoking the execution of the target function, determining that the second status information represents the final status information of the current window by at least partially determining that no additional messages assigned to the current window are waiting to be processed by the aggregation function and determining that the time span of the current window has passed.

[0121] Clause 11. The computer-implemented method according to Clause 10, wherein determining that the time span of the current window has elapsed includes determining that the retrieved message is associated with a timestamp after the time span.

[0122] Clause 12. The computer-implemented method according to any one of Clauses 6-11, wherein the aggregation criterion specifies at least one of a maximum number of messages within each group or a maximum data size of messages within each group.

[0123] Clause 13. The computer-implemented method according to any one of Clauses 6-12, wherein the windowing criterion specifies a sliding window, and wherein the method further includes adding a new window to the plurality of windows for each message retrieved from the data stream.

[0124] Clause 14. A non-transitory computer-readable medium comprising instructions that, when executed by a computing system, cause the computing system to:

[0125] Iteratively retrieve messages from a data stream;

[0126] Using a windowing criterion, assign each retrieved message to one of a plurality of windows; and

[0127] For each window of the plurality of windows:

[0128] Group the messages assigned to the window according to an aggregation criterion to produce at least a first group of messages and a second group of messages;

[0129] Invoke a first execution of an aggregation function on a serverless computing system, wherein the aggregation function represents executable code to process a set of input messages and provide status information as a result, wherein the first group of messages represents the input set for the first execution, and wherein the result of the first execution is first status information;

[0130] Invoke a second execution of the aggregation function on the serverless computing system, wherein the second group of messages represents the input set for the second execution, wherein invoking the second execution includes passing the first status information to the second execution, and wherein the result of the second execution is second status information; and

[0131] Invoke an execution of a target function on the serverless computing system, wherein the target function represents executable code to process input status information from the aggregation function and provide a result, and wherein the second status information represents the input status information for executing the target function.

[0132] Clause 15. The non-transitory computer-readable medium according to Clause 14, wherein the aggregation function and the target function represent a single function on the serverless computing system, wherein the instructions, when executed, cause the computing system to call the aggregation function at least in part by invoking the single function with an input request for the aggregation function, and wherein the instructions, when executed, cause the computing system to call the target function at least in part by invoking the single function with an input request for the target function.

[0133] Clause 16. The non-transitory computer-readable medium according to any one of Clauses 14-15, wherein the instructions, when executed, cause the computing system to call the aggregation function at least in part by passing existing state information of the current window to the aggregation function, and wherein the instructions, when executed, cause the computing system to generate initial state information for each of the plurality of windows.

[0134] Clause 17. The non-transitory computer-readable medium according to any one of Clauses 14-16, wherein, in order to pass the first state information to the second execution, the instructions, when executed, cause the computing system to pass the first state information as a parameter during the invocation of the second execution.

[0135] Clause 18. The non-transitory computer-readable medium according to any one of Clauses 14-17, wherein the instructions, when executed, further cause the computing system to determine that the second state information represents the final state information of the current window at least in part by determining that no additional messages assigned to the current window are waiting to be processed by the aggregation function and determining that the time span of the current window has passed before invoking the execution of the target function.

[0136] Clause 19. The non-transitory computer-readable medium according to Clause 18, wherein determining that the time span of the current window has passed includes determining that the retrieved message is associated with a timestamp after the time span.

[0137] Clause 20. The non-transitory computer-readable medium according to any one of Clauses 14-19, wherein the windowing criterion specifies a sliding window, and wherein the instructions, when executed, further cause the computing system to add a new window to the plurality of windows for each message retrieved from the data stream.

[0138] All of the methods and processes described above can be embodied in software code modules executed by one or more computers or processors and fully automated via the software code modules. These code modules can be stored in any type of non-transitory computer-readable medium or other computer storage device. Some or all of the methods can alternatively be embodied in dedicated computer hardware.

[0139] Unless otherwise expressly specified, conditional language such as, among others, "able to", "can", "could", or "may", is generally to be understood in context as presenting that certain embodiments include certain features, elements, and / or steps, while other embodiments do not include certain features, elements, and / or steps. Thus, such conditional language is generally not intended to imply that the features, elements, and / or steps are necessary for one or more embodiments in any way, or that one or more embodiments must include logic for deciding, with or without user input or prompting, whether to include such features, elements, and / or steps or whether to perform such features, elements, and / or steps in any particular embodiment.

[0140] Unless otherwise expressly specified, disjunctive language such as the phrase "at least one of X, Y, or Z" is generally to be understood in context as presenting that items, elements, 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 and should not be construed to imply that certain embodiments require the presence of at least one of X, at least one of Y, or at least one of Z, respectively.

[0141] Unless otherwise expressly specified, articles such as "a" or "an" are generally to be understood as including one or more of the items described. Thus, phrases such as "a device configured to..." are intended to include one or more of the described devices. Such one or more of the described devices can also be collectively configured to perform the stated recitation. For example, "a processor configured to perform recitations A, B, and C" can include a first processor configured to perform recitation A working in conjunction with a second processor configured to perform recitations B and C.

[0142] Any routine descriptions, elements, or blocks in the flowcharts described and / or depicted in the figures herein are to be understood as potentially representing code modules, segments, or portions including one or more executable instructions for implementing specific logical functions or elements in the routine. Alternative implementations are within the scope of the embodiments described herein, where, as understood by those skilled in the art, according to the involved functions, elements, or functions can be deleted, or executed out of the order shown or discussed, including substantially synchronously or in reverse order.

[0143] It should be emphasized that many changes and modifications can be made to the above embodiments, and the elements of these changes and modifications should be understood to be among other acceptable examples. In this document, all such modifications and changes are intended to be included within the scope of this disclosure and are protected by the appended claims.

Claims

1. A system for performing streaming analysis using serverless code execution, the system comprises: A streaming data system, which includes a set of computing devices configured to host a data stream including messages, and each message within the data stream is associated with a timestamp corresponding to a relative position within the data stream; A serverless computing system configured to obtain a call to a serverless function and initiate the execution of the serverless function in response, where the serverless function includes: An aggregation function, which represents executable code to process one or more input messages from the data stream and generate status information representing an analysis of the one or more input messages; and A target function, which represents executable code to process the status information from the aggregation function; and A poller device configured to: Iteratively retrieve messages from the data stream; Using a window criterion, assign each retrieved message to one of a plurality of windows; and For each of the plurality of windows: Group the messages assigned to the window according to an aggregation criterion to produce at least a first group of messages and a second group of messages; Invoke a first execution of the aggregation function to process the first group of messages; Obtain first status information from the first execution; Invoke a second execution of the aggregation function to process the second group of messages by at least partially passing the first status information to the second execution of the aggregation function, where the second execution of the aggregation function produces second status information; and Invoke the execution of the target function by at least partially passing the second status information to the execution of the target function, where the execution of the target function provides processing of the result of the streaming analysis for the messages assigned to the window.

2. The system according to claim 1, wherein the aggregation function represents executable code to provide at least one of a count, an average, a maximum, or a minimum of fields within the one or more input messages.

3. The system according to claim 1, wherein the windowing criterion specifies non-overlapping windows of a fixed length.

4. The system according to claim 1, wherein the windowing criterion specifies a sliding window, and wherein the poller device is further configured to add a new window to the plurality of windows for each message retrieved from the data stream.

5. The system according to claim 1, wherein the data stream is divided into a plurality of shards, and wherein the poller device is included within a plurality of poller devices, the plurality of poller devices including at least one poller device assigned to each of the plurality of shards, and wherein iteratively retrieving messages from the data stream includes iteratively retrieving messages from the shard to which the poller device is assigned.

6. A computer-implemented method, which comprises: Iteratively retrieve messages from a data stream; Using a window criterion, assign each retrieved message to one of a plurality of windows; And For each of the plurality of windows: Group the messages assigned to the window according to an aggregation criterion to produce at least a first group of messages and a second group of messages; Invoke a first execution of an aggregation function on a serverless computing system, where the aggregation function represents executable code to process a set of input messages and provide status information as a result, where the first group of messages represents the input set for the first execution, and where the result of the first execution is first status information; Obtain the first status information from the first execution; Invoke a second execution of the aggregation function on the serverless computing system, where the second group of messages represents the input set for the second execution, where invoking the second execution includes passing the first status information to the second execution, and where the result of the second execution is second status information; And Invoke an execution of a target function on the serverless computing system, where the target function represents executable code to process input status information from the aggregation function and provide a result, and where the second status information represents the input status information for the execution of the target function.

7. The computer-implemented method according to claim 6, wherein the aggregation function and the target function represent a single function on the serverless computing system, wherein invoking the aggregation function includes invoking the single function with an input request function of the aggregation function, and wherein invoking the target function includes invoking the single function with an input request function of the target function.

8. The computer-implemented method according to claim 6, wherein invoking the aggregation function includes passing existing status information of a window associated with the invocation of the aggregation function, and wherein the method further includes generating initial status information for each of the plurality of windows.

9. The computer-implemented method according to claim 6, wherein passing the first status information to the second execution includes passing the first status information as a parameter during the invocation of the second execution.

10. The computer-implemented method according to claim 6, which further includes: Before invoking the execution of the target function, determine that the second status information represents the final status information of the current window by at least partially determining that no additional messages assigned to the current window are waiting to be processed by the aggregation function and determining that the time span of the current window has passed.

11. The computer-implemented method according to claim 10, wherein determining that the time span of the current window has passed includes determining that the retrieved messages are associated with a timestamp after the time span.

12. The computer-implemented method according to claim 6, wherein the aggregation criterion specifies at least one of a maximum number of messages within each group or a maximum data size of messages within each group.

13. The computer-implemented method according to claim 6, wherein the windowing criterion specifies a sliding window, and wherein the method further comprises adding a new window to the plurality of windows for each message retrieved from the data stream.

14. A non-transitory computer-readable medium comprising instructions that, when executed by a computing system, cause the computing system to: Iteratively retrieve messages from a data stream; Using a windowing criterion, assign each retrieved message to one of a plurality of windows; and For each of the plurality of windows: Group the messages assigned to the window according to an aggregation criterion to produce at least a first group of messages and a second group of messages; Invoke a first execution of an aggregation function on a serverless computing system, wherein the aggregation function represents executable code to process a set of input messages and provide status information as a result, wherein the first group of messages represents the input set for the first execution, and wherein the result of the first execution is first status information; Invoke a second execution of the aggregation function on the serverless computing system, wherein the second group of messages represents the input set for the second execution, wherein invoking the second execution includes passing the first status information to the second execution, and wherein the result of the second execution is second status information; And Invoke an execution of a target function on the serverless computing system, wherein the target function represents executable code to process input status information from the aggregation function and provide a result, and wherein the second status information represents the input status information for the execution of the target function.

15. The non-transitory computer-readable medium according to claim 14, wherein the aggregation function and the target function represent a single function on the serverless computing system, wherein the instructions, when executed, cause the computing system to invoke the aggregation function at least in part by invoking the single function with the input request function of the aggregation function, and wherein the instructions, when executed, cause the computing system to invoke the target function at least in part by invoking the single function with the input request function of the target function.

16. The non-transitory computer-readable medium according to claim 14, wherein the instructions, when executed, cause the computing system to invoke the aggregation function at least in part by passing existing status information of the current window to the aggregation function, and wherein the instructions, when executed, cause the computing system to generate initial status information for each of the plurality of windows.

17. The non-transitory computer-readable medium according to claim 14, wherein, in order to pass the first status information to the second execution, the instructions, when executed, cause the computing system to pass the first status information as a parameter during the invocation of the second execution.

18. The non-transitory computer-readable medium according to claim 14, wherein the instructions, when executed, further cause the computing system to determine that the second state information represents final state information of the current window, at least in part, by determining that no additional messages assigned to the current window are waiting to be processed by the aggregation function and determining that a time span of the current window has elapsed, before invoking the execution of the target function.

19. The non-transitory computer-readable medium according to claim 18, wherein determining that the time span of the current window has elapsed includes determining that a retrieved message is associated with a timestamp after the time span.

20. The non-transitory computer-readable medium according to claim 18, wherein the windowing criterion specifies a sliding window, and wherein the instructions, when executed, further cause the computing system to add a new window to the plurality of windows for each message retrieved from the data stream.

Images