To meet user requirements in different scenarios, Function Compute provides two types of functions: event functions and HTTP functions. You can deploy functions by using built-in runtimes, custom runtimes, and container images. This topic describes the types of functions that are supported by Function Compute and the deployment methods.
Function types
Function Compute supports two types of functions: event functions and HTTP functions. Event functions apply to event-driven models in which functions are executed based on events. HTTP functions are suitable for quick building of web applications.
In the programming model of Function Compute, a handler consists of a function name, input parameters, and return values. You can also pass another function defined in the code as an input parameter to the handler.
The following table lists the differences between event functions and HTTP functions in terms of trigger methods and input parameters.
Function type | Trigger method | Input parameter | ||||||||
---|---|---|---|---|---|---|---|---|---|---|
Event function | You can trigger the execution of an event function to implement a specific feature. To trigger the execution of an event function, you can configure a time trigger, call API operations or use SDKs, or use triggers of other Alibaba Cloud services. You can create various triggers other than HTTP triggers, such as Object Storage Service (OSS) triggers, Log Service triggers, Alibaba Cloud CDN triggers, Tablestore triggers, and EventBridge triggers. For more information about supported trigger types, see Trigger overview. All supported types of triggers can be used to trigger event functions. | The following code defines a simple Node.js handler:
Description about input parameters
For more information about Node.js event functions, see Event handler. For more information about the input parameters of functions in other programming languages, see Overview. | ||||||||
HTTP functions | HTTP functions can be triggered only by HTTP or HTTPS requests. You can specify the request methods that can trigger a HTTP function, such as GET, POST, PUT, DELETE, HEAD, and PATC, based on your business requirements. Function Compute allows you to create an HTTP trigger that triggers the execution of a HTTP function by sending HTTP or HTTPS requests. Only one HTTP trigger can be created for one version or one alias of a service. For more information, see Overview. | The following code defines a simple Node.js handler:
Description about input parameters
For more information about Node.js HTTP functions, see HTTP handler. For more information about the input parameters of functions in other programming languages, see Overview. |
Deployment methods
From the perspective of the development process, you can deploy functions in the Function Compute console by using Serverless Devs, API operations, and SDKs. For more information, see Create a function in the Function Compute console, Use Serverless Devs to manage function resources, and CreateFunction.
From the perspective of runtime types, functions in Function Compute can be deployed by using built-in runtimes, custom runtimes, and container images. You can select a deployment method based on your business conditions.
Use a built-in runtime
If you want to use the interfaces defined by Function Compute to write a program for handling event requests and HTTP requests, use a built-in runtime. For more information, see Create a function.

Use a custom runtime
Use a custom runtime if you want to develop programs based on common frameworks of various languages, such as Java SpringBoot, Node.js Express, Python Flask, and Golang Gin, or migrate applications of existing frameworks. For more information, see Create a function.

Use a container image
Container Registry is a secure platform that allows you to manage and distribute cloud-native artifacts that meet the standards of Open Container Initiative (OCI) in an efficient manner. The artifacts include container images and Helm charts. If you use a container image to deploy a function, you can enjoy secure and efficient image hosting and distribution on the cloud without the need to create and maintain a self-managed image service. For more information, see Create a custom container function.

Comparison of deployment methods
Item | Use a built-in runtime | Use a custom runtime | Use a container image |
---|---|---|---|
Upper limit of code package size | 10 GB of original code | 10 GB of original code | 10 GB of uncompressed images |
Code package format | ZIP, JAR (Java), and folder | ZIP, JAR (Java), and folder | For more information, see What is Container Registry?. |
GPU-accelerated instances | Unsupported | Unsupported | Supported |
Runtime environments | Node.js, Python, PHP, Java,. NET Core and Go | Unlimited | Unlimited |