This is awesome! I'm working on a project that will heavily utilize FaaS and I've explored many options. Your combination of "secure and configure via workerd" with "autoscale and orchestrate with fly.io" is really great!
I know it's a POC but just some of my thought's / questions to see if you have any ideas or opinions on them:
- I briefly browsed workerd repo and it doesn't seem like there's an api to load a new worker script file to the existing workerd instance. Which is, i'm guessing, one reason why you're just restarting the whole fly machine to re-fetch the latest zipped resources at boot.
- workerd repo mentions it's currently single-threaded
- i'm wondering how fast workerd itself boots?
- due to ^ those three points I'm wondering if a nice design would be:
- publisher & worker use bullmq and it's sandbox-worker to spawn child process workers running workerd (helps utilize more threads & the bullmq worker code can take the job data input which contains the new user script to bootstrap config at job run). This would be good IF workerd boots fast..
- if workerd doesn't boot fast, and eventually you have many user scripts i can't see any other option than to have a third server that acts as a load-balancer/orchestrator. It would keep state of user scripts and which worker fly machines have told it it can run that script. Could still use a "buffer worker machine" which can "cold-boot" newly published scripts using the bullmq method i mentioned above.
Anyway, this is all really cool just wanted to spitball some ideas!
Basically, I think that rolling restarts of the worker instances, just does the trick in the easiest way. Mind that flymachine instances, are pretty quick to boot. While an instance is restarting, others still serve requests so the system is still up.
Hi, this is more an experiment that a real production-tested project. You can create your own Function as a Service architecture, and self-host everywhere you want.
It leverages workerd, the Cloudflare worker runtime. And as deploy tutorial, it include a guide to host everything on Fly.
It support container-based deployment, so docker is your friend here.
jamesmcintyre|2 years ago
I know it's a POC but just some of my thought's / questions to see if you have any ideas or opinions on them:
- I briefly browsed workerd repo and it doesn't seem like there's an api to load a new worker script file to the existing workerd instance. Which is, i'm guessing, one reason why you're just restarting the whole fly machine to re-fetch the latest zipped resources at boot. - workerd repo mentions it's currently single-threaded - i'm wondering how fast workerd itself boots? - due to ^ those three points I'm wondering if a nice design would be: - publisher & worker use bullmq and it's sandbox-worker to spawn child process workers running workerd (helps utilize more threads & the bullmq worker code can take the job data input which contains the new user script to bootstrap config at job run). This would be good IF workerd boots fast.. - if workerd doesn't boot fast, and eventually you have many user scripts i can't see any other option than to have a third server that acts as a load-balancer/orchestrator. It would keep state of user scripts and which worker fly machines have told it it can run that script. Could still use a "buffer worker machine" which can "cold-boot" newly published scripts using the bullmq method i mentioned above.
Anyway, this is all really cool just wanted to spitball some ideas!
giuseppelt|2 years ago
Basically, I think that rolling restarts of the worker instances, just does the trick in the easiest way. Mind that flymachine instances, are pretty quick to boot. While an instance is restarting, others still serve requests so the system is still up.
giuseppelt|2 years ago
It leverages workerd, the Cloudflare worker runtime. And as deploy tutorial, it include a guide to host everything on Fly.
It support container-based deployment, so docker is your friend here.
The complete project is on: https://github.com/giuseppelt/self-workerd
Mind this a proof-of-concept, public exposed systems require more work.
prakis|2 years ago
giuseppelt|2 years ago