Hey, now I can talk about that project that we've been cooking for a while at @clever_cloud: a Function as a Service system based on Web Assembly applications running directly in a VM. No OS. Just raw communication with the hypervisor
Why Web Assembly ? It's a common format to run multiple languages, very few requirements to execute it, designed for sandboxing
See github.com/appcypher/awes… for the current list of languages targetting wasm
See github.com/appcypher/awes… for the current list of languages targetting wasm
Why in a virtual machine? While wasm is well sandboxed, it's a matter of time until someone finds an escape bug.OTOH a VM is a great security boundary and there are good hypervisors (we use KVM). It is much easier to control code running in a VM than code directly in your process
As a side note virtual machines are a huge part of our ADN at @clever_cloud . We do not run your applications in containers, we have always isolated them in virtual machines, booting a fresh one on each update.
We just made sure we're fast at starting them
We just made sure we're fast at starting them
The FaaS VM has no hardware: just a vCPU, some RAM, and that's it. No emulated device to hack. Just direct communication with the hypervisor through ports.
No OS either: load the code in memory, set the instruction pointer and start
No OS either: load the code in memory, set the instruction pointer and start
Yes, that's a unikernel!
But with a caveat: the API is a bit high level, no need to add device drivers or write raw TCP packets, there's a posix like interface (soon following WASI).
Applications are easier to write and we can provide useful high level features
But with a caveat: the API is a bit high level, no need to add device drivers or write raw TCP packets, there's a posix like interface (soon following WASI).
Applications are easier to write and we can provide useful high level features
That also means applications are very small. Most of them weight a few kilobytes. The biggest one yet was 6MB. And that's because it was embedding tract-core and 5MB of onnx model (yes it can run machine learning models).
Most apps need < 5MB of RAM
Most apps need < 5MB of RAM
In the end this runs fast:
- VM boot: 50-70ms (I'm expecting this to go down soon, and VMs are reusable between requests of a same app)
- function execution: 1-10ms
- total response time: 20-50ms without boot time (expecting this to go down too)
- VM boot: 50-70ms (I'm expecting this to go down soon, and VMs are reusable between requests of a same app)
- function execution: 1-10ms
- total response time: 20-50ms without boot time (expecting this to go down too)
It can run applications that answer to HTTP requests (booting the VM directly after parsing the request) or listens to a Pulsar topic.
I have example applications written in Rust (ofc that's the main wasm language), Assemblyscript, Kotlin, and I recently had fun with TinyGo
I have example applications written in Rust (ofc that's the main wasm language), Assemblyscript, Kotlin, and I recently had fun with TinyGo
Sadly, it is not publicly available yet, but we're working hard on it, because this system is just too fun to keep it to ourselves 😁
the slides of the talk are here:
