AWS Lambda: An Introduction to the Serverless World 🌎


Hi Reader πŸ‘‹πŸ½

when people hear serverless they often hear AWS Lambda. This is what this issue is about. Let's learn about Lambda and see some real-world use-cases.

We cover the following topics in this issue:

  1. Introduction to Lambda πŸŽ’
  2. Under the Hood of Lambda πŸ€–
  3. Asynchronous vs. Synchronous Execution πŸ”ƒ
  4. Real World Lambda Use Cases πŸ‘·πŸ½

Lambda Infographics

As always let's start with an overview with the AWS Lambda Infographics.


Lambda Introduction πŸŽ’

AWS Lambda is the OG (Original Gangster) in the serverless space. If somebody is talking about serverless they often mean Lambda. While we're not agreeing with this saying in particular, it is true that Lambda was the initial enabler of the serverless journey we are on.

Lambda removes the need of configuring any infrastructure. Lambda is true serverless. You, as the customer, only bring the code, Lambda is doing the rest.

Under the Hood of Lambda πŸ€–

We are all about covering the fundamentals of services. Let's see what Lambda actually is doing under the hood.

Micro-Containers in the Back Which run Your Code

One thing that is often misunderstood is the fact that serverless services don't have any servers. That is were the naming wasn't super successful. Lambdas execution still runs on a server. You just don't have to manage them as the developer.

Once a request is sent to your Lambda function one of the two things will happen:

  1. Provision a new micro container and deploy the code (cold start)
  2. Re-use an existing micro container (warm start)

As you can guess one is faster than the other (2 πŸ˜‰)

Assigning Resources Takes Time - Cold Starts πŸ₯Ά

Let's take a deeper look at the first scenario. This scenario is called a cold start. You will hear this term a lot when you start researching serverless solutions.

Cold starts are the major trade-off you need to take if you want to work with serverless services. The preparation and deployment of your code in Lambda microcontainers takes time. This time is referred as a cold start.

Lambda needs to download your function’s code and start a new micro-container environment that will then receive and execute it. Afterward, the global code of your function will run. This is everything that’s outside of your handler function. Lastly, your main code is run that’s inside your handler function.

If you compare this to traditional stateful approaches like EC2 or ECS this is one of the main differences. Your ECS task only needs to start once. Lambda needs to start a couple of times.

But cold starts are often not an issue. In interpreted languages like TypeScript or Python cold starts are super short. Additionally, if you have a production application like an API, you will almost always have warm containers running that can serve your users.

We often see architectures where less than 1% of all users face a cold start. It is important to understand this concept since it applies to almost all serverless services.

One Container Serves One Request at a Time

Another important note is that one Lambda container is only able to handle one request at a time.

That means even if you have a running lambda container. As long as this container is not finished with the request, another one needs to spawn.

These are the two main concepts to understand. Understanding this will help you on your serverless & cloud journey in the future ⛷️

Asynchronous vs. Synchronous Invocation πŸ”ƒ

A Lambda function can be executed in an asynchronous and a synchronous way. Let's first understand what the difference actually is:

  • synchronous or blocking: Lambda executes your code but only returns after the execution has finished. You’ll receive the actual response that is returned by the function. An example would be a simple HTTP API that is built via API Gateway, Lambda, and DynamoDB. The browser request will hit the API Gateway which will synchronously invoke the Lambda function. The Lambda function will query and return the item from DynamoDB. Only after that, the API Gateway will return the result. The user who calls this API needs to wait till the Lambda is finished.
  • asynchronous: Lambda triggers the execution of your code but immediately returns. You’ll receive a message about the successful (or unsuccessful, e.g. due to permission issues) invocation of your function. An example would be a system that generates thumbnails via S3 and Lambda. After a user has uploaded an image to S3, they will immediately receive a success message. S3 will then asynchronously send an event notification to the Lambda function with the metadata of the newly created object. Only then Lambda will take care of the thumbnail generation.

A good metaphor here is a restaurant vs. a fast-food chain. If you order in a restaurant your talk to the waiter, place your order and he goes off to create the meal. This is async. You get an immediate response and don't have to wait. At some point you get the food. 🍣
In a fast-food chain you order, and wait till your food is ready. This is synchronous. You need to wait as long as it takes till the food is done. πŸ”

If you’re invoking functions from another place, e.g. another Lambda function, the invocation type depends on how you want to handle results. Synchronous invocation is useful when you need to retrieve the result of the function execution immediately (e.g. for a user-facing API) and use it in your application.

Asynchronous events are more suited for background tasks where no immediate result is required (e.g. creating a thumbnail).

Real World Use Cases πŸ‘·

We talk a lot about using AWS for the Real World. So, let's see some real world examples for Lambda.

Use Case 1: Creating Thumbnails for Images or Videos

Classic approaches to video or image processing involve uploading files to storage and having a server regularly pulling for newly created files.

This will introduce costs as your servers also have idle times if traffic is not constant but with periods of high or low traffic.

Putting video conversion or thumbnail generation into the hands of Lambda, while uploading files to S3 gives you a completely different approach. You’re able to attach Lambda invocations to S3 object lifecycle events like ObjectCreated. With this, new files will automatically trigger your function with an event that contains all necessary information about the lifecycle event and file.

You won’t pay for any idle times, as only computations will be billed with Lambda.

Use Case 2: Creating Backups and Synchronizing Them into Different Accounts

Lambda is the perfect tool for creating backups and synchronizing them between different storages or even accounts to have redundancy and with that high security.

Looking at the previous image and video processing use case: you can also directly synchronize files based on lifecycle events and event notifications.

Use Case 3: Scraping and Crawling Web Pages and APIs

You can use Lambda to scrape and crawl web pages or other data sources to gather information for analysis or other purposes.

A common example for which you can find a lot of blog posts is to automatically update your Twitter banner based on recent followers, the blog post you’ve published recently, or any other information you want to show in near real-time.

Lambda can gather the required information from the Twitter API, create a new banner with updated information (e.g. via the sharp library), and then upload the results to your accounts again. The regular invocation of your function is taken over by an EventBridge rule, for example with a schedule for every minute.

Final Words

Lambda is everywhere. It is definitely one of the compute services you will work with in all different roles. Starting from Cloud Engineeers, Software Engineers, or Support Engineers. You will need to handle workloads on Lambda.

Learning how Lambda works in detail makes it much easier to also understand how other serverless services are working.

We hope we could give you some insights in how Lambda is working.

The future of AWS Fundamentals

After the successful launch of our book we finally had the chance for a meeting to celebrate the launch. We also discussed the future of AWS Fundamentals and we have many ideas!

The focus right now will be to create high-quality content on the newsletter and on our blog. We love to follow a visual approach of learning so we will focus on that with AWS Hot Tips, Cheat Sheets, and even more infographics.

Let us know what you want to hear about next!

Cheers,
Sandro & Tobi ✌🏽

PS: If you want to dive deeper check out our latest blog posts about Lambda:

AWS for the Real World

Join our community of over 9,300 readers delving into AWS. We highlight real-world best practices through easy-to-understand visualizations and one-pagers. Expect a fresh newsletter edition every two weeks.

Read more from AWS for the Real World

AWS FOR THE REAL WORLD ⏱️ Reading time: 6 minutes 🎯 Main Learning: Understanding Amazon Aurora DSQL pricing structure including DPUs, storage costs, and free tier πŸ“ Blog Post πŸŽ₯ YouTube Video Hey Reader πŸ‘‹πŸ½in December 2024 AWS announced the preview of the serverless database DSQL and just in May it was generally available. With the announcement of the general availability, the pricing was also announced. The pricing is not super straightforward, so let's dive into it. Click to watch this video...

AWS FOR THE REAL WORLD ⏱️ Reading time: 8 minutes 🎯 Main Learning: Building & Testing Lambda@Edge Functions with LocalStack πŸ“ Blog Post Hey Reader πŸ‘‹πŸ½we hope you have a great week! End of last year the CDN Edgeio was deprecated. Tobi's client company used it and the only thing that saved his day was CloudFront and Lambda@Edge Functions. But we realized that testing them and executing them locally is a pain. When we started to look for a solution we found Localstack - let's see how we can use...

AWS FOR THE REAL WORLD ⏱️ Reading time: 8 minutes 🎯 Main Learning: Migrating from Edgio to CloudFront πŸ“ Blog Post πŸ’» GitHub Repository Hey Reader πŸ‘‹πŸ½After a busy week in Prague, both Tobi and I (Sandro) delivered our talks and we got quite some good feedback! We will share them in a separate newsletter soon.But this newsletter is all about accessing S3 within a VPC via Gateway endpoints vs. Internet routing. We know these networking issues are not the fanciest onces (looking at you AI) but...