Comment by politelemon | Hacker News Reader

Comment by politelemon | Hacker News Reader

Parent Full thread

> 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, maintaining and deploying AWS Lambda functions — and it comes without the lock-in to boot. Moreover, the former allows me to give an URL to a piece of code instantly, whereas with the latter I have to figure out how to setup AWS API Gateway plumbing correctly. I'm genuinely curious how many people find AWS Lambda interesting because they've never encountered, or never properly looked at, CGI.

Well, assuming you are genuinely curious and not just using an expression!

The difference is that the 'web server' is still consuming resources when the code is not in use. They aren't equivalent at all. The web server is hosted on an OS and both require ongoing maintenance.

Further, the appeal of Lambda is in its ease of onboarding for newcomers; I can run a piece of .NET or JS or Python locally and directly without a lambda 'layer' to host it, just invoke the handler method.

I'm not sure what complex tooling that the author is referring to though, it's a zip and push.

Once you add API gateway, IAM roles/permissions, VPC, security groups, it gets a lot more complicated. Then you want to host a static web site, reverse proxying to API gateway, add CloudFront, WAF, etc. You'll go crazy setting this up manually, so you'll also want Terraform or CloudFormation to make it repeatable.

For anything complex, you'll run into "slow start" issues and have to look at provisioned concurrency.

Lambda also sucks for dependencies. Zips and "layers" can only be so large. Eventually you'll hit the limit and have to move to containers. There are also other limitations, like payload sizes. Eventually you might run into that, too.

Also, it would be nice if Lambda just reused the CGI interface instead of inventing its own thing.

> nice if Lambda just reused the CGI interface

Lambda is an event-driven system; synchronous, stateful request/reply for HTTP is shoehorned onto that. At heart it's a scale-out queue processor, not a web server. This whole "lambda gives your code a URL" folks speak of, is actually an API Gateway thing. This is also why Lambda has at-least-once semantics rather than that at-most-once, which definitely surprises the casual web developer from time to time ("why did that happen twice??").

That said, I don't disagree with the sentiment; it would be quite nice if API Gateway had a simple option to map incoming request parameters to CGI-like attribute names in the event payload.

Yeah, it's an absolute explosion of complexity, and with it comes the risk that you miss something and are faced with a security issue or giant bill or both.

What I would kill for is something in between all of this and FTPing PHP around like it's 1999. I've hunted for years for middle-ground solutions and haven't found anything. Security, cost, performance etc are important, sure, but what I really yearn for is a simple, easy, bulletproof solution like the days of yore when a handful of simple scripts could chug on for decades. Two decades ago you could set up a simple site that needed no attention for twenty years. Today's technologies require constant attention and updates and if you blink then everything requires an update that's not compatible with your code. Meanwhile, PHP from 2004 can be trivially run in 2024. What's the PHP-and-FTP of today? Does it exist?

Actually they don't, at least most of the time.

At my last shop the entry cost for hosting a single static file was around $2500 for infra, because that was the agreed upon template for a project that was pre-approved by all neccessary committees. I've tried to fixed it for quite some time, presented solution to C level, got some initial funding, but eventually after many pushbacks I died on that hill.

People like to play with toys, cv driven developement is a real thing, and when it comes to security and compliance everyone want to be sainter than the pope, just in case.

Is that $2500/month?

Have you seen https://www.val.town/ ?

tgere are far better ways but for the sake of simplicity I suppose you could ssh in to box, cd /some/dir, and git pull on the latest branch. that way atleast you have version control and can rollback quickly if you bork your site

It's still php-and-ftp. Sometimes I get fancy and use python and ssh.

I was going to say the same thing. I generally use Laravel instead of "raw" PHP these days, but still...

I nowadays mostly use a simple static website plus minimal Javascript, but I still have PHP sites.

It still works. And PHP today is at least factor 3 faster than PHP was back then — on the same hardware.

So maybe just use PHP and ftps or sftp?

> Two decades ago you could set up a simple site that needed no attention for twenty years.

