Function Compute:Basic concepts

Overview

function

A function is a unit by which Function Compute schedules and runs resources. A FC function consists of function code and function configurations. For more information, see Create a web function.

version

A version can be considered as a snapshot of a function. A version contains information such as the function configurations and code. A version does not contain trigger information. A version is similar to a commit in Git. Each commit contains changes to one or more code files or settings, and represents a snapshot of a repository at a specific point in time. For more information, see Manage versions.

alias

Aliases can be considered as pointers to specific function versions. You can use aliases to manage versions. For example, you can use aliases to release or roll back versions, or implement canary releases. An alias is similar to a tag in Git. You can add a tag to a commit and release the commit to perform a business iteration. For more information, see Manage aliases.

layer

Layers allow you to publish and deploy custom resources such as public dependency libraries, runtimes, and function extensions. You can use a layer to abstract the public libraries on which a function depends. This reduces the size of the function code package when you deploy and update the function. You can also deploy a custom runtime as a layer to share the runtime among multiple functions. For more information, see Create a custom layer.

trigger

A trigger is a way to trigger function execution. In an event-driven computing model, an event source is an event producer, and a function is an event handler. Triggers manage different event sources in a centralized manner. When an event that matches the rules defined for a trigger occurs, the event source automatically invokes the function associated with the trigger. For more information, see Trigger overview.

runtime

A runtime is an environment in which functions are executed. Function Compute provides runtimes in multiple programming languages. For more information, see the Built-in runtimes section of the "Overview" topic.

custom domain name

You can bind a custom domain name to an application or function that is configured with HTTP triggers. This allows users to access the application or function by using a fixed domain name. You can also configure the custom domain name as the origin domain name and add a CDN-accelerated domain name to the custom domain name. This allows users to access resources faster and improves the service quality by reducing access latency. For more information, see Configure custom domain names.

pay-as-you-go

Pay-as-you-go is a billing method that allows you to use resources first and pay for them afterward. If you use the pay-as-you-go billing method, you pay only for the Function Compute resources that you use. You do not need to purchase resources in advance. For more information, see Pay-as-you-go.

resource plan

Resource plans are prepaid packages to offset fees of resource usage. Compared with pay-as-you-go, resource plans can be more cost effective. Function Compute provides resource plans of various types. For more information, see Resource plans.

CPU instance

CPU instance is the basic instance type of Function Compute. CPU instances are suitable for scenarios in which burst traffic occurs and compute-intensive scenarios. For more information, see Instance types and usage modes.

GPU-accelerated instance

GPU-accelerated instance is a type of instances that are based on the Turing architecture and accelerate service loads by using GPU hardware. This way, service processing is more efficient. In most cases, GPU-accelerated instances are used in scenarios such as audio and video processing, AI, and image processing. For more information, see Instance types and usage modes.

cold start

A cold start occurs during steps such as code downloads, function instance starts, process initialization, and code initialization during the invocation of a function. After the cold start is complete, the function instance is ready to process subsequent requests. For more information, see Best practice for reducing cold start latencies.

on-demand mode

In on-demand mode, Function Compute automatically allocates and releases function instances. For more information, see Instance types and usage modes.

provisioned mode

In provisioned mode, function instances are allocated and released by yourself. Function Compute preferentially forwards requests to provisioned instances. If provisioned instances are not enough to process requests, the remaining requests are forwarded to on-demand instances. For more information, see Instance types and usage modes.

An instance in provisioned mode is ready for use after it is created. This eliminates impacts of cold starts.

If you create a fixed number of provisioned instances, the instances may not be fully used. You can enable scheduled or metric-based auto scaling for provisioned instances to improve instance utilization.

Scheduled auto scaling

Scheduled auto scaling allows you to configure a rule to automatically adjust the number of provisioned instances to a specific value at the specified points in time. For more information, see the Modify or delete a provisioned instance policy section of the "Configure provisioned instances" topic.

Metric-based auto scaling

Metric-based auto scaling dynamically adjusts the number of provisioned instances based on values of tracking metrics. For more information, see the Modify or delete a provisioned instance policy section of the "Configure provisioned instances" topic.

synchronous invocation

In a synchronous invocation, the result is returned after an event is processed by a function. For more information, see Synchronous invocation.

asynchronous invocation

In an asynchronous invocation, a response is immediately returned after an event triggers a function. You do not need to wait for the event to be processed by the function. Function Compute processes the event in a reliable manner but does not return the invocation details or execution status of the function. To obtain results of asynchronous invocations, you must configure destinations for asynchronous invocations. For more information, see Overview.

invocation analysis

The invocation analysis feature summarizes the execution states of function requests. After you enable invocation analysis, the system collects metrics about each invocation of a function. For more information, see Request-level metric logs.