Serving a half billion requests per day with Rust and CGI

Is the selling point of shared hosting and "serverless" PaaS platforms similar? To an extent it definitely is, but I think another major selling point of shared hosting was the price. For a really long time it was the only economically sane option, and even when cheap low end VPS options (usually OpenVZ-based) emerged, they were usually not as good for a lot of workloads as a similarly priced shared hosting option.

But at that point, we're basically debating whether or not the term "serverless" has merit, and that's not an argument I plan to make. I'm only trying to make the argument that serverless is about the actual abstraction of traditional server machines. Shared hosting is just about having someone else do it for you. These are similar, but different.

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.

> Serverless computing is an application development model where you can build and deploy applications on third-party managed server infrastructure. All applications require servers to run. But in the serverless model, a cloud provider manages the routine work; they provision, scale, and maintain the underlying infrastructure. The cloud provider handles several tasks, such as operating system management, security patches, file system and capacity management, load balancing, monitoring, and logging. As a result, your developers can focus on application design and still receive the benefits of cost-effective, efficient, and massively scalable server infrastructure.

Right. And that makes sense. Because again, what we're talking about when we're talking about AWS Lambda is serverless functions. But AWS also uses the term for other things that are "serverless", again, like Aurora Serverless. Aurora Serverless is basically the same idea: the infrastructure is abstracted, except for a database. This effectively means the database can transparently scale from 0 to whatever the maximum instance sizes Amazon supports without a human managing database instances.

That's also the same idea for serverless functions. It's not about whether your application has a "server" in it.

Exactly. And how that development model differs from the traditional approach is that you don't have to implement a server. Deployment isn't a development model. The development is necessarily done by the time you get there.

> But AWS also uses the term for other things

The terms has expended to be used for all kinds of different things, sure. There is probably a toaster out there somewhere solid as being "Serverless" nowadays.

If we really want to get into the thick of it, "serverless" seems to go back much further, used to refer to certain P2P systems. But we know from context that isn't what we're talking about. Given the context, it is clear we are talking about "serverless" as it emerged out of Lamba, referring to systems that were CGI-esq in nature.

But, no, you could very easily edit the httpd source to do the dynamic things and recompile it. As an example of what you could do, stock NCSA httpd supported "server-side includes" very early on, for example, definitely in 01994, maybe in 01993. The big advantage of CGI was that it decoupled the management of the server as a whole from particular gateway programs. It didn't take all that long for people to start writing their gateways in languages that weren't C, of course, and that was a different benefit of CGI. (If you were running Plexus instead, you could hack Perl dynamic things into your server source code.) And running the CGI (or SSI) as the user who owned the file instead of as the web server came years later.

By "abstraction of traditional server machines" do you mean "load balancing"? Like, so that your web service can scale up to handle larger loads, and doesn't become unavailable when a server fails, and your code has access to the same data no matter which machine it happens to get run on? Because, as I explained above, NCSA (the site, not NCSA httpd at other sites) was doing that in the mid-90s. Is there some other way that AWS Lambda "abstracts" the servers from the point of view of Lambda customers?

With respect to the price, I guess I always sort of assumed that the main reason you'd go with "serverless" offerings rather than an EC2 VPS or equivalent was the price, too. But certainly not having to spend any time configuring and monitoring servers is an upside of CGI and Lambda and Cloud Run and whatever other "serverless" platforms there are out there.