08 Function Compute Development and Configuration #

Abstract: In this article, the “Basic Concepts” section mainly provides a detailed introduction to the core concepts of function computing, including services, functions, triggers, versions, aliases, and related configurations. The “Development Process” section introduces the complete development and deployment process based on function computing.

Basic Concepts #

1. Services #

A service is the unit of resource management in function computing. There are many functions under the same service, and these functions share the network configuration, permission configuration, storage configuration, and log configuration of the service.

A service can be considered as an “application” composed of many functions. These functions have the same access permissions, network configurations, and logs recorded in the same log store. The configuration of these functions can vary. For example, some functions have 3GB of memory, while others have 512MB. Some functions are written in Python, while others are written in Node.js.

Of course, if the application is more complex, the same application can correspond to multiple services, and there is no strict binding relationship here.

1) Service Configuration

Next, we will introduce several core configurations of services:

Log configurations: In function computing, how can developers view the logs generated by the code during function execution? In the serverless development model, logs are written to a unified file and collected into ElasticSearch through log collection tools like Logstash/Fluentd. They can be viewed through visualization tools like Kibana. However, in function computing, the machines running the code are dynamically assigned by the function computing platform, and developers are unable to collect logs themselves. Function computing needs to assist developers in delivering logs. This is where log configurations come into play. By configuring LogConfig, the log service’s Project and Logstore are set. Function computing will deliver the logs generated during function execution to the developer’s Logstore.

However, in order to successfully deliver logs, it is not enough to simply configure the Logstore. Function computing does not have permission to deliver logs to the developer’s Logstore. Users need to grant function computing the permission to write data to the specified Logstore. Once this authorization is granted, function computing can legitimately deliver logs to the developer’s Logstore.

File storage configuration: Each function in function computing is independent and executed in different execution environments. What if users have some common files that they want multiple functions to share? In the traditional serverless development model, it’s easy. Just put the common files on the disk and let everyone read them from the same location on the disk. In function computing, the machines are dynamically assigned by function computing, and developers cannot pre-store files on the disk. What should be done in this case? NAS (Network Attached Storage) can be mounted in the service. After NAS is mounted in the service, functions can access files on NAS as if accessing the local file system.

Network configuration: As the name suggests, network configuration is used to set the network access capabilities of functions. There are mainly two types: whether the function can access the public network and whether the function can access a specified VPC (Virtual Private Cloud). VPC is a private network, and data within the VPC is confidential and cannot be accessed through public internet. If the function needs to access resources within the VPC, such as an RDS (Relational Database Service) within the VPC, it needs to grant function computing the ability to access the specified VPC. The principle is to authorize elastic network interfaces (ENIs) to access the VPC, and insert this ENI into the machine where function computing executes the user function. This allows the function to access resources within the VPC.

Permissions: Function computing is a cloud-native architecture that interacts with many services in the cloud. Alibaba Cloud has very strict permission restrictions, and function computing does not have the ability to access other cloud resources of developers. When developers need function computing to access other cloud services, they need to explicitly grant function computing the permission.

There are two main scenarios for permissions: granting function computing the permission to access other services, such as authorizing function computing to access the developer’s log service or authorizing function computing to create ENIs; and granting function computing the permission to access the developer’s cloud resources. What is this second scenario? For example, if the function needs to access an object in Object Storage Service (OSS), but the access key (AK) should not be exposed, what should be done? Developers can configure the Role in the service with permissions to access OSS. During function execution, function computing will assume the role and generate a temporary access key (AK), and store this AK in the function’s context context.credentials. Developers can use context.credentials.access_key_id``/``context.credentials.access_key_secret``/``context.credentials``.``security_token``  in the code to create an OSS client.

2. Functions #

In “Function Computing,” functions can be considered as core concepts. Functions are the basic units of management and execution, and a function is usually composed of a series of configurations and executable code packages.

1) Function Configuration

The configuration of the function is shown in the above figure:

• Runtime is the environment type in which the function runs: Function Compute currently supports development environments such as Node.js/Python/Java/C#/PHP, and also supports Custom Runtime for custom development environments;
• Code is the function code package: Function Compute only recognizes code packages on the backend, and various development tools will automatically package them for you. For example, you can directly write code on the console, and the console will automatically package and create/update the function for you. You can also write/debug functions locally and deploy them to Function Compute through the command-line tool Funcraft, which will also help package them;
• Handler is the entry function: You have written many functions in the code package, so where does the function compute start executing? It starts executing from the entry function you specified;
• Timeout is the function’s timeout period: If the function execution exceeds this time, the function will be forcibly stopped;
• MemorySize is the memory allocated for the function’s execution environment: Currently, the range is 128M~3G. If the function consumes more memory than the allocated memory, an OOM error will occur;
• Initializer is the initialization function: What is it used for? We mentioned earlier when introducing the function compute execution environment that function compute will allocate an execution environment for the function. When it is allocated for the first time, it will have a cold start. After the current request is completed, function compute will not release it immediately. If there are new requests within a certain period of time, it will reuse this execution environment. The logic in Initializer will be executed after allocating the execution environment, and ensure that the same execution environment is executed only once. Therefore, you can put some time-consuming operations such as establishing connections and loading dependencies in the Initializer function;
• InitializerTimeout is the maximum running time for the Initializer function.

3. Trigger #

Previous lessons have introduced the various types of event sources supported by Function Compute. In the event-driven computing model, the event source is the producer of the event, and the function is the handler of the event. Triggers provide a centralized and unified way to manage different event sources. When an event occurs and satisfies the rules defined by the trigger, the event source will automatically invoke the function corresponding to the trigger.

Typical use cases include processing objects uploaded to OSS, such as image processing, audio and video transcoding, OSS zip package decompression, and cleaning, processing, and storing logs in SLS. Functions can also be triggered to execute at specified times.

4. Version & Alias #

The previous section introduced services, functions, and triggers, so developers can build applications based on Function Compute. However, a new problem arises: When developers have new requirements and need to update the code, how can they ensure that the online application is not affected and smoothly iterate for deployment? To solve this problem, Function Compute introduces versions and aliases.

Versions are like snapshots of services, which include the service’s configuration, function code, and function configuration. After you finish development and testing, you can publish a version. Versions have monotonically increasing names and cannot be modified after being published. You can continue to develop and test on the Latest version without affecting the published versions. When calling a function, you only need to specify the version to call the specified version of the function.

But a new problem arises again: Function Compute specifies monotonically increasing version names, so there will be a new version each time a version is published. After each version is published, does the client need to modify the code to execute the latest version? To solve this problem, we introduce aliases. An alias is a pointer to a specific service version. After it is published, you only need to point the alias to the published version. After it is published again, switch the alias to point to the latest version. The client only needs to specify the alias to ensure that it calls the latest code online. At the same time, aliases support gray release, which means that 10% of the traffic points to the latest version and 90% theoretically points to the old version. Rollback is also very simple, just need to switch the alias to the previous version to quickly complete the rollback.

Development Process #

As shown in the above figure, developers first create a service, set up log and permission configurations, and then create a function. Write code to develop the function under the current version (Latest version), and after passing the test, publish a version. The first published version is Version 1. Create an alias prod pointing to Version 1, and then you can provide the service externally.

Logs of client calls to the function will be recorded in the Logstore configured by the developer. Function Compute provides comprehensive monitoring charts. After the application is launched, developers can use the monitoring charts and logs to view the health status of the application.

When developers have new requirements, they continue to change the code and develop functions in the Latest version. After passing the test, they publish a new version, which is Version 2 this time. Then, switch 10% of the traffic to Version 2 by changing the alias. This achieves the purpose of gradually releasing the application. If everything is normal after observing for a period of time, switch 100% of the traffic to Version 2.