Minimise / eradicate initial FN spin up delay for OCI API GW authorisation

Question

We are using an FN Function for OCI API Gateway authorisation (https://docs.cloud.oracle.com/en-us/iaas/Content/APIGateway/Tasks/apigatewayusingauthorizerfunction.htm). We're finding that there is a slight delay in the auth process when it hasn't been triggered for a while as an instance of the Function container spins up, which is expected. As the Oracle documentation states :

When the function has finished executing and after a period being idle, the Docker container is removed. If Oracle Functions receives another call to the same function before the container is removed, the second request is routed to the same running container. If Oracle Functions receives a call to a function that is currently executing inside a running container, Oracle Functions scales horizontally to serve both incoming requests and a second Docker container is started. (https://docs.cloud.oracle.com/en-us/iaas/Content/Functions/Concepts/functionshowitworks.htm)

We would like to minimise or ideally eradicate this initial delay, for instance by keeping one instance of the Function running all the time. What would be the best approach?

Answer 1

I doubt if you could keep the FN Container hot without repeatedly invoking it at the first place. One of the daft options could be to keep calling it after every "sleep" interval; but this has to be traded-off with associated FN Invoking cost/month.

Other options could be based on how long the actual operation runs for. For instance, this could be split into the two Operations represented by two FNs. A FN can call another FN; so you should be able to sequence invoking them one by one if that is achievable for your intended task.

Answer 2

That is known in serverless as the "cold start" and it is something that is being worked on to reduce the initial startup time. Until then a health-check can be used to periodically ping the function.

Essentially create a case in the function where the URL ends in something like /status or /healthcheck. In that case return response.Response(ctx,response_data=json.dumps({"status": "OK"}), headers={"Content-Type": "application/json"})

In API Gateway, create a route making sure to enable anonymous for /status (or /healthcheck) that invokes the function.

Then set up a health check to periodically invoke the API with the /status or /healthcheck end-point. This both keeps the function active and also monitors the health. Your case could perform any needed validation rather than just returning an OK response.

Another thing to keep in mind is API Gateway will cache responses, so depending on your chosen TTL you can adjust your healthcheck timing accordingly.

Answer 3

This 'hot start' requirement is now covered by Oracle Cloud's "Provisioned Concurrency" feature for Functions:

https://docs.oracle.com/en-us/iaas/Content/Functions/Tasks/functionsusingprovisionedconcurrency.htm

From the documentation:

Provisioned concurrency is the ability of OCI Functions to always have available the execution infrastructure for at least a certain minimum number of concurrent function invocations.