[Ros2]

I just started using cron to keep my cloud functions warm at a cost of pennies per month. It feels like a strange ceremony to let more knowledgeable people game the system. Even figuring out the time that your functions go 'cold' is a secret handshake you can't find in proper documentation.

I'm curious what's going to happen when everyone else does this too. It goes without saying this isn't the intended use for the price they've set and it's also apparent that >75% of customers will, likely, choose to make this performance optimization before going to production or after complaints of bad latency.

Also it is a bit scary that even with keeping a single server warm, you still pay the cold startup penalty on subsequent scale-ups. Afaik, no cloud provider has claimed to have 'solved' this (yet more secrecy in how the platform is managed)

[k__]

"using cron to keep my cloud functions warm at a cost of pennies per month"

"you still pay the cold startup penalty on subsequent scale-ups"

That's probably why they don't care.

You just keep one warm AND you pay for it.

If you don't have parallel requests this is a good thing for you, bot everyone else doesn't have much gain from only having one hot instance.

On the other hand you can probably get around this with UI tricks when facing and end user. Native apps are installed anyway and web apps will be delivered via S3/CloudFront etc.

[heavenlyblue]

I don't see why they could not implement a pricing strategy to pay for the RAM used by keeping the lambda hot.

After all this is just keeping it "loaded in memory".

[wahnfrieden]

It'd be a regressive concession misaligned with the goals of serverless - a return to peak capacity planning. How many containers do you keep warm? Might as well just use traditional non-serverless platforms at that point.