watchcat

watchcat

May also go by "funky" (or whatever else).

A tiny HTTP proxy acting as the main process for base-images.

It's responsibilities are going to be:

• managing the function runtime server(s)
• parsing of invocation requests and responses
• timeouts / deadlines
• health checks
• capturing logs

Managing the function runtime server(s)

The proxy should keep a pool of function runtime servers (as many as configured in SERVERS env var). Each of those servers will run no more than one invocation at a time. Also, only healthy function-servers (see below) should receive invocations. This means, concurrent invocations should be throttled to the number of available function-servers.

FaaSs differ in handling invocations. Riff will only need SERVERS=1. OpenFaaS and Kubeless will need more than that (they like to think concurrency is good).

Parsing of invocation requests and responses

Dispatch function invocation requests and responses have a particular structure: they are JSON messages having payload (any JSON-encodable value) and context fields (a JSON-object with known fields, like secrets, deadline, etc)

Invocations should only get to actually run on the real function server if they satisfy certain pre-conditions, like:

• the JSON message is well formed and has all necessary fields,
• the deadline hasn't passed,
• etc...

Timeouts / deadlines

One of the fields in the context is going to be deadline, which is an absolute timestamp by which the invocation should have completed, either successfully or not.

The proxy should pass the invocation to the function server (if the deadline hasn't expired) and wait for response until the deadline, then respond with appropriate error status (FunctionError - if the function hasn't completed before deadline).

If an ongoing invocation hasn't met the deadline, the proxy would kill the function-server process and spawn a new one instead.

Health checks

The proxy should expose a health check endpoint (/healthz)

The proxy is healthy if it has at least one healthy function-server process. This means, the proxy should check the health status of its function-servers. These should respond to health checks within milliseconds.

Capturing logs

Function implementations will log to stdout/stderr, and function servers will NOT redirect or capture these streams (just print directly to stdout/stderr). Now, because invocations run in function-servers one at a time, it is possible for our proxy to capture those streams for individual invocations and wrap them into the response context.logs.