Since it's serverless, I assume it runs on the client. How does it scale then? And is the client really the right place to run these functions, in view of performance, and perhaps battery use?
"Serverless" is a marketing term invented by Amazon for what might in retrospect have been better described as mini-PaaS.
It doesn't literally mean "without servers". It means that the developer doesn't care about them. AWS have energetically pushed the line that in The One True and Holy Definition of Serverless operators don't care either.
Which, gee whiz, what a coincidence, distinguishes Lambda from opensource projects like this.
Disclosure: I work on a FaaS, Project Riff, for Pivotal. So I guess we're kinda competing with AWS? -ish?
> "Serverless" is a marketing term invented by Amazon for what might in retrospect have been better described as mini-PaaS.
Almost. Imho "serverless" describes more the architecture of applications, in contrast to "mini-PaaS" which would then describe the platform on which such applications are deployed.
Warning: handwaving ahead. Serverless just means each and every request from the client spins up a process on a cloud platform to handle the request. It is "serverless" in the sense that the actual hardware and OS running the process is completely abstracted away from the developer. You just tell the platform which functions should respond to which routes and the platform handles the load balancing, deployment, and (usually) spins up a container for each request on demand.
serverless means that the server is abstract it away from you, you just have scripts that run and if it needs to run grow to more servers it will do by itself
Serverless is an annoying buzzword term that actively confuses those who don't know the architecture. What is it, really? (someone else tried to explain above). What does if offer? What is an example use case or business/research function deployed on "serverless" services?
