[darsoli]

This post seems to go into more detail on the technical architecture.

I've read a lot of these style posts, and oftentimes the results don't end up being that interesting - but I have to say this post is different. Nice job and good overview of all the different layers in the stack. I didn't realize there was a meaningful difference between Cloudflare Workers and Lambda, but now will have to check it out.

[nicoburns]

Indeed Cloudflare Workers have much lower latency, and much much quicker cold starts (to the point that you probably won't notice them). IMO this makes them much more useful for typical web APIs than lambda.

[ignoramous]

Workers and cold-starts? If you count 0ms as coldstarts, then sure.

Also, Workers supports HTTP3 (QUIC) and ESNI already.

https://twitter.com/eastdakota/status/1288855462931177472

[jariel]

My understanding is that 'when hot' AWS Lambdas are pretty quick, and so long as there is basically any traffic, the remain hot? Do you have any details?

[nicoburns]

There are also cold starts every time the number of concurrent requests increases. Also: lambdas are only really useful for the low-to-no traffic situation. If you have constant traffic you're better off using a small VM.

[jariel]

"Also: lambdas are only really useful for the low-to-no traffic situation. If you have constant traffic you're better off using a small VM."

I don't understand this.

The entire point of Lambda's is to offload the overhead and complexity of managing severs - and - to allow for large occasional spikes in traffic.

Even with the limitation of '5 second warmup per concurrent' Lambda - that's not a big deal. It means maybe 100-200 users have to wait a few seconds while 100-200 Lambdas warm up - and with 1.5 user spike ... you really don't know what you're going to get, but with Lambda's at least you're pretty much guaranteed it will work.

For cost efficiency, with stable tech, stable/predictable traffic, and enough scale that you have the right team to be able to manage your EC2's properly - yes that makes sense. But you need some scale to get to that point wherein that cost efficiency is worth it given that Lambda's 'just work' fairly well fairly easily.

But I definitely could be missing something.

[vp8989]

I believe what is being implied is that because Cloudflare Workers operate inside of a much lighter construct, they are able to burst to higher concurrency inside of shorter time windows. Lambda can burst to 3000 and then an additional 500 more per minute after that.

https://docs.aws.amazon.com/lambda/latest/dg/invocation-scal...

Based on the scale mentioned in the article (hundreds of RPS) it's likely Lambda would also have been able to handle it just fine.

On another note, using non-provisioned infrastructure (aka "serverless") for an expected bursty load (TV campaign) is bordering on negligence. It sounds like lots of potential donations were missed because the Stripe account was not set up to cope with the load. It turned out to be a wash because Stripe donated 100k but if you change the business context of this system from "receiving donations" to "taking credit card payments" ... this outcome would not be considered acceptable.

[jariel]

Thanks, I see more details on how Cloudflare may be more performant than Lambda.

But why is running a bursty tv load on serverless negligent?

"the Stripe account was not set up to cope with the load." - I've used Stripe and I don't know what this means. I don't see any 'product' limitations towards accepting many payments, that said, they could have some internal financial controls which should have been accommodated by calling ahead and letting them know about the burst.

And how would there be a technical limit with Stripe? If payment processing was directed to Stripe.com - surely they can handle the traffic.