Execution of scheduled jobs based on a time schedule is a frequent requirement. Jobs on Oracle Cloud Infrastructure are often implemented using cloud native, serverless Functions – that can be exposed through (public) HTTP endpoints on an API Gateway. I recently published an article describing how execution of functions can be scheduled using IFTTT. This works fine. However, there is a much better way – that is finer grained, easier to monitor and completely cloud native on Oracle Cloud Infrastructure.
Using the OCI Monitoring Service we can create Healthchecks that consist of periodic ping or HTTP calls. We can configure a Healthcheck that periodically invokes an endpoint on a public API Gateway with a Function as its backend. In this way we can easily schedule a function to be executed every X seconds | minutes | hours | days. The following figure describes this setup.
The hello function shown in this figure was created in an earlier article; it is implemented in Node and does not do anything useful. There are no requirements on the backend function that we want to schedule the execution of.
The steps we go through:
- define a Health Check in OCI Monitoring for the API Gateway endpoint & route for the Function we want to schedule
- (check that the function is now periodically triggered)
Note: the Health Check does not allow us to pass a body to the function; HTTP headers can be specified.
To create a Health Check, go to Monitoring | Health Checks:
Click on Create Health Check:
Configure the Health Check – using the API Gateway endpoint and the [URL] path on APU Gateway to the function to be triggered. Indicate how often the health should be checked; this corresponds with the frequency of triggering the function.
The health check shown here fires every 60 seconds; it then makes a GET call (HEAD is the other option) over HTTPS to the API Gateway’s endpoint at the path /fn/hello – which leads to the functin hello. No headers are included in the request.
Save the new Health Check Configuration. It should now immediately be activated.
After a few minutes, the console shows the following details for the Health Check – evidence it has (successfully) been executed:
The detailed metrics after 45 minutes give some insight in the latency on the calls to the function. I expect the peaks to be caused by the function going cold after a little while, causing a much longer response time when invoked after the cold restart.
I probably should investigate this in more detail.
On the function side, we can see in the metrics that the function is regularly executed, about once a minute.
Using a Health Check – together with an API Gateway – seems a fairly elegant way of scheduling function execution. Oracle is likely to provide scheduling as a cloud native function in the near future, but until then, this seems a workable alternative.
When I try this setup I cannot select the API GW endpoint, it shows the public IP. When using the ip the health check fails with the message “errorMessage”: “x509: cannot validate certificate for XXX.XXX.XXX.XXX because it doesn’t contain any IP SANs”,