When you uploaded your PHP script, you uploaded it to a single server, and it ran on a single server. Unless your provider were doing some kind of load balancing (doubt it).

With serverless you upload your 'script' to the 'cloud' and then it will run on any number of servers, usually assigned to one when it dry-runs. Then it'll unload from the server afterwards. And therefore unless you have a bottleneck (like a database server) then you can essentially scale as far as the cloud will let you.

It worked because each page request ran a complete cgi php script to generate the page view and then terminated. There was no long running server.

Gestures at LAMP and PHP-FPM

This isn’t a contradiction. “Server” is an overloaded term and the “server” in “serverless” refers to a different meaning of “server” than the “email server” bit. “Serverless” means there is no physical or virtual hosts to manage, you just supply the request handler i.e., the email server. It's amusing because it sounds like a contradiction, but it's not one.

We're just swapping one type of management for another, really. Becoming proficient in all the permutations of AWS stack, for example, to

* make sure you don't get overbilled,

* have appropriate memory/limit resources on your lambdas,

* have correct backup/redundancy on s3,

* make sure all your IAM policies are correct and not allowing malicious actors, etc.

and more... it's ... just a different set of things to worry about. Yay - I don't have a 'server' that can go down. I now just have to make sure I don't get billed $87k because I forgot to click the correct button.

Servers need to be configured as do lambdas.

Servers also have backup needs.

Servers also present security problems of access.

It's not that hard to configure a lambda to run in just as limited a way as a physical machine.

Not having to worry about MCEs or disk failure patching makes the concerns less like a "different set" and more like a subset of things to worry about relative to managing servers.

I know most of this stuff is really well trod-over, but from your comment I think one'd get the impression that people are switching just because of a trend or something, not because there's an actual layer of management they're paying to have outsourced.

