By Kong Dehui (Xiawan), Alibaba Cloud Function Compute Development Engineer
In a serverless architecture, developers can focus on developing, building, and deploying applications, without the need to manage and maintain servers. In a Function Compute architecture, developers only need to define service code and monitor the running status of services. This frees developers from cumbersome O&M work, allowing them to focus on meaningful business development.
As we all know, serverless does not mean that no servers are used, but rather that developers no longer need to worry about servers. The following figure shows a comparison between the conventional and Function Compute-based application building processes, from application development to application release.
To deploy an application in a conventional serverful architecture, you must purchase a server, deploy an operating system, build a development environment, define code, build an application, deploy the application, configure the load balancing mechanism, build a log analysis and monitoring system, release the application, and monitor the running status of the released application. In contrast, in a serverless architecture, developers can focus on developing, building, and deploying applications, without the need to manage and maintain servers. In a Function Compute architecture, developers only need to define service code and monitor the running status of services. This frees developers from the cumbersome O&M work, allowing them to focus on meaningful business development.
The preceding figure shows how Function Compute is used. All a user needs to do is write code and then upload the code to the Function Compute system. Uploading the code is the same as deploying the application. When a large number of concurrent requests flood the Function Compute service, developers do not need to manually scale up the system. Instead, the Function Compute system automatically scales up within milliseconds based on the number of requests, ensuring that tasks run flexibly and reliably. In addition, the Function Compute system provides built-in features such as log query, performance monitoring, and alerting, helping developers quickly find and locate problems.
Function Compute is mainly used in the following types of applications:
Function Compute has been integrated with more than a dozen products, including Object Storage Service (OSS), Tablestore, Timer, CDN, Log Service, and CloudMonitor. This allows you to quickly assemble business logic.
The preceding figure shows the complete request and call traces in Function Compute. Function Compute is an event-driven serverless application. Event-driven means that functions are automatically triggered by event sources. For example, when an object is uploaded to OSS, a function is automatically triggered to process the uploaded object. Function Compute supports a wide range of event sources, including SLS, OSS, OTS, Message Service (MNS), API Gateway, and CDN.
In addition, functions can be directly called by using API operations or SDKs. Calls can be divided into synchronous calls and asynchronous calls. When a request arrives at a Function Compute system, the system allocates an execution environment for the request. If a request requires an asynchronous call, the Function Compute system stores the request event in a queue waiting for consumption.
A synchronous call is used when the client expects the server to immediately return computing results. When a request arrives at the Function Compute system, the system immediately allocates an execution environment to run the function.
For example, after API Gateway synchronously triggers the Function Compute system, the client keeps waiting for the execution result from the server. If an error occurs during execution, the Function Compute system will return an error message directly, instead of retrying to process the request. In this case, you need to add a retry mechanism to the client to handle the error.
An asynchronous call is used when the client does not need to immediately know the function execution result. In this case, the Function Compute system drops the request to a queue and then returns a successful response, instead of waiting until the function call ends.
The Function Compute system gradually consumes requests in the queue, allocates execution environments, and executes functions. If an error occurs during the execution, the Function Compute system retries to process the request. Specifically, if the error is a function error, the Function Compute system retries three times. If the error is a system error, the Function Compute system retries with exponential backoff until the request is processed.
Asynchronous calls are applicable to data processing scenarios, such as when an OSS trigger triggers a function to process audio and video data or a log trigger triggers a function to cleanse logs. These scenarios are latency-insensitive but require successful task execution. You can use the Destination feature if you want to identify failed requests and process the failed requests as needed.
The Function Compute system adopts a serverless architecture. This does not mean that no servers are used. Instead, this means that developers do not have to deal with servers. The Function Compute system allocates instances to developers to run functions.
As shown in the preceding figure, when a function is called for the first time, the Function Compute system must dynamically schedule an instance, download and decompress the code, and start the instance to obtain a code environment where the function can be run. Then, the Function Compute system starts to run the user's initializer function in the instance allocated by the system and executes the business logic of the function. The process from scheduling an instance to starting the instance is the cold start process of the system.
After the function logic is executed, the system does not release the instance immediately, but retains the instance for a period of time. If a new call occurs during this period, the system directly reuses the instance. For example, in the preceding figure, request 2 occurs during this period of time, and then the system directly reuses the previously allocated execution environment to process request 2. In this case, request 2 does not need to go through the cold start process of the system.
After request 2 is executed, the system waits for a period of time. If no new requests are allocated to the instance during this period, the system recycles the instance and releases the execution environment. After the instance is released, if request 3 is sent to the Function Compute system, the Function Compute system needs to reschedule an instance, download and decompress code, and start the instance. In other words, the new request has to go through the cold start process.
To minimize the impact of the cold start, we recommend that you do your best to avoid cold starts and reduce the latency caused by cold starts.
Function Compute provides reserved instances to allow you to completely avoid cold starts. Soon after you reserve an instance, the system allocates the reserved instance and prepares an execution environment. The system does not automatically recycle the instance even after all requests are processed.
The Function Compute system does not automatically allocate or recycle reserved instances. Instead, you can manage the lifecycle of a reserved instance and make the reserved instance resident in the system. Reserved instances allow the system to avoid the latency caused by cold starts, enhancing performance and facilitating the migration of online applications to the Function Compute system.
If reserved instances are not applicable to your business scenarios, you need to reduce the latency caused by cold starts in other ways. For example, you can reduce the size of the code package to shorten the time it takes to download and decompress. The initializer function initializes an instance. It runs in the same instance and can run only once. Therefore, you can add time-consuming common logic to the initializer function. For example, you can enable the initializer function to load dependencies to a Network Attached Storage (NAS) instance and establish a connection. In addition, we recommend that you ensure that requests are received continuously and stably to avoid sudden bursts of traffic. Otherwise, if the instances already started in the system cannot handle the traffic, cold starts are inevitable.
506 posts | 48 followers
FollowAlibaba Developer - February 1, 2021
Alibaba Clouder - February 3, 2021
Alibaba Clouder - December 11, 2020
Alibaba Clouder - April 16, 2019
Alibaba Cloud Native Community - August 25, 2022
Alibaba Cloud Serverless - March 8, 2023
506 posts | 48 followers
Follow
Function Compute
Alibaba Cloud Function Compute is a fully-managed event-driven compute service. It allows you to focus on writing and uploading code without the need to manage infrastructure such as servers.
Learn More
Microservices Engine (MSE)
MSE provides a fully managed registration and configuration center, and gateway and microservices governance capabilities.
Learn More
Serverless Workflow
Visualization, O&M-free orchestration, and Coordination of Stateful Application Scenarios
Learn More
Serverless Application Engine
Serverless Application Engine (SAE) is the world's first application-oriented serverless PaaS, providing a cost-effective and highly efficient one-stop application hosting solution.
Learn MoreMore Posts by Alibaba Cloud Native Community
