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

61–70 of 183 posts

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

#61

Post by chubot »

fernandopj wrote: post #57
chubot wrote: post #50

Earlier quoted context omitted.

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

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.

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

#62

Post by derefr »

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 is also distributed, though — while CGI scripts just live on the webserver itself. So if you're old like me and want a crisper mental model, the actual '90s equivalent of Lambda would be:

• a cluster of "diskless" web-server (let's say Apache) machines with a round-robin load-balancer in front of them;

• where these web servers are all using mod_userdir, pointing /~*/ at, let's say, "/wwwhome/*/www/" — and with `Options +ExecCGI` enabled for all UserDirs;

• where /wwwhome on all these web-server machines is a read-only NFS mount from the /home dir of a shared disk server;

• and where each user of this service has an FTP-enabled user and home directory on the disk server.

Given this setup, if a user bob FTPs a script to /home/bob/www/foo.pl on the disk server, then anyone can trigger that script to execute on some arbitrary web-server in the cluster by hitting http://lb.oldschool-lambda.example.com/~bob/foo.pl.

(I'm actually curious whether this exact architecture was ever implemented in the 1990s in practice, maybe by a university or ISP. It seems totally feasible.)

---

One other major difference I should point out, is that Lambda functions are versioned — you don't overwrite a function, you just deploy a new content-hash-named copy of it and then update some "symbolic names" to point at it, but can always call a fixed version by its content-hash.

Implementing enforced versioning wouldn't require any changes to the above architecture, though, so it doesn't matter here. (It'd "just" be a fork of ftpd that would transparently map between a versioned backend view and an unversioned frontend view. Very much like what Amazon S3 does for versioned buckets, actually.)

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

#63

Post by dreadnip »

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…

> it requires endless system maintenance. Otherwise all the PHP stuff becomes vulnerable to random hacks

How so? I've seen PHP websites & apps run for 10+ years in production without updates. Even longer with a simple "sudo apt update" every few months and a "composer update" every year or so. The maintenance rate is actually very very low.

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

#64

Post by liveoneggs »

untech wrote: post #36
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…

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.

We often hit lambda max quotas and scaling limits:

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

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

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

#65

Post by liveoneggs »

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.

yes where I work there is an alert for when a lambda is not running. I have proposed wrapping the lambda code in a while() loop on a fargate many many times to save $thousands of dollars but I lack the political power to actually do it.

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

#68

Post by wwweston »

edflsafoiewq wrote: post #21
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…

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.

This. For people looking for hosting as a service that don’t need scale (and even for some people who think they do) shared hosting is often the best low-admin + low-cost solution. Buuut you can’t brag about your cloud setup.

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

#69

Post by EGreg »

fernandopj wrote: post #57
chubot wrote: post #50

Earlier quoted context omitted.

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

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

Do you know about them?

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

#70

Post by EGreg »

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 is like CloudFlare workers.

They are deployed AT THE EDGE TO THE CDN, and therefore can handle requests without hitting your network and database.

For example I recommend your servers sign all the session IDs they give out, so they can easily be discarded if the signature doesn’t match or if they’ve been blacklisted. Such decisions can be made without doing any I/O, or by checking a local cache that was built up when eg a blacklisted session ID was tried just recently.

They can also spin up huge numbers of instances and fan out requests to MANY different servers, not just yours and your domain names. They allow client-first development, where you might not build ANY back end at all, just use some sort of JAM stack.

And now, CloudFlare Workers supports a key-value store and a SQL database so it is sort of an environment that will autoscale all your deployments in CDNs around the world and take care of the eventual consistency too.

Post reply on HN