Integration with OpenFaaS

OpenFaaS^[58] (Open Functions as a Service) takes a different approach to cloud functions. Where the major cloud providers implement all of the underlying infrastructure for you, OpenFaaS expects you to have that infrastructure available (which could still be AWS, GCP, Azure, etc).

There could be full books written about OpenFaaS as well, so I will try and keep my explanation brief. Unlike the other cloud providers which have different runtimes for each language, OpenFaaS has a single runtime for all functions—docker and the deployed OpenFaas components.

In OpenFaaS, your function is a compiled binary inside a docker image. This docker image also contains a watchdog process that acts as a proxy between the OpenFaaS gateway and your function. It routes incoming requests for function invocations to your process. The classic gateway communication mode is about as simple as it gets: the request payload is conveyed to your process via stdin and your response is delivered via stdout. There’s also a newer watchdog type^[59] that’s faster and uses HTTP.

So while your function process is just a simple binary, OpenFaaS takes care of waking it up and invoking it on demand and deals with the complexities of trying to keep it “warm,” and so on. You could also use a WebAssembly module here. All you’d need is a host process (e.g. a Rust application) that conformed to any of the OpenFaaS watchdog requirements and you could quickly turn your WebAssembly module into a function that could be launched on-demand in a Kubernetes cluster hosted wherever you like.

In this scenario, you could also reap the benefits of knowing the WebAssembly module could never do anything to harm your cluster or OpenFaaS, because the host is in complete control of what the module can and cannot do. You can even verify that the module was deployed by the right people or services—the subject of this book’s second appendix.