Netlify functions are based on AWS lambda functions, which spin up a container with say a node.js runtime environment everytime a request (or another event) comes in, then executes the user provided node.js function within the runtime. I can imagine that handy for something like cronjobs or api requests which happen occasionally.
But using Netlify functions for things like Next.js SSR (or API routes) means, that for every single website request, a new container is setup, the function is run once, and the container is discarded. Am i right in this? Isn't that a huge overhead in contrast to a long running server process?
This is a good summary. Edge Functions bring another set of trade-offs into the mix:
- Startup-time so fast that if you hit a "cold start" it is still fast enough from a human perception (often <30ms attributable to startup)
- Global by default
- Cheaper on a per invocation
- No limits on concurrent invocations
BUT
- Restricted API set, no node.js API support like Buffers or filesystem access
- Smaller max binary size
- Lower available CPU quota per request
- Lower max RAM usage
- Lower CPU-
Users do get conufused about the CPU quota thing. They compare the 10ms or so that you get with edge functions, vs 10 seconds on lambda and think it's loads worse, without realising they're comparing apples and oranges. Both Cloudflare and Deno Deploy are limiting CPU time, whereas Lambdas are limited on wall clock time. I've had no trouble keeping long-running Deno Deploy functions running for far longer than a Lambda could run, e.g. when using Server-Sent Events or passing-through a large file download. As long as they're blocking on IO rather than CPU then you're fine. As long as you're not doing something like trying to process images, you're much more likely to hit a 10s lambda timeout than a 10ms CLoudflare or Deno limit.
There's also a way to "provision"[2] resources to ensure that the function always stays warm, but that adds to the fixed cost, which is otherwise, near zero, if there are no requests.
[1]: https://aws.amazon.com/blogs/compute/operating-lambda-perfor... [2]: https://aws.amazon.com/blogs/aws/new-provisioned-concurrency...
It's generally just a better fit for this model, which is why I'm so glad to see the approach becoming more popular and am genuinely please that Vercel's offering has gone GA. The more this model of edge computing spreads, the better. More framworks will add support, and it will be a virtuous cycle. The WinterCG work on creating a common standard for these runtimes is also a great project.
> More framworks will add support, and it will be a virtuous cycle.
I'm in the early phase of developing a SSG in (TypeScript) Node currently. I think i'll study isolates and Deno a bit more, before going further. :)
Containers were clearly the safer bet when FaaS options hit the scene 6-8 years ago. Now with WASM opening up possibilities, Cloudflare made the smart move to base their edge compute off isolates, given the significantly reduced overhead.
Will be fun to see how the cloud competition responds!