...but as of yesterday, you can't?

In a lot of these discussions the point gets raised about the work to maintain a self-hosted server. When i've done it I install the os (usually ubuntu server), turn off unused services, setup the firewall to only allow required ports, and then it just sort of sits there and does its thing. Uptimes have been measured in years in some cases and the server just sits there happily serving whatever html and connecting to whatever db forever.

Do you enable unattended upgrades and kernel live patching? If not, then that doesn't seem secure.

`dnf upgrade` or `apt update && apt upgrade` once a month isn't so much work. If either includes a kernel upgrade then it's `reboot now` and I'm done.

But if you're doing that, it's not just sitting there, and you'd never get anywhere close to years of uptime.

I'm most cases people stress uptime too much. Developers worry about downtime during restarts and overcomplicate everything because of it. Meanwhile, my national railway reservation system has an hour of planned downtime daily and life carries on.

I mean, typically hosting a static site that's fine, but with the number of exploits these days and the ability for people to chain them together, maybe you don't even realize your box has been exploited?

Uptimes in years means your box, especially without updates has something it could be targeted with.

Most of those that are find for a static site but not dynamic are those that are not fixed by just applying updates from the distro.

You still need to update your app code even if you are using someone elses servers, so its the same either way.

Note that the parent said "uptimes measured in years", so they are either using a more complex system with multiple servers, or they are not doing security updates.

I agree I would not endorse uptimes measures in years, which means not doing kernel updates - but OP does qualify that with "in some cases".

> They aren't equivalent at all. The web server is hosted on an OS and both require ongoing maintenance.

From a technical standpoint, surely the servers running Lambda have an OS and require maintenance internally by Amazon at some level (even if it's dev-ops-abstracted away for their operators). It's just their responsibility instead of yours, and it's also their responsibility to find other work for those servers when your code isn't running (or bear the cost of an idle server). It's like if they were letting you push PHP functions to their web server, using the quoted comparison.

Useful from a business standpoint, yes. Revolutionary, maybe not as much as it seems at first glance. That's the takeaway I got.

> Useful from a business standpoint, yes.

This business standpoint is the whole thing, I don’t see many people arguing otherwise. And the business standpoint is in fact quite revolutionary.

Amazon can have a team of like 5 engineers maintaining VM images and as a result 500,000 other people don’t have to. And so you can host a “server” that’s only “on” when it’s in use, and usually end up paying less than $1/mo.

In fact, you could likely run all of your side projects in lambda and if they’re “conventional web server” type things you could still end up paying less than $1/mo across all of them.

Compare that to a $5/mo droplet for every side project (you probably don’t want to bunk multiple services into a $5 VM) and it definitely adds up before even considering updating the OS on those droplets.

And, of course, they don't just "bear the cost of an idle server". Just like any other fixed costs in any other industry, those costs get smeared over the charged prices. Unless there is some serious economy of scale (i.e. ops at Amazon managing to handle the upkeep of a 1000 of their servers for less than 1/1000 it costs you to manage 1 of your server), you're ending up paying somewhat more. But then again, you don't have to spend time to manage your own server which is probably a positive trade-off.

>> somewhat

It's a factor of 5 to 20 [1] in many cases.

Regular hosting is unbelievably cheap, especially in high traffic environments.

[1] https://tech.ahrefs.com/how-ahrefs-saved-us-400m-in-3-years-...

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.

Where can I get a VM in a data center that doesn't cost me anything?

cost and convenience: Time is money.

Whatever works for you is more important than 5 euro.

Lambda is pretty straightforward as well for those who know how to use it.

You probably could do something marginally useful with lambda within 30 seconds as well.

Don’t you have a virtual server? I’m pretty sure that my managed webserver runs on some virtual machine somewhere on a bigger server, and when it is not doing stuff, other tasks are running there and using the CPU and bandwidth.

There is likely some fixed memory and disk space cost, but those are negligible with todays capacities.

Reply on news.ycombinator.com