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.
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...
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"
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.