It's actually somewhat different. AWS Lambda is intended to act as your origin server. Generally your Lambda functions run in a small number of locations, not necessarily close to users.
Cloudflare Workers will run in all of Cloudflare's 117 (and growing) locations. The idea is that you'd put code in a worker if you need the code to run close to the user. You might want that to improve page load speed, or to reduce bandwidth costs (don't have to pay for the long haul), or because you want to augment Cloudflare's feature set, or a number of other reasons. But, generally, you would not host your whole service on this. (Well, you could, but it's not the intent.)
We haven't nailed down pricing yet, but we've worked hard to create the most efficient possible design so that we can make pricing attractive.
Can I use this together with CloudFlare streaming to open up stream ingestion based on some HMAC signed parameters?
To give regular end-user the rights to e.g. 'record one video of up to X seconds and Y mbps under ID "some-uuid"'
I've been waiting for a proper Content Ingestion Network for ages by now... if the CloudFlare video team ever wants to talk to someone who hand-rolled their own single-node version of this I'd be more than willing to share my experiences.
If you added this with RTMP+WebRTC ingestion support all of these [1] companies would probably jump on the opportunity... and dozens more would start up in that space ;-)
That is correct. However, the design is very different. Lambda@Edge is, from what I can tell, based on running a full Node.js process in a process-level sandbox for each customer, whereas we are embedding V8 directly.
What are you embedding v8 into exactly? What happens if I figure out a buffer overflow in v8? What do I break out into? Is it solely process isolation? Is it in a container? A VM?
> What happens if I figure out a buffer overflow in v8?
You report it to Google for $15,000. ;)
More seriously, though, this is something we've spent a huge amount of effort worrying about. There are many layers of sandboxing and mitigation, including an incredibly tight seccomp filter, namespaces, cgroups, ASLR, architectural changes to keep sensitive secrets away from risky processes, etc. But we still worry and will continue to add more safeguards.
Same as any other site setting, all of which need to be pushed to every location. We have existing infrastructure for this that propagates changes everywhere within a couple seconds.
Cloudflare Workers will run in all of Cloudflare's 117 (and growing) locations. The idea is that you'd put code in a worker if you need the code to run close to the user. You might want that to improve page load speed, or to reduce bandwidth costs (don't have to pay for the long haul), or because you want to augment Cloudflare's feature set, or a number of other reasons. But, generally, you would not host your whole service on this. (Well, you could, but it's not the intent.)
We haven't nailed down pricing yet, but we've worked hard to create the most efficient possible design so that we can make pricing attractive.