From the perspective of someone deciding between AWS Lambda and Fly Machines to run our customers’ untrusted code, what are some things to consider? What are some differences between the two? I’ve used Lambda extensively and functionality and cost wise they seem pretty similar.
How is the cold start compared to AWS Lambda, especially now that they’ve launched SnapStart, which should essentially get rid of cold starts (though it’s only available for Java at the moment)? Does Fly offer something similar? It seems to be the case, from reading the Run User Code on Fly Machines · Fly Docs section titled “Start an Existing Machine”.
We haven’t like scientifically benchmarked this, but in random observations, we have found that our NodeJS Machines start in 10ms to 600ms, with 100ms-200ms being the norm.
That one is a game-changer. For AWS.
Yes. Fly Machines are kind of SnapStarting already since the code / image is kept on the host ready-to-go (there’s no download code/image step on Fly). That said, Fly plans to improve upon their existing cold-starts by restoring from VM snapshots (aka doing SnapStart for real).
The major one is, on Fly, you have to explicitly exit the main process with exit code 0 or it keeps running.
The other thing it is early days for Fly Machines, they’re in-preview.
Things like flyctl support isn’t quite there yet (but there’s a nifty REST API at least).
Also, according to Fly docs (and in my experience too), Fly Proxy has trouble load-balancing when there are multiple VMs (of a single Machines app) running in the same region.
I’ve also had to deal with Zombie VMs, Ghost VMs, and Phantom VMs… It is quite something! (: I am sure Lambda has its share of quirks, too.
Is there an example for how to achieve a NodeJS start time of 10ms? In my testing, it takes Fly.io a minimum of 200ms (in addition to the ~200ms to start Firecracker) to execute node server.js even if all server.js contains is: