distributed systems of native-cloud like functions that have a lot of benefit like

Resiliency and availability

Resiliency and availability refers to the ability of asystem to continue operating, despite the failure or sub-optimal performance of some of its components.

In the case of Oracle Functions:

The control plane is a set of components that manages function definitions.

The data plane is a set of components thatexecutes functions in response to invocation requests.

For resiliency and high availability, both the control plane and data plane components are distributed across different availability domains and fault domains in a region. If one of the domains ceasesto be available, the components in the remaining domains take over to ensure that function definition management and execution are not disrupted.

When functions are invoked, they run in the subnets specified for the application to which the functions belong. For resiliency and high availability, best practice is to specify a regional subnet for an application (or alternatively, multiple AD-specific subnets in different availability domains). If an availability domain specified for an application ceases to be available, Oracle Functions runs functions in an alternative availability domain.

Concurrency and Scalability

Concurrency refers to the ability of a system to run multiple operations in parallel using shared resources. Scalability refers to the ability of the system to scale capacity (both up and down) to meet demand.

In the case of Functions, when a function is invoked for the first time, the function's image is run as a container on an instance in a subnet associated with the application to which thefunction belongs. When the function is executing inside the container, the function can read from and write to other shared resources and services running in the same subnet (for example, Database as a Service). The function can also read from and write toother shared resources (for example, Object Storage), and other Oracle Cloud Services.

If Oracle Functions receives multiple calls to a function that is currently executing inside a running container, Oracle Functions automatically and seamlessly scales horizontally to serve all the incoming requests. Oracle Functions starts multiple Docker containers, up to the limit specified for your tenancy. The default limit is 30 GB of RAM reserved for function execution per availability domain, although you can request an increase to this limit. Provided the limit is not exceeded, there is no difference in response time (latency) between functions executing on the different containers.

Adding Request Policies and Response Policies to API Deployment Specifications:

You can control thebehavior of an API deployment you create on an API gateway by adding request and response policies to the API deployment specification:

a request policy describes actions to be performed on an incoming request from a caller before it is sent to a back end

a response policy describes actions to be performed on a response returned from a back end before it is sent to a caller

You can use request policies to:

limit the number of requests sent to back-end services

enable CORS (Cross-Origin Resource Sharing) support

provide authentication and authorization

You can add request and response policies that apply globally to all routes in an API deployment specification, and also (in some cases) request and response policies that apply only to particular routes.

Notethe following:

No response policies are currently available.

API Gateway request policies and response policies are different to IAM policies, which control access to Oracle Cloud Infrastructure resources.

You can add request and response policies to anAPI deployment specification by:

using the Console

editing a JSON file

References:

ateway/Tasks/apigatewayaddingrequestpolicies.htm

Authorization Header

The Oracle Cloud Infrastructure signature uses the "Signature" Authentication scheme (with an Authorization header), and not the Signature HTTP header.

Required Credentials and OCIDs

You need an API signing key in the correct format. See Required Keys and OCIDs.

You also need the OCIDs for your tenancy and user. See Where to Get the Tenancy's OCID and User's OCID.

Summary of Signing Steps

In general, these are the steps required to sign a request:

Form the HTTPS request (SSL protocol TLS 1.2 is required).

Create the signingstring, which is based on parts of the request.

Create the signature from the signing string, using your private key and the RSA-SHA256 algorithm.

Add the resulting signature and other required information to the Authorization header in the request.

References: