An introductory thread on AWS Lambda, based on what I’ve learned so far.

ƛ

Lambda is part of AWS’ serverless architecture.

You could also describe Lambda as Function as a Service or FaaS.

So what do serverless and FaaS actually mean?

1/

Serverless doesn’t mean no servers involved, it just means you don’t have to think about those servers.

Don’t have to manage them, provision them, upgrade them... nothing.

AWS does all that for you.

2/

With Lambda, all you have to think about is individual functions.

You write and deploy functions. That’s it. That’s your only responsibility.

3/

Your functions are triggered by events.

These can come from all sorts of places.

Here’s one example.

4/

A user makes a request to your API, which is managed by AWS API Gateway

That particular endpoint is mapped to a Lambda function

The user calls the endpoint, the Lambda function gets invoked

5/

That Lambda function could call ANOTHER Lambda function

Or write to a database

Or call another AWS service

Or return a response

6/

Another example.

A user uploads a new image to S3 (which is AWS’ simple storage solution)

That upload triggers a Lambda function, which creates a thumbnail version

7/

After creating the thumbnail, the Lambda function does two things:
- Uploads the thumbnail to S3
- Writes the metadata of the image to your database

Boom. Simple image transformation.

8/

You thus can compose a full API by creating individual Lambda functions

These are all managed separately.

You can update each one individually, and your “deploy process” is mostly just uploading the new code

Thus… Function as a Service

9/

Lambda functions are versioned and aliased

This makes updating safe and easy.

What does this look like?

10/

You make a Lambda function. It’s on version 1 (v1)

You alias v1 as “prod”

All requests are routed to “prod”, so your function is now being invoked by real users

11/

You make a new version of your function and upload it to Lambda. That’s v2.

You alias v2 as “test”

The “prod” alias is still on v1. Users are still interacting ONLY with v1

12/

You test v2 thoroughly, and when you’re happy, you can make the “prod” alias to v2.

(You can also do partial allocation i.e. route 60% traffic to v1, 40% of traffic to v2 and slowly ramp up v2)

13/

So that’s the workflow.

Individual functions, triggered by events.

But what makes Lambda particularly appealing is how pricing works

14/

When you deploy a typical back-end application, you deploy instances of it to servers

Depending on your setup, you have to manage those instances and servers

How much management? Depends

15/

But at the very least, you have to keep your instances running… all the time

The application has to be running to be ready to receive requests

That costs $$$

16/

With Lambda, it’s different

You only pay when your functions are INVOKED

So if a function isn’t called… you pay nothing for it

So zero thinking about servers, thus… serverless.

17/

Your functions are always ready to be invoked. Always.

And they scale out to meet your needs.

If you have 0 requests one second and 10,000 requests the next.. Lambda is ready for it

18/

Easy scaling + very cheap.

That’s a powerful combination.

(Though note that Lambda functions should have short execution times i.e. not for long running tasks)

19/

In conclusion, Lambda is neat because it:
- Allows you to deploy individual functions
- Allows those functions to easily interact with other AWS services
- Is very cheap
- Scales instantly

Anything I missed? Let me know.