Live data from Hacker News

The demise of the mildly dynamic website (2022)

devever.net

41–50 of 183 posts

Re: The demise of the mildly dynamic website (2022)

#41
post #36

I sometimes wonder what the hell AWS Lambda is and whether or not I should care. Now I have a succint answer: > What captured people's imaginations about AWS Lambda is that it lets you a) give any piece of code an URL, and b) that code doesn't consume resources when it's not being used. Yet these are also exactly the attributes possessed by PHP or CGI scripts. From now on, when anyone mentions "AWS Lambda" I'm going…

I understand the sentiment, but to be fair, CGI doesn’t give you an infinite scalability. AWS Labmda based solution is far less susceptible to something like HN hug-of-death.

But it’s entirely susceptible to your wallet being hugged to death if someone decides to ddos you.

Re: The demise of the mildly dynamic website (2022)

#42
post #36

I sometimes wonder what the hell AWS Lambda is and whether or not I should care. Now I have a succint answer: > What captured people's imaginations about AWS Lambda is that it lets you a) give any piece of code an URL, and b) that code doesn't consume resources when it's not being used. Yet these are also exactly the attributes possessed by PHP or CGI scripts. From now on, when anyone mentions "AWS Lambda" I'm going…

I understand the sentiment, but to be fair, CGI doesn’t give you an infinite scalability. AWS Labmda based solution is far less susceptible to something like HN hug-of-death.

Instead your wallet gets ddos'd.

Re: The demise of the mildly dynamic website (2022)

#43
post #14

I think the spirit of this article is correct, although some of the digs at modern web tech and SPAs seem to be beside the point. I used to have a "mildly dynamic website." It was a $5 digital ocean box. It ran nginx with php-fpm, mostly so it could have a Wordpress install in a subdirectory, and it had a unicorn setup for an experimental Rails app somewhere in there. Given that environment, the "mildly dynamic websi…

Shared hosting is probably better, and AFAIK more common, for the mildly dynamic website. The host handles a lot of the admin tasks like OS updates that you have to handle yourself with a VPS.

NearlyFreeSpeech.NET is good for this. Their main tier - "production" sites - are very inexpensive and the admins take care of OS and server-software updates. They have another tier - "non-production" sites - that are even cheaper and can be perfectly sufficient for a personal homepage. The admins maintain these servers as well but they might do beta testing on them.

The environment is fully hackable and has PHP, SSH, SFTP, MariaDB, dominant languages like Perl and Python, obscure languages like Haskell and Lisp, etc etc.

Re: The demise of the mildly dynamic website (2022)

#44
post #36

Earlier quoted context omitted.

I understand the sentiment, but to be fair, CGI doesn’t give you an infinite scalability. AWS Labmda based solution is far less susceptible to something like HN hug-of-death.

But it’s entirely susceptible to your wallet being hugged to death if someone decides to ddos you.

That’s a trade off many businesses are very happy to make! Spike in traffic = spike in sales. For an actual DDOS there’s always WAF firewalling.

I have to admit I don’t get the lambda hate. You don’t have to use them but there is a valid use case for them.

Re: The demise of the mildly dynamic website (2022)

#45

I sometimes wonder what the hell AWS Lambda is and whether or not I should care. Now I have a succint answer: > What captured people's imaginations about AWS Lambda is that it lets you a) give any piece of code an URL, and b) that code doesn't consume resources when it's not being used. Yet these are also exactly the attributes possessed by PHP or CGI scripts. From now on, when anyone mentions "AWS Lambda" I'm going…

Lambda has its places, but I've noticed devs consistently using it for things where it doesn't make any goddamn sense. Like processing messages from a Kafka consumer, the function is running 24/7. People think it's a container or something.

Re: The demise of the mildly dynamic website (2022)

#46
post #45

I sometimes wonder what the hell AWS Lambda is and whether or not I should care. Now I have a succint answer: > What captured people's imaginations about AWS Lambda is that it lets you a) give any piece of code an URL, and b) that code doesn't consume resources when it's not being used. Yet these are also exactly the attributes possessed by PHP or CGI scripts. From now on, when anyone mentions "AWS Lambda" I'm going…

Lambda has its places, but I've noticed devs consistently using it for things where it doesn't make any goddamn sense. Like processing messages from a Kafka consumer, the function is running 24/7. People think it's a container or something.

News at eleven: devs use tech for utterly inappropriate purposes just because it happens to be cool at the moment.

Re: The demise of the mildly dynamic website (2022)

#47
post #36

I sometimes wonder what the hell AWS Lambda is and whether or not I should care. Now I have a succint answer: > What captured people's imaginations about AWS Lambda is that it lets you a) give any piece of code an URL, and b) that code doesn't consume resources when it's not being used. Yet these are also exactly the attributes possessed by PHP or CGI scripts. From now on, when anyone mentions "AWS Lambda" I'm going…

I understand the sentiment, but to be fair, CGI doesn’t give you an infinite scalability. AWS Labmda based solution is far less susceptible to something like HN hug-of-death.

CGI can definitely scale infinitely!! It's stateless.

PHP can scale to all of Facebook's front ends, and so can CGI. Because they are stateless.

Same with FastCGI. FastCGI just lets you reuse the process, so you don't have the "cold start" every time

> CGI had the original "cold start problem"

It's just that nobody has implemented a cloud that uses the CGI or FastCGI interfaces.

I quoted this same article in a blog post yesterday:

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

Re: The demise of the mildly dynamic website (2022)

#49

> What captured people's imaginations about AWS Lambda is that it lets you a) give any piece of code an URL, and b) that code doesn't consume resources when it's not being used. Yet these are also exactly the attributes possessed by PHP or CGI scripts. In fact, it's far easier for me to write a PHP script and rsync it to a web server of mine than for me to figure out the extensive and complex tooling for creating, ma…

Running PHP on a VM in a data center doesn’t cost you anything either while the VM isn’t doing stuff, and you still have something to ssh into and manage and investigate without layers of abstraction bolted on top. And PHP-on-httpd is pretty much one of the most newcomer-friendly straight-to-coding environments ever developed.

Re: The demise of the mildly dynamic website (2022)

#50
post #35

I sometimes wonder what the hell AWS Lambda is and whether or not I should care. Now I have a succint answer: > What captured people's imaginations about AWS Lambda is that it lets you a) give any piece of code an URL, and b) that code doesn't consume resources when it's not being used. Yet these are also exactly the attributes possessed by PHP or CGI scripts. From now on, when anyone mentions "AWS Lambda" I'm going…

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…

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

Post reply on HN