FAAS implementation considerations

[smoke]

This project is great!
I imagine it can be used to implement a lightweight FAAS (Function As A Service) oriented setup,
it provides a lot out of the box,
however there are other concerns, that need to be covered for a production grade FAAS oriented setup.

Such point is only mention, but not ellaborated in FAQ docs:

• How is this project similar or different from Knative
• How is this project similar or different from OpenFaaS

Available already

1. Have a Function (NodeJS, Python, etc.) wrapped in a lightweight HTTP server / Controller running in the POD / Container of the Function, allowing it to be invoked via HTTP, e.g. using:
   • https://hub.docker.com/r/amazon/aws-lambda-nodejs
   • https://hub.docker.com/r/amazon/aws-lambda-python
   • or a custom implementation based on https://github.com/aws/aws-lambda-nodejs-runtime-interface-client
   • or other
2. Using https://github.com/kedacore/http-add-on wire the Function to be Invoked via HTTP request, allowing it to scale from 0 to what is needed

All of the above covers a basic setup.

What is missing

In order of importance:

1. Async Invocations - essentially instead of HTTP request that awaits response, to allow request to be accepted, put in a queue (memory / external) and executed in a background
2. Resource limits - in many Serverless implementations (e.g. AWS Lambda) - there are strict Resource limits (CPU, Memory, Storage), there is as well Execution Time limit of up-to 15 min
3. Resilience and Error handling - in many Serverless implementations there are automatic retries to certain limits, also async invocations are queued and retried as well, in case of crashes / resource limits exhaustion there is certain recovery
4. Triggers - in many Serverless implementations there are Scheduled or external event source triggers
5. Recursive loop detection
6. Standardized API working with the FAAS
7. NodeJS, Python, etc. SDKs allowing invoking the FAAS through the Standardized API

[smoke]

Regarding 1. Async Invocations I am thinking of couple of options to implement:

A. Option - using http-add-on with added feature to support async / background invocations, like that

• a request with given header e.g. x-async-invocation: true is sent
• http-add-on responds HTTP 202 Accepted and queues in internal (memory) the request
• once the upstream service is available, execute it and swallow the response

PROS:

• easy to implement
• less components and integration

CONS:

• Limited Resilience and Error handling available, no fail-over / crash survival
• occupies http-add-on with yet another responsibility

B. Option - using same like A, however implemented within the the HTTP server / Controller running in the POD / Container or worst case in the Function

PROS:

• easy to implement
• less components and integration
• offloads http-add-on
• requires no http-add-on changes

CONS:

• Limited Resilience and Error handling available, no fail-over / crash survival
• occupies the function or function Controller with yet another responsibility
• introduces lag - the function needs to be scaled to accept the work, that could be time consuming

C. Option - using external subsystem like https://docs.bullmq.io/ or others - essentially re-route http requests with x-async-invocation: true to another service in NodeJS that queues the request in redis, then a worker picks that and invokes the function through regular path swallowing the response

PROS:

• offloads http-add-on
• requires no http-add-on changes
• requires no function or function Controller changes
• extended Resilience and Error handling available, fail-over / crash survival
• less / no lag

CONS:

• a bit more difficult to implement
• more components and integration

D. Option similar to C. Option - however using https://github.com/fission/keda-connectors