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:
As always let's start with an overview with the AWS Lambda Infographics.
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.
We are all about covering the fundamentals of services. Let's see what Lambda actually is doing under the hood.
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:
As you can guess one is faster than the other (2 π)
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.
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 β·οΈ
A Lambda function can be executed in an asynchronous and a synchronous way. Let's first understand what the difference actually is:
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).
We talk a lot about using AWS for the Real World. So, let's see some real world examples for Lambda.
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.
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.
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.
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.
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:
We teach AWS for the real world - not for certifications. Join more than 10,500 developers learning how to build real-world applications on AWS.
AWS FOR THE REAL WORLD β±οΈ Reading time: 4 minutes π― Main Learning: Which AWS services are worth your time and which ones to skip π¬ Watch on YouTube Hey Reader ππ½ a new week, new AWS video coming out. I (Sandro) used all of my knowledge from the past six plus years building AWS solutions, ranking the services I actually use and the services I hate. For some I've changed my mind A LOT over the years (e.g. DynamoDB). Let me know what you think and check it out.Here you go AWS News But first of...
AWS FOR THE REAL WORLD β±οΈ Reading time: 12 minutes π― Main Learning: The 11 most impactful AWS releases from the past 12 months that have nothing to do with AI. π Blog Post Hey Reader π Every re:Invent recap, every AWS blog, every newsletter from the past year has been dominated by one topic. You know which one. But while everyone was writing about agents and foundation models, the core infrastructure layer kept moving. Quiet releases. No keynote fanfare. Things that actually affect your...
AWS FOR THE REAL WORLD β±οΈ Reading time: 5 minutes π― Main Learning: Deploy AWS's open-source TEAM solution for temporary admin access with approval workflows π¬ Watch on YouTube Hey Reader ππ½ I hope you had a great weekend and have a great week ahead. One thing I see over and over again in AWS setups: admin permissions are either handed out way too easily or way too hard. There is no middle ground. In other systems this was already solved. You shouldnβt have to DM somebody for admin access. We...