Welcome to the serverless world, one of the biggest mindset shifts in the cloud. Until now, there was always a server involved: you started it, configured it, scaled it, repaired it. With AWS Lambda you forget about all that: you just write the code you want to run, and AWS takes care of the rest. In this subchapter, you'll understand how this model works.

Let's remember what you've done so far with EC2 (Chapter 4) and Auto Scaling Groups (Chapter 13): you worried about servers. Even though AWS managed the hardware, you had to think about how many instances, what type, how to scale them, how to repair them.

With Lambda, the unit is no longer the server: it's the function. You upload a piece of code (a function), and AWS runs it when needed. There is no server to manage. That's where the name "serverless" comes from: it's not that there are no servers, it's that they're not your problem; AWS adds and removes them for you, invisibly.

Important clarification: "serverless" does not mean "no servers." Servers exist, but they are completely hidden and managed by AWS. You don't see them, you don't configure them, and you don't pay to have them running idle.

The Lambda model is easy to understand with one idea: your code only runs when something happens, and only for as long as it takes to do its job.

Let's compare it to a traditional server:

• An EC2 server is always on, waiting for requests. You pay for all the time it's on, even if no requests arrive.
• A Lambda function only "exists" when there's work. If no one invokes it, it doesn't run and you pay nothing.

Analogy: a server is like having a taxi with the engine running waiting all day at the door: you pay for the gas even if you don't go anywhere. Lambda is like ordering a taxi via app: it shows up just when you need it, takes you, and you only pay for that ride. The rest of the time, you pay nothing.

There's no operating system to patch, no instances to size, nothing to repair. AWS takes care of everything "under the hood." You only focus on your code.

If 1 request arrives, AWS runs 1 function. If 1,000 arrive at once, AWS runs 1,000 functions in parallel, automatically. You don't configure Auto Scaling Groups or policies (Chapter 13): scaling is immediate and transparent, managed by AWS.

This is the star economic advantage. You pay for the number of executions and for the time each one takes (in milliseconds). If your function doesn't run, you pay nothing. This can greatly reduce costs for intermittent or unpredictable workloads.

A Lambda function is basically a function in your favorite language (Python, Node.js, Java, Go...) with a specific shape: it receives an event as input and returns a response. Here's a simple example in Python:

• event: the input data (what triggered the function and with what information).
• context: information about the execution (how much time is left, identifiers, etc.).
• What return returns is the response.

AWS calls this function every time the event that triggers it occurs. You don't worry about where it runs or how many copies there are.

Lambda shines in many scenarios, but it's not for everything:

We'll see the limits and anti-patterns in detail in subchapter 14.5. For now, keep the general idea.

• Lambda changes the unit of work: from the server to the function. You upload code and AWS runs it; you don't manage servers.
• Serverless doesn't mean "no servers," but that the servers are invisible and managed by AWS: they're not your problem.
• The model is on-demand: your code only runs when an event occurs, and only for as long as it takes. If it's not invoked, it doesn't run.
• Three advantages: you don't manage servers, automatic and instant scaling (1 or 1,000 parallel executions), and you only pay for what you use (if it doesn't run, you don't pay).
• A function receives an event as input and returns a response; it fits short tasks, intermittent traffic, and event processing.

In the next subchapter, we'll see what can trigger a Lambda function: the triggers (API Gateway, S3, DynamoDB, SQS...).