OCI Functions Concepts

Oracle Cloud Infrastructure users who use OCI Functions to create and deploy functions are referred to as 'functions developers'. To use OCI Functions, functions developers must have Oracle Cloud Infrastructure user accounts. Their user accounts must belong to groups to which appropriate policies grant access to function-related resources.

See Creating Groups and Users to use with OCI Functions, if they don't exist already.

In OCI Functions, an application is:

• a logical grouping of functions
• a way to allocate and configure resources for all functions in the application
• a common context to store configuration variables that are available to all functions in the application
• a way to ensure function runtime isolation

When you define an application in OCI Functions, you specify the subnets in which to run the functions in the application. You also specify whether to enable logging for the functions in the application.

When functions from different applications are invoked simultaneously, OCI Functions ensures these function executions are isolated from each other.

Best practice is to group multiple functions in a single application for better efficiency and performance.

OCI Functions shows applications and their functions in the Console.

See Creating Applications.

In OCI Functions, functions are:

• small but powerful blocks of code that generally do one simple thing
• grouped into applications
• created from either a container image or, for supported runtimes, an archive containing function code and dependencies
• invoked in response to a CLI command or signed HTTP request

When you create a function, you specify how to provide the function code. For image-based functions, you provide a container image. For code-only functions, you provide an archive that contains the function code and dependencies, and select a managed runtime.

A definition of the function is stored as metadata in the OCI Functions server. The definition describes how the function is to be executed and includes:

• the source used to run the function, such as the container image or archive source details
• the runtime configuration for a code-only function
• the maximum length of time the function is allowed to execute for
• the maximum amount of memory the function is allowed to consume

OCI Functions shows functions, and the applications into which they are grouped, in the Console.

For more information about creating functions from images, see Creating, Deploying, and Invoking an Image-Based Helloworld Function. For more information about creating functions from archives, see Creating Functions from Archives (Code-only Functions).

In OCI Functions, a function's code is run (or executed) when the function is called (or invoked). You can invoke a function that you've deployed to OCI Functions from:

• The Fn Project CLI.
• The Oracle Cloud Infrastructure SDKs.
• Signed HTTP requests to the function's invoke endpoint. Every function has an invoke endpoint.
• Other Oracle Cloud services (for example, triggered by an event in the Events service) or from external services.

When a function is invoked for the first time, OCI Functions prepares the execution environment for the function and executes the function code. For image-based functions, OCI Functions pulls the function's container image from the specified container registry. For code-only functions, OCI Functions uses the function archive and managed runtime to prepare the execution environment. If there are subsequent requests to the same function, OCI Functions can direct those requests to the same execution environment. After a period of being idle, the execution environment is removed.

OCI Functions shows information about function invocations in metric charts.

See Invoking Functions.

A trigger is the result of an action elsewhere in the system, that sends a request to invoke a function in OCI Functions. For example, an event in the Events service might cause a trigger to send a request to OCI Functions to invoke a function. Alternatively, a trigger might send regular requests to invoke a function on a defined, time-based schedule.

A function might not be associated with any triggers, or it can be associated with one or multiple triggers.