On the contrary, neither of things are required. Most tellingly, Lambda itself was first released as an event-driven service; there was no endpoint to invoke in a client-server fashion.
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.
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.
The wrapper to fit Lambda into a client-server synchronous-invocation world is API Gateway.
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.
> The wrapper to fit Lambda into a client-server synchronous-invocation world is API Gateway.
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.
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.