I am new to the whole serverless concept, can someone explain how it works? Let's say I have to do some processing on the server (schedule some cron jobs, generate a PDF or send an email), how do I go about doing that? Do I use AWS Lambda for that?
But seriously what they mean is that you rent an allotted amount of resources on a server farm to run your application for a short period of time, and then the resources are freed again. Not all applications will fit this environment, such as any embedded databases, persistent connections, and so on.
But that's a mouthful, so "serverless" seems to fit the bill outside of what feels a bit like pedantry.
Given all the work this appears to save one, there's a curious explosion of "serverless" articles, frameworks, APIs, 'practices', crash-courses, workshops, talks .. ah well, par for the course with anything tech that gains a catchy moniker.
(Perhaps that's why FP doesn't take off quite as much, "Monads" should have been called "Promises" 30 years ago, and Peano Numbers "numberless maths"!)
https://en.m.wikipedia.org/wiki/Serverless_computing
https://aws.amazon.com/lambda/
"Run code without provisioning or managing servers [...] pay only for the time you consume"
Makes sense, but based on the name, I initially expected to see a framework that lets you spin up an app without writing any backend code, perhaps like using Firebase but more framework and less service. Then I thought there are even more ways to remove the server.
Maybe there should be multiple levels of "serverless". Type 0 serverless is an html file. Type 1 serverless is a static web page. Type 2 serverless is a dynamic app with a backend service; no writing backend code. Type 3 serverless is a dynamic app plus backend code with a backend management service; no provisioning or managing backend instances.
:P
Essentially, the motivation is to abstract away from caring about the underlying operating system and virtual machine. That is, in the same way that a VM attempts to abstract away from the underlying hardware (so that you, the system operator, need not care about it), serverless attempts to abstract away from the underlying VM and operating system. You the developer shouldn't care about that; you should just care about your code.
So how is that achieved? Well, in AWS, Lambda is a key portion of it. They are small units of execution, defined by arguments in, arguments out, and side effects (same as a function in any language). They have access to a set amount of cpu/memory resources, as well as a bit of hard disk scratch space (note: this space is -not- guaranteed to exist across function invocations; any state you wish to persist between functions must be stored in another services, such as RDS, Dynamo, S3, etc). So you can certainly create a function that, when called, executes some bit of functionality (based on the input, or not, as appropriate).
What then matters is how it is called. Per another comment, you can trigger them via Cloudwatch to execute at a scheduled time (so perfect for cron jobs). You can also cause them to trigger based on certain events in AWS (such as S3 uploads; whenever a file lands in S3, spin up a lambda to process it in some way). But more than that, you can stick an HTTP(S) endpoint in front of them to create a RESTful API. You can do this via the AWS API Gateway. You map how the HTTP request gets passed into the lambda, and then your code can process it whenever the HTTP(S) endpoint is hit.
So with this you effectively have a REST API that will scale predictably. There is cost associated with it (and you have to evaluate whether the cost makes sense; it may not if you have already invested in sysops style resources, or if your load is so high that the Lambda + API Gateway cost is prohibitive compared with running equivalent EC2 instances), but that cost scales with use. And there are a few other caveats as well to learn about and be aware of. But if you then rely on other AWS services for things like data storage, messaging, etc (including email sending; have a look at AWS SES) you can create an entire backend without any servers that you, personally, have to maintain or care about.
'Serverless' frameworks tend to focus on the Lambda + API Gateway integration, to provide you with a developer environment that you can run locally, and then with a single command deploy to AWS, getting both your function and your API in place. They generally have no knowledge of other related infrastructure (which you will likely need, though you can likely configure just once and be done with it; unlike a lambda, you're not changing it frequently)