This topic describes the runtime extension feature of Function Compute that is developed based on traditional long-running applications to help you eliminate idle costs.
Long-running applications and FaaS execution environment
Traditional long-running virtual machines or managed container services often use a billing interval that starts when an instance is started and ends when the instance is stopped. You are charged even if no request is executed during this interval. Function Compute charges you at a billing granularity of 1 ms. Instances are billed only during the execution of actual requests. The instances are frozen in time periods where no requests are executed. This basically eliminates the idle costs of a fully event-driven billing model. However, the freezing mechanism breaks the assumption of long-running processes in traditional architectures and increases the difficulty in migrating applications. For example, the commonly used open source distributed Tracing Analysis libraries or third-party application performance management (APM) solutions cannot correctly report data due to the special execution environment of Function Compute.
The following pain points hinder the smooth migration of traditional applications to a serverless architecture:
- Data of asynchronous background metrics is delayed or lost. If the data fails to be sent during the execution of a request, the data may be delayed until the next request or data points are discarded.
- The latency is increased if metrics are sent synchronously. If a method similar to Flush is called after each request is completed, this not only increases the latency of each request, but also causes unnecessary pressure on backend servers.
- To support graceful release of functions, applications need to close connections, stop processes, and report status when instances are stopped. Developers do not know when instances are released in Function Compute. In addition, no webhook is provided to send notifications about release events of function instances.
Programming model extensions
Function Compute provides the runtime extension feature to resolve the preceding pain points. The feature extends the existing programming model for HTTP servers by adding the PreFreeze and PreStop webhooks to the existing HTTP server model. Extension developers implement an HTTP handler to monitor lifecycle events of function instances.
- PreFreeze: Each time Function Compute decides to freeze the current function instance, Function Compute sends an HTTP GET request to the /pre-freeze path. Extension developers implement the logic to ensure that necessary operations are completed before the instance is frozen. For example, the instance waits until metrics are sent. The function invocation time does not include the execution time of the PreFreeze webhook.
- PreStop: Each time Function Compute decides to stop the current function instance, Function Compute sends an HTTP GET request to the /pre-stop path. Extension developers implement the logic to ensure that necessary operations are completed before the instance is released. For example, database connections are closed and the status is reported or updated.
The billing method for PreFreeze or PreStop calls is the same as that for InvokeFunction calls. You are not charged for the number of requests sent to the HTTP hooks. The extensions are also applicable to scenarios in which multiple concurrent requests are executed on a single instance. Assume that multiple invocation requests are concurrently executed on the same instance. After all the requests are completed, the PreFreeze hook is called before the instance is frozen. In the example shown in the following figure, the specification of the function is 1 GB. Assume that the period from t1 when PreFreeze starts to t6 when Request 2 is completed is 1s. The execution time of the instance is calculated based on the following formula: t6 - t1. The consumed resource is calculated based on the following formula: 1s × 1 GB = 1 CU.