Hacker News Reader

Comment by GuB-42 | Hacker News Reader

A serverless server?

It is a great illustration of how the term "serverless" has shifted from literally no server (ex: sqlite database) to "somebody else's computer".

View on HN

This argument is so tiring... if we all agreed to change the word “serverless” to idk “xirverous” it would have a pretty clear meaning and clear distinctions from “server” and “local to the machine”. Xirverous technologies are an innovative, new, unique, and interrelated class of technologies. Thank you for your consideration.

I was doing serverless pages back in late 90s when I uploaded PHP scripts to "website providers".

true serverless

Why "true"? I don't have to worry about servers and infrastructure with Lambdas either.

Now those are called "cloud" servers (gasps, awe)...

Why are you booing me? I'm right.

original lambda

"Your function runs from scratch on each request, with some intelligent caching for performance reasons."

Gestures at LAMP and PHP-FPM

Different thing though.

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.

Scaling: upload file to another server.

At least with Mediatemple’s shared hosting, they had a “grid” service that would host your site on a cluster of servers and claimed to be able to handle large bursts of traffic.

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.

It worked. But I remember Media Temple being slower than their competition. Seemed to have to pay a performance penalty for the "grid".

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

I disagree with your assessment, email is a service and not a server. A service can run on a server, or ephemerally as in this article (which still has servers underneath it, you're just not running them). S3 and SES are services running on servers.

You are incorrect, see man pages.

This makes no sense (too abstract of a statement), but here let's try this:

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

An email daemon (Postfix, Exim, Dovecot, UW-IMAP, Sendmail, etc.) are services running on a server. An "email server" would be a server running a daemon to provide email service in this example.

This makes me think there should be a Linux tool to extract the Nth line of a file. With options to get the N-Mth lines, etc

Man pages can be tricky as the content can vary distro by distro (how up to date is your copy of man-pages, what changes have happened, etc.) - this technique is pretty portable to extract the synopsis of a man page specifically due to the format it uses (most times I'd use like grep -A3 -B2 foo /some/file, e.g.).

Ugly way to get the first indented line: `man systemd | grep '^ ' | head -1`

Which is the summary

There are many. Sed is fast. This will give you lines 11 to 500

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

Calling cut with a newline as the field delimiter works:

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

Works with multiple lines too:

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

Makes plenty of sense: https://man7.org/linux/man-pages/man1/smtp.1.html

"SMTP transaction against an SMTP server"

> email is a service and not a server.

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.

> One definition of "server" is "a service in a network"

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.

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

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

> This seems to be a common point of confusion for people who aren't native English speakers

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.

I'm surprised you need a source for this. Literally half of the server software out there refers to itself as "<thing> server".

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/

Where did this come from and what value does it have, other than being condescending to non-native English speakers?

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.

> Where did this come from and what value does it have, other than being condescending to non-native English speakers?

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. ¯\_(ツ)_/¯

Accept the L.

Nah. +4 for the thread after adding up the down/up votes. I dipped out, the conversation held no further value to continue to me especially after being told "well it's an idiom you just don't understand". No minds will be changed, no positive outcome will happen from continuing.

> This isn’t a contradiction.

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

I don't understand. You insist it's a contradiction but then go on to reiterate my own argument which demonstrates that it is not, in fact, a contradiction but rather using the same term ("server") to refer to two distinct concepts ("computer" vs "service")?

It's a contradiction because it's an incorrect overload of the word "server".

Well, Oxford English Dictionary disagrees with you.

So if you get an omelette at a restaurant, I can call it an eggless omelette because I didn’t have to cook the eggs myself?

This would make a lot of sense if the de-facto restaurant experience involved you cooking your own eggs, especially if the egg-cooking experience was notoriously laborious and expensive.

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.

No no, it still sounds ridiculous.

If "egg" was an overloaded term that meant the noun "egg" and the noun "process of cooking an egg for an omelette", then yes, you could.

Agile isn't really agile. Cloud computing isn't really in clouds. Personal computers aren't that personal. Serverless isn't really serverless. Who cares.

"means there is no physical or virtual hosts to manage"

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.

Billing exists for servers as well.

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)

Amen.

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.

Just because you didn't doesn't mean they did and you didn't actually have any vulnerabilities. There is no such provable attestation of security in serverless model.

> Lambda provides support for these runtimes by continuously scanning for and deploying compatible updates and security patches, and by performing other runtime maintenance activity.

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)?

> “Serverless” means there is no physical or virtual hosts to manage

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

It's indistinguishable from a regular web hosting. You just upload script to some ftp and don't manage anything either. You just configure links to other services like DNS, or DB if that's needed.

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.

Cloud 2.0 "serverless" often expects:

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

I wonder if you could, for reasons, make a set-up where you upload your PHP files to an S3 bucket, and then have a API Gateway or Lambda which basically just serves the files from the bucket, and if they are PHP, executes them with a Lambda PHP runtime.

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.

I'm a little confused about why you're responding to me. I think I agree with everything you're saying, but I'm not sure where the comparison with PHP hosting is coming from. Are you sure you responded to the right thread?

I literally had one of the heads of a crucial flight system project loudly exclaim to me in front of the senior managers. "It's serverless - there is no server!"

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

Maybe what he meant is "there is no server that we are responsible for", which is where the benefit lie for them.

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

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

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.

I just figured there was some "short term" misunderstanding. As always I looked like an idiot but hey in a good place with good people youll all just move onto the next topic and know the details will work themselves out regardless who is right.

Spent the first 10 years of my IT career driving towards greater control over the systems we managed, because "the reason the service is down is that someone else (usually a vendor) didn't do their job" was never an excuse. The last 5-10 years I've found myself ceding more and more control to cloud service vendors (like Microsoft). Less work for me ("raise a premium case"). Less stress too ("they're working on it, nothing for us to do"). Now I finding myself hoping I'll be retired before the pendulum swings back again.

everything old is new again.

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

We went through this when people first started calling quadcopters "drones".

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.

My understanding of it has been "look, I reinvented cgi-bin."

Is cgi-bin highly available and will someone else have to wake up at night if it crashes?

sure, cgi-bin with a big load balancer

It can be, and not necessarily. `cgi-bin` can be as stateless as you want it to be. Just as stateless as lambdas, or other forms of "serverless" functions.

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

Yes and no, respectively.

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 cgi-bin was really just an evolution of inetd (or ucspi-tcp if you worshipped at the altar of djb). You didn't used to have to worry about binding to ports or long running processes. Something would just send you a message on stdin and you replied on stdout.

I ran an e-mail service with 2m users. The web frontend was written in C++ (no, I don't want to go back, but we had a pretty nice custom framework) all served up as a CGI, behind a load balancer.

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.

That depends on you and the SLAs you have in place with your cgi-bin provider.

I don't think there's anything wrong with reinventing something to be more accessible.

And a million other moving parts: https://raw.githubusercontent.com/0x4447/0x4447-product-s3-e...

This comment shows up on every thread about lambdas, and despite the FUD it still proves its value to me every single day.

"Serverless" is a ridiculous stupid term. You'd think it meant something like Photoshop, some system that doesn't rely a server, something that lives locally. Nope. It's just a server that someone else manages 90% of.

No we call those a more succinct term: local processes. We call "serverless" for processes running not locally that do not require standing up a server that you care about for, are billed by usage only ($0 for none, infinity for infinite), and you are not concerned where or how it is running. Are there computers listening for requests somewhere that someone is managing that is doing this? Yes. But from my frame of reference it is a service, not a server. I know a lot of people on here get hung up on it, but it is the term and it is not going to go away.

Serverless has become a stupid marketing term, just like Facebook hijacked the words “Friend” and “Like”.

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

Serverless just means “we spin up a server for you”

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

It's more than that, slightly. A "serverless" application doesn't have a specific piece of hardware supporting it except in the context of a single operation. The hardware is all abstracted away and allocated from a pool on demand. I suppose it comes from "serverless architecture", where there are just other distributed services (not specific servers, virtual or otherwise) executing your code.

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

I guess a Heroku hosted application counts as serverless then.

Reply on news.ycombinator.com