Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The demise of the mildly dynamic website (2022)

devever.net

Post reply on HN
Print view View original

51–60 of 183 posts

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

#51

Post by afavour »

chubot wrote: post #47
untech wrote: 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.

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 p…

This maybe gets to the core of why the author’s assertion is incorrect: they’re comparing a programming language to an execution environment.

Yeah, PHP can scale infinitely… if you provide it with the necessary server resources to do so. PHP is not going to scale infinitely on a Raspberry Pi.

This dynamically scaling server resource is Lambda. Hell, you can even run PHP on Lambda these days the comparison really doesn’t work.

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

#52

Post by chubot »

decasia wrote: 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…

The thing is — if you are running this setup on your own linux virtual machine — it requires endless system maintenance.

Yeah, this is exactly what I talk about this post -- why do I used shared hosting?

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

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

#54

Post by morkalork »

pram wrote: post #45
jimbokun wrote: post #32

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.

I can definitely see lambdas being abused when the process for requesting dedicated resources is too arduous.

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

#55

Post by jjk166 »

throwaway22032 wrote: post #33
jimbokun wrote: post #32

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…

Basically everything AWS is things we already have but more expensive because someone else does the easiest bit for you.

Some people don't want to create a universe every time they want an omelet.

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

#56

Post by jbmchuck »

pram wrote: post #45
jimbokun wrote: post #32

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.

https://docs.aws.amazon.com/prescriptive-guidance/latest/pat...

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

#57

Post by fernandopj »

chubot wrote: post #50
afavour wrote: post #35

Earlier quoted context omitted.

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 workin…

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...

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

#59

Post by WorldMaker »

chubot wrote: post #50
afavour wrote: post #35

Earlier quoted context omitted.

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 workin…

> 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.)

Post reply on HN