Usually somebody else is managing the server, or servers, so you don't have to think about it. That's been how it's worked for 30 years.
> Before PaaSes I don't think I've ever seen anyone once call CGI "serverless".
No, because "serverless" was a marketing term invented to sell PaaSes because they thought that it would sell better than something like "CloudCGI" (as in FastCGI or SpeedyCGI, which also don't use the CGI protocol). But CGI hosting fits cleanly within the roomy confines of the term.
Having a guy named Steve manage your servers is not "serverless" by my definition, because it's not about you personally having to manage the server, it's about anyone personally having to manage it. AWS Lambda is managed by Amazon as a singular giant computer spawning micro VMs. And sure yes, some human has to sit here and do operations, but the point is that they've truly abstracted the concept of a running server from both their side and yours. It's abstracted to the degree that even asking "what machine am I running on?" doesn't even have a meaningful answer and if you did have the answer you couldn't do anything with it.
Shared hosting with a cgi-bin is closer to this, but it falls short of fully abstracting the details. You're still running on a normal-ish server with shared resources and a web server configuration and all that jazz, it's just that you don't personally have to manage it... But someone really does personally have to manage it.
And anyway, there's no reason to think that serverless platforms are limited to things that don't actually run a server. On the contrary there are "serverless" platforms that run servers! Yes, truly, as far as I know containers running under cloud run are in fact normal HTTP servers. I'm actually not an expert on serverless despite having to be on this end of the argument, but I'll let Google speak for what it means for Cloud Run to be "serverless":
> Cloud Run is a managed compute platform that enables you to run stateless containers that are invocable via HTTP requests. Cloud Run is serverless: it abstracts away all infrastructure management, so you can focus on what matters most — building great applications.
These PaaSes popularized the term to mean this from the gitgo, just because you have passionately formed a belief that it ever meant something else doesn't change a thing.
That's the trouble when a term catches on — everyone wants to jump all over it and use it as they please.
This is hardly a unique situation. Look at SQL. According to the very creator of the relational model, SQL isn't relational, but the SQL specification latched onto the term anyway because it was trendy to do so. As a result, today, I think it is fair to say that "relational" has taken on dual meaning, both referring to the model as originally conceived as well as what SQL created.
If you wish to maintain that "serverless" now refers to both an execution model and outsourced management of computer systems, I think that is fair. However, it is apparent that "serverless" was originally popularized by Lamba, named as such due to its CGI-inspired execution model. Other angles came later.
I do think that SQL falls short of the relational-data-bank ideal in a number of important ways, and I mostly agree with Date on them. I just don't agree with Date's saying he's not contradicting Codd's early work.
> SEATTLE – (Nov XX, 2014) – Amazon Web Services LLC (AWS), an Amazon.com company (NASDAQ:AMZN), today announced the introduction of AWS Lambda, the simplest way to run code in the cloud. Previously, running code in the cloud meant creating a cloud service to host the application logic, and then operating the service, requiring developers to be experts in everything from automating failover to security to service reliability. Lambda eliminates the operational costs and learning curve for developers by turning any code into a secure, reliable and highly available cloud service with a web accessible end point within seconds. Lambda uses trusted AWS infrastructure to automatically match resources to incoming requests, ensuring the resulting service can instantaneously scale with no change in performance or behavior. This frees developers to focus on their application logic – there is no capacity planning or up-front resource type selection required to handle additional traffic. There is no learning curve to get started with Lambda – it supports familiar platforms like Java, Node.js, Python and Ruby, with rich support for each language’s standard and third-party libraries. Lambda is priced at $XXX for each request handled by the developer’s service and $YYY for each 250ms of execution time, making it cost effective at any amount of usage. To get started, visit aws.amazon.com/lambda.
Let me emphasize some points here:
> Previously, running code in the cloud meant creating a cloud service to host the application logic...
> then operating the service, requiring developers to be experts in everything from automating failover to security to service reliability...
> Lambda eliminates the operational costs and learning curve for developers by turning any code into a secure, reliable and highly available cloud service with a web accessible end point within seconds.
> there is no capacity planning or up-front resource type selection required to handle additional traffic
It is genuinely impressive how devastatingly, horrifically incorrect the idea is that "serverless" ever had anything to do with whether your application binary has a network request server in it. It's just not a thing.
We can talk about the parallels between CGI servers and Lambda all day and all night, but I am not letting this non-sense go. Serverless is not a marketing term for CGI.
[1]: https://www.allthingsdistributed.com/2024/11/aws-lambda-turn...
Well, that's sort of true of AWS Lambda, but it's just as true of EC2 and EBS, which aren't called "serverless". Moreover, "serverless" is a marketing term used to sell the service to Amazon customers, who can't tell whether or not there's a guy named Steve working at Amazon who lovingly nurtures each server†, or whether Amazon manages their whole Lambda farm as a giant herd of anonymous nodes, so I don't think it makes sense to argue that this is what it's intended to mean. As you point out, it's kind of a nonsense term since the code does in fact run on servers. I believe you were correct the first time in your earlier comments that you are now contradicting: they call it "serverless" because the customer doesn't have to manage servers, not because their own employees don't have to manage servers (except collectively).
> enables you to run stateless containers that are invocable via HTTP requests. (...) abstracts away all infrastructure management
This is a precise description of the value proposition that old-fashioned CGI hosting offers to hosting customers. (The containers are processes instead of KVM machines like Firecracker or cgroups like Docker, but "container" is a pretty generic term.)
So I think you've very clearly established that CGI scripts are "serverless" in the sense that Google's marketing uses, and, in https://news.ycombinator.com/item?id=44512427, the sense that Amazon's marketing uses.
______
† Well, Steve would probably cost more than what Amazon charges, so customers may have a pretty good guess, but it could be a loss leader or something.