(I would acknowledge that view of it being a subset rather than a different set is invalid once you're debugging performance at a gritty level, where cold starts etc. etc. introduce their own equivalent layer of complication, but most people doing most things never need to)

How many times did you update your Node.js AWS Lambdas or GCP Cloud Functions because of the Linux kernel CVE of the week? You didn't because all you're responsible for is your few lines of Node.js logic that kept on scaling and humming along. The cloud vendor cares for the rest.

https://docs.aws.amazon.com/whitepapers/latest/security-over...

I'm not sure if that addresses your concern (maybe you're worried they're lying or they have a bug in their process)?

- Just add code/logic

- Scales to zero (zero calls to your endpoints, $0/mo)

- Scales up automagically to match load

- You don't do anything to provision/patch servers (e.g. FaaS)

Classic PHP shared hosts don't meet this definition because:

- You paid a flat monthly hosting fee (e.g. Dreamhost)

- You only scaled to 1 node (need more, too bad)

True, you didn't usually need to mess with PHP.ini or Apache server installs and configs, but you still didn't get the same benefits as modern serverless.

So you hit /index.php -> checks S3 bucket for index.php -> executes that with lambda and gets string of response -> returns it to original lambda -> serves up to client.

It's just now the same thing is done via some proprietary/custom cli tools and/or APIs not via a standard protocol and a trusty old clients that are already in your distro, and it's branded differently.

APIs are good for some uses. That's usually lacking with hosting providers. Other than auto-scaling I can also easily bankrupt myself with if I make a mistake, I don't see much qualitative difference. Only in the details.

While true, that's not the defining characteristic of "Serverless" because PaaS also does not require server management.

Yes it is. The "server" in "serverless" means no need to low-level manage/provision a server (computer) and its lifecycle. While "server" in "A serverless email server" means actually "service" as in "A serverless email service on AWS using S3 and SES". Which makes much more sense. The linked repo lets you have an "email server" just like GSuite gives you a "serverless email server".

If we swap "egg" and "cooking" with "VM" (or "bare metal" if it suits you better) and "maintaining", suddenly "serverless" doesn't sound so ridiculous.

Those aren't mutually exclusive, which is my whole point. One definition of "server" is "a service in a network". Another definition is "a computer in a network". So you can have a server running on a server without contradiction. If the user isn't responsible for managing the underlying computer, then you have a serverless server.

> which still has servers underneath it, you're just not running them

Of course, "serverless" means you don't have to worry about the underlying servers, not that they don't exist. Perhaps you were only clarifying and not nerd-sniping, but this particular nit is so boring and predictable in every serverless thread.

Can you link to something where this is a common accepted definition? I'm a systems engineer by trade, talk to a bajillion people about all sort of things and we just don't call a "service in a network" a server in parlance.

I was not nerd-sniping and could care less about serverless as a term, I'm specifically talking about calling a "service" a "server" in this chat. I feel this is presenting something as accepted definition which does not match my experience in the field.

This seems to be a common point of confusion for people who aren't native English speakers. Oxford English Dictionary defines "server" as:

> a computer or computer program which manages access to a centralized resource or service in a network.

Similarly, a quick bit of Googling turned up [this][1] which isn't authoritative, but indicates that "server" can mean either hardware, VM, or software services.

[1]: https://stackoverflow.com/a/13118205/483347

Where did this come from and what value does it have, other than being condescending to non-native English speakers? I am a native speaker and we're having a discussion in my native tongue about words in my native language about work I do as a profession.

> Similarly, a quick bit of Googling turned up [this][1]

I do not accept Stackoverflow as an authoritative source for anything. Useful? Yes, great for finding random solutions to random problems. Authoritative source on terminology used in the industry I work? Nah.

Apache [1] "The Number One HTTP Server On The Internet". This is not referring to the machine hosting, it's referring to the software that you run to provide a service.

Postfix [2] "mail server"

IIS [3] "Web server"

I could go on...

[1] https://httpd.apache.org/

[2] http://www.postfix.org/

[3] https://www.iis.net/

I don't think he was being condescending, so there's no need to be offended on behalf of other people.

I think he was suggesting that part of the linguistic confusion comes from how the tech industry has become so global that different words and phrases are exchanged between cultures, but within the tech sphere.

For example, it's not uncommon to hear the phrase "Do the needful" in places like Seattle, even though the phrase originated elsewhere and was imported by tech workers.

I do not accept Stackoverflow as an authoritative source for anything.

Good call. I'm with you there.

What is condescending? I'm observing that it's a common problem among non-native English speakers. It seems like you're taking offense on behalf of others and unduly so.

> I am a native speaker and we're having a discussion in my native tongue about words in my native language about work I do as a profession.

This is a common idiom among English-speaking IT professionals. If you're not familiar, that's fine. Now you know.

> I do not accept Stackoverflow as an authoritative source for anything

In a minute of Googling, I found several random sources on the Internet that indicate that the term is overloaded precisely as I described. One of those sources was the Oxford English Dictionary. I think that suffices to demonstrate that this is a common idiom, but I can't force you to be persuaded. ¯\_(ツ)_/¯

    $ man systemd | head -4 | tail -1
       systemd, init - systemd system and service manager

sed -n '11,500p' < file.txt

Which is the summary

man systemd | cut -d $'\n' -f 4

Works with multiple lines too:

cut -d $'\n' -f 10-20,50-60

"SMTP transaction against an SMTP server"

To which I honestly, just kept my mouth shut and stood aside.

(not commenting on the "serverless" name for what used to be called "mutualised services"…)

I can never keep my mouth shut in these situations. Sometimes it leads to promotions, but I suspect it puts a ceiling on how high I can climb the corporate ladder.

cloud computing is basically batch processing in the mainframe of yesterday from a functional standpoint.

It's just a term used to describe a server configuration that has different billing/operational characteristics than traditional always-on.

And like the quadcopter-drone, I hope everyone losing their shit over this can either accept "serverless" or submit and market a new term that conveys this difference soon.

A cgi-bin is as highly available as the web infrastructure hosting it, which as the cgi-bin author you don't need to know anything about.

A cgi-bin cannot "crash" because there is nothing long-running to crash. It is only run on demand.

I think it is easy to make the case that CGI was the proto-serverless api and that the serverless offerings we have today are an evolution of the CGI approach.

edit: typos

And thus, it can be distributed as well as any other stateless function.

If our code crashed, the next request would just get served as normal. If Apache crashed or a frontend crashed, another one would just take its place. High availability cgi-bin is trivial.

I look forward to true serverless software - that is either peer to peer or uses a distributed back-end with encryption. Now THAT is the future!

Serverless just means “we spin up a server for you”, similarly to how “the cloud” is just a euphemism for “extreme centralization of hosting myriad clients under the control of one company”.

I agree it's not a term well suited to its popular use, but such is life. Commercial interests are constantly mucking up the language to suit their own ends. E.g. Discord is abusing the term "server" to mean a virtual meeting space. "Organic" w.r.t. food has a really contrived official criteria, unlike in chemistry. Regular people muck up the language in frustrating ways, too. See "literally".

Thank you for "spin up a server," as in fire up the hard drives, rather than "stand up a server," as in... I dunno.