3 ms·
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
by jimbokun 2y ago
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 to replace with "CGI" in my head.
- throwaway22032 2y agoBasically everything AWS is things we already have but more expensive because someone else does the easiest bit for you.
- tracerbulletx 2y agoI don't know how anyone who experienced how Ops worked at companies before AWS can say things like this. Is AWS right for everyone economically? No. It is an impressive automation of software operations, that has driven the industry forwards by leaps and bounds. Yes.
- jjk166 2y agoSome people don't want to create a universe every time they want an omelet.
- afavour 2y agoThe 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.
- magicalhippo 2y agoSo it's like code-only shared hosting, billed by CPU-time rather than wall-time, and with a load balancer in front.
- afavour 2y agoAnd 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!
- jimbokun 2y agoDidn't know enough about it to know whether I should care enough about it to investigate more.
- salawat 2y agoAnd 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.
- chubot 2y agoThere'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 https://www.oilshell.org/blog/2024/06/cgi.html
- untech 2y agoI 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.
- loloquwowndueo 2y agoBut it’s entirely susceptible to your wallet being hugged to death if someone decides to ddos you.
- afavour 2y agoThat’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.
- coryrc 2y agoInstead your wallet gets ddos'd.
- chubot 2y agoCGI 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 https://www.oilshell.org/blog/2024/06/cgi.html
- afavour 2y agoThis 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.
- pram 2y agoLambda 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.
- Sharlin 2y agoNews at eleven: devs use tech for utterly inappropriate purposes just because it happens to be cool at the moment.
- morkalork 2y agoI can definitely see lambdas being abused when the process for requesting dedicated resources is too arduous.
- jbmchuck 2y agohttps://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/deploy-lambda-functions-with-container-images.html https://docs.aws.amazon.com/prescriptive-guidance/latest/pat...
- liveoneggs 2y agoyes 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.
- derefr 2y agoLambda 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 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.)
- troupo 2y ago> Lambda is also distributed, though — while CGI scripts just live on the webserver itself. Most of the stuff people use lambdas for they could run from the cheapest Digital Ocean droplet or cheapest Hetzner server. You need "omg distributed" perhaps after your millionth user, and even then it's highly debatable.
- derefr 2y agoYou're thinking about the (rather few) advantages distribution confers for single-tenant scaling. But the distribution here is mainly for other reasons: • operational fault-tolerance: arbitrary servers in the cluster hosting the function can fail or be taken down for repair without any workloads going down. This allows the ops team that owns the cluster to freely keep the cluster's machines up to date with OS package updates, reboot them as needed, swap them out for newer-generation hardware, move them to new racks in new DC buildings, etc. (This is also something you get from a VM on most larger clouds — but only because the VM itself is a workload running on a hypervisor cluster, where the cluster's control-plane can live-migrate workloads to drain host nodes for maintenance.) • horizontally scaling the cluster as a whole, to keep up with more and more users sticking more and more workloads onto it, and more and more requests coming in for those workloads. As load increases, just add more diskless web servers. (This also means that in the rare case where your workload is too popular to fit on a cheap VPS, the ops team is doing your personal infrastructure scale-out for you for free, as part of scaling the capacity of the service as a whole.) • maintaining your multi-tenant Quality-of-Service in the face of other users who have hugely-expensive workloads. On that 90s cgi-bin webserver — or on a modern VPS — if someone else deploys some workload that pins all the CPU cores for five seconds each time anyone calls it, then that impacts how long it takes you to serve calls to your workload, because your request has landed on the same machine and is waiting in some kernel queue behind that other workload's CPU bottleneck. VMs solve this by reserving capacity per workload that's "always on" even when the workload is idle. Lambda solves this by collecting resource-accounting statistics for each function and resource-utilization metrics for each backend, and putting that info together at the load-balancer level to plan a hybrid of least-conn and resource-packing routing to backend nodes. --- But even ignoring all that, the point of the "distributed-ness" of the Lambda architecture on the low-usage end, is the "scales to zero" part that it shares with CGI. Unlike VMs, you aren't paying anything per month for a function nobody is calling. And for a workload that does get called, but only runs for N aggregate CPU-seconds each minute, you're only paying N/60 of what you'd pay for a VM (which runs every CPU-second of the every minute.) If you have one script and you have $5/mo burning a hole in your pocket, then sure, I guess you could put it on a DO droplet? (But you could just as well deploy a function that will cost you less than $5/mo.) But if you have ten scripts, where some of them might be high-utilization (you're not sure yet, depends on how many people hit the web pages that call them) while others are definitely extremely low-utilization — then your options are either "becoming a hobbyist DevOps engineer, utilization planning a packing arrangement of VMs or hardware to optimize cost, installing metrics to ensure things aren't falling over, getting emails when it does, re-planning things out, and migrating them as necessary"... or just deploying 10 functions and getting what will probably be a bill each month for <$1.
- EGreg 2y agoLambda 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.
- troupo 2y ago> where you might not build ANY back end at all, just use some sort of JAM stack. So, a backend > And now, CloudFlare Workers supports a key-value store and a SQL database So, a backend.