Commoditization of computer hardware and software components has led to the rise of service providers that provide computational and storage capacity as a service. More traditional server-based service architectures require persistent provisioning and management of a server on behalf of a client. In this persistent type of traditional server architecture there may be sufficient excess capacity for the server to perform additional functionality, such as aggregating the metrics associated with server performance. The excess capacity and/or persistence of the persistent server may lend itself to software architectures that demand extra processing time (e.g., the extra processing time required by software architectures that use synchronous calls, instead of asynchronous calls, for example).
A more recent computing paradigm is a compute as a service environment that provides a serverless event driven compute service. In this stateless environment, clients may be charged for these compute services based on the amount of compute time consumed, instead of the number of virtual instances provisioned. In other words, the client code may be run only when it is needed. For example, event-based client code may be triggered, executed, and retired, all without the customer having to provision or manage servers. A few examples of event-based executable functions include image conversion, file compression, and change notifications, etc. This stateless architecture lends itself to parallel processing that triggers individually and scales more precisely with the size of the workload. Any of numerous event sources may be used to trigger event-based client code, such as receipt of an entry into a data store, or a user-interface click-based event, for example.
At least partly due to the ephemeral nature and/or the large number of instances some event-based executables, it may be a challenge to gather metrics from individual executions. For example, some event-based executables may trigger, execute, and retire before metrics can be gathered, batched and logged, or synchronous metric management may introduce unacceptably significant latency, or a centralized logging service may be overwhelmed by the large number of sources of metrics provided be each individual executable environment (e.g., in some systems each request triggers another individual executable).
While embodiments are described herein by way of example for several embodiments and illustrative drawings, those skilled in the art will recognize that embodiments are not limited to the embodiments or drawings described. It should be understood, that the drawings and detailed description thereto are not intended to limit embodiments to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope as defined by the appended claims. The headings used herein are for organizational purposes only and are not meant to be used to limit the scope of the description or the claims. As used throughout this application, the word “may” is used in a permissive sense (i.e., meaning having the potential to), rather than the mandatory sense (i.e., meaning must). Similarly, the words “include,” “including,” and “includes” mean including, but not limited to.
USPTO Backgrounds
USPTO Backgrounds