Hacker News Reader

Comment by afavour | Hacker News Reader

The author’s assertion isn’t correct though.

Yes, technically speaking a PHP script that isn’t being executed isn’t itself costing you money. But it’s stored on server that is running 24/7 and is costing you money.

Set up in the traditional way, CGI/PHP is priced by server uptime, be that per hour, per day, per month, whatever. The server runs all the time, it waits for requests, it processes them.

By contrast Lambda only costs money while your code runs. There’s a big difference there. Pricing of the two is different enough that a Lambda isn’t automatically cheaper but it’s misleading to suggest it’s just a CGI/PHP script. And we haven’t even started on the differences around scaling etc.

View on HN

There's nothing stopping anyone from implementing a cloud that runs CGI or FastCGI that scales down to zero (with per second billing), and scales up to infinity.

It's just that nobody has chosen to do so

Though I suppose not without reason. Google App Engine was one of the first "PaaS", billed on a fine-grained level, and it WAS initially based on CGI. Later they changed it to in-process WSGI, probably because working around CGI startup time is difficult / fiddly, and FastCGI has its own flaws and complexity.

I think it would have been better if they had developed some of the open standards like SCGI and FastCGI though. I think it could have made App Engine a more appealing product

Comments on Scripting, CGI, and FastCGI - https://www.oilshell.org/blog/2024/06/cgi.html

You have to consider that AWS Lambda does have "cold start" - if your code wasn't run for about 10 minutes it isn't "hot" anymore and will have a penalty time cost to its first next request. This is not billable but it is a latency, explained here [1]

[1] https://docs.aws.amazon.com/lambda/latest/operatorguide/exec...

Yes it's exactly like FastCGI ... if you make enough requests, then you have a warm process.

If you don't, then you may need to warm one up, and wait.

So yeah I think AWS Lambda and all "serverless" clouds should have been based on an open standard.

But TBH FastCGI is not perfect, as I note in my blog post.

The real problem is that doing standards is harder than not doing them. It's easier to write a proprietary system.

And people aren't incentivized to do that work anymore. (Or really they never were -- the Internet was funded by the US government, and the web came out of CERN ... not out of tech companies)

The best we can get is something like a big tightly-coupled Docker thing, and then Red Hat re-implements it with podman.

I think that Cloudflare Workers have been optimized to avoid the cold start problem far better than Amazon Lambda.

Do you know about them?

If that's an issue, use Cloudflare Workers instead: https://blog.cloudflare.com/eliminating-cold-starts-with-clo...

> scales down to zero (with per second billing)

> It's just that nobody has chosen to do so

If we're having fun with "everything old is new again", then I do remember some classic hosts for things like "Guestbook" perl CGI scripts would charge in those days per-"impression" (view/action), it's not quite CPU time but a close approximate you'd hope, and the associated costs would scale down to zero whether or not their hosting tech actually did. (Also, some of them certainly didn't scale to "infinity", though they tried.)

>There's nothing stopping anyone from implementing a cloud that runs CGI or FastCGI that scales down to zero (with per second billing), and scales up to infinity. >It's just that nobody has chosen to do so

i suspect they have. i'm sure there's a ton of different in-house implementations out there at various enterprises, that are a minimal wrapper on aws lambda to turn an ALB request into a CGI request

> There's nothing stopping anyone from implementing a cloud that runs CGI or FastCGI that scales down to zero (with per second billing), and scales up to infinity. It's just that nobody has chosen to do so

I think in discussions like this it's often helpful to think of Lambda not as a technology but as a product. Lambda isn't "CGI with extra steps", it's "CGI with per second billing", which is a rarer offering.

So it's like code-only shared hosting, billed by CPU-time rather than wall-time, and with a load balancer in front.

And it scales to multiple servers to accommodate traffic without your input. But essentially, yes.

Not to sound uncharitable but I’m confused by statements like the OPs who profess to not understanding what Lambda is… it’s not actually that complex!

Didn't know enough about it to know whether I should care enough about it to investigate more.

And mind the opportunity cost: You never learn how to set such a thing up yourself; and AWS runs off to the bank. Where you could have had an asset, (frequently a good idea), that you can do something with.

Remember, the innovation of cloud was to add a payment, IAM, and config layer on top of basic compute tasks.

> By contrast Lambda only costs money while your code runs.

There is no fee for uploading it, only a fee for executing? In that case could I upload a function that only disgorges a static payload? Then I could store a multi-GB file for free and just invoke it in order to download the data.

You still get charged for data / bandwidth egress, of course. Either way, that multi-gig response wouldn't work. You'd discover lambda can only generate a 6 megabyte response!

Lambda has all sorts of weird limitations: https://repost.aws/questions/QUjXEef9ezTTKpWqKRGk7FSg/limita...

I believe there is no usage fee for uploading functions, but there’s a size limit per function and an account-wide total storage quota on uploaded functions.

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

Reply on news.ycombinator.com