I think serverless is a very misleading name, because it does still need server infrastructure and server software.
The serverless term will confuse non-technical people to think there's actually no server infrastructure or software needed.
The serverless term will confuse non-technical people to think there's actually no server infrastructure or software needed.
Moreover, although function-as-a-service requires hardware to run on (duh), the need for server-grade compute infrastructure is obviated by the short execution times. You could run a FaaS-based offering on a massive array of smartphones.
So sure, if you build a FaaS platform you'll need a scheduler, but you won't need a server, not in the client-server sense and not in the hardware sense either.
So some marketing-oriented people will think that "serverless" is just a buzzword to mean you're not managing the OS & hardware, but there's actually a more positive reading of this term that undermines all the negativity.
How do you trigger a function from the outside Lambda ?
But Lambda was built as an event consumer e.g. listening to a SNS queue. If you look at the broader set of AWS services you have a full toolbox of event-driven pub/sub message/event-driven tools to play with: Lambda / Kinesis / S3 / DynamoDB / SNS / SQS / Cognito / IoT and more.
It's enough of an integration & compute lego kit to build complete distributed/asynchronous pub/sub applications. However the tools are kinda .. developmental, you'll be doing much of the wiring up yourself.
So yes, there is a server indeed. Why call it "serverless" then ? because one part of the stack uses pubsub ? then call that part a worker queue because that's what it is.
Do you have a process listening on a port, that accepts connections and handles what is sent through them? If the answer is yes, you have a SERVER. That's the definition of a server.
If connection handler is short lived, well, so it is the case in a HTTP server. It's just a repackaged idea.
Non-technical people may assume no server infrastructure. From the developer perspective -this is accurate-; the actual hardware is handled by someone else, there is no concept of it that the developer has to work around.
I'm not sure why you'd think someone would believe no software would be needed; even when servers are involved, there is software located elsewhere, on a mobile phone or a web browser or similar. No one is going to say "Oh, serverless? Then I don't need my software development team any more!"
So why not chose a more fitting name?
Why not say "fully-managed" or "serverside fully-managed"?
In serverless, everyone is a "client" and you run things client-side. Things like P2P file sharing in the browser is serverless. Things like AWS lambda obviously have a server.
If I deploy a PHP script on a shared host there is no server to manage either. My PHP script doesn't listen communications on a socket connection. It doesn't make it "serverless". At some point the stuff you deploy, on a server no matter what you think it is, needs to communicate with the outside world through a server. It is not "serverless".
There is no technology anywhere that is called "Wireless internet". There is wireless networking, which does exactly what the name implies, it transfers packets from point A to point B, without wires.
That it might be connected to wires at each end is irrelevant because that is a different technology.
"Serverless" is a misleading name - it inherently requires a server, as it's specifically a server-side technology (an event driven function runner).