Learn AWS Lambda without scrubbing through videos or documentation. Educative’s text-based courses are easy to skim and feature live coding environments - making learning quick and efficient.
Cloud computing has revolutionized how organizations build and deploy their applications by providing scalable and on-demand resources over the internet. Serverless computing is a commonly used model where we can run applications on the cloud without worrying about provisioning or managing the underlying infrastructure.
At the most basic technical level, serverless applications are software that runs in an environment where the hosting provider is fully responsible for infrastructural and operational tasks. These include receiving network requests, scaling the computing infrastructure on demand, monitoring, and recovery.
Instead of containers bundling application business logic with an operating system, they bundle network servers (such as web servers or message brokers) and business logic code. Serverless applications only need to provide the code to run when an event happens and configure the triggers in the execution environment to call that code.
In the Amazon Web Services cloud, the execution environment for serverless code is called AWS Lambda.
AWS Lambda is a serverless computing service, or FaaS (Function as a Service) provided by Amazon Web Services. It supports a wide array of potential triggers, including incoming HTTP requests, messages from a queue, customer emails, changes to database records, user authentication, messages coming to web sockets, client device synchronization, and much more. AWS Lambda also helps you to focus on your core product and business logic instead of managing the operating system (OS) access control, etc.
Because application developers do not package or distribute the server code to control a network socket in AWS Lambda, their applications are serverless. The buzzword ‘serverless’ is a bit misleading, as there are still servers in a serverless environment.
Lambda functions are executed in response to triggers, such as events generated by other AWS services. Each trigger includes an invocation event, which includes data, typically in the form of a JSON packet, and its contents vary depending on the service. For example, a trigger generated when an object is uploaded in a S3 bucket contains information like the bucket name and object key.
Lambda receives requests, and depending on the data's size, amount, or volume, it runs on the defined number of containers. Requests are then given to a container to handle. A container contains the code the user has provided to satisfy the query.
An increasing number of requests creates an increasing number of containers. If the number of requests decreases, the number of containers also decreases.
AWS Lambda supports various programming languages like Java, Python, Ruby, Node.js, and .NET (C# and PowerShell). It also provides a Runtime API that allows you to use additional programming languages to perform your functions.
In addition to this, we can also run container images in a Lambda function.
A Lambda function is invoked when some event is generated in the AWS environment. Some examples of the events that can trigger a Lambda function are given below:
Modifications to objects in Amazon S3 buckets
Messages published to an SNS topic
State transitions in AWS Step Functions
Some of the main concepts related to AWS Lambda are as follows:
A function is a resource that runs your code in AWS Lambda. Functions contain code that process events, and a runtime that passes requests and responses between Lambda and the function. You provide the code, and you can use the provided runtimes or create your own.
Lambda runtimes allow functions in different languages to run in the same base execution environment. You configure your function to use a runtime that matches your programming language.
An event is a JSON formatted document that contains data for a function to process. The Lambda runtime converts the event to an object and passes it to your function code. When you invoke a function, you determine the structure and contents of the event. When an AWS service invokes your function, the service defines the event.
Concurrency is the number of requests that your function is serving at any given time. When your function is invoked, Lambda provisions an instance of it to process the event. When the function code finishes running, it can handle another request. If the function is invoked again while a request is still being processed, another instance is provisioned, increasing the function’s concurrency.
A trigger is a resource or configuration that invokes a Lambda function. This includes AWS services that can be configured to invoke a function, applications that you develop, and event source mappings.
Lambda layers are an important distribution mechanism for libraries, custom runtimes, and other important function dependencies. This AWS component also helps you to manage your development function code separately from the unchanging code and resources that it uses.
Keep the learning going
Keep the learning going
Lambda is great for use cases where throughput is critical, and the tasks parallelize nicely.
Typical web requests for dynamic content involving access to a back-end database or user data manipulation usually fall into this category. Automatic email replies or chatbots are also nice examples.
With Lambda, occasional cold starts may add a few hundred milliseconds to a request, but this delay is generally unnoticeable to users. Lambda’s automatic scaling also ensures that users are served quickly, even during traffic spikes.
Longer on-demand computational tasks that can execute in less than 15 minutes or could be split into independent segments that take less than 15 minutes are also a good use case for Lambda.
In these cases, the few hundred milliseconds required for Lambda functions to start won’t make an important difference to processing time. Some nice examples of tasks that fall into this category are file format conversions, generating previews or thumbnails, and running periodic reports.
Tasks that need high availability and good operational infrastructure but do not need to guarantee latency are also a great use case for AWS Lambda. This includes payment notifications from external systems, for example, PayPal or Stripe.
These notifications must be handled reliably and relatively quickly; they might have unpredictable traffic patterns, and it’s not critically important if they are finished in one or two seconds.
There are four important technical limitations that you need to consider when evaluating whether something should run in Lambda:
No session affinity
Non-deterministic latency
Execution time-limited to 15 minutes
No direct control over processing power
Lambda is unsuitable for tasks requiring guaranteed low latency, such as high-frequency trading systems or near-real-time control systems. For tasks that must be handled within 10 to 20 milliseconds, using a reserved cluster and connecting services directly to a message broker is preferable.
Another category where Lambda is not ideal includes tasks that could run longer than 15 minutes. One notable example is video transcoding for large files. Additionally, connecting to a socket and consuming a continuous data feed is not a good use case for Lambda due to the time limit.
A third category where Lambda is not ideal is for tasks that require extensive processing power and coordination, such as video rendering. These tasks are better suited to dedicated infrastructure with significant CPU or GPU resources.
Lastly, tasks that require no on-demand computation, such as serving static web files, are a poor use case for Lambda. Theoretically, it’s possible to use Lambda as a web server and send images and CSS files to clients, but this is a waste of money.
It is much cheaper and faster to use a specialized product for that, for example, a content delivery network.
Now that we have learned about AWS Lambda and its different components let’s look at an example of how to use AWS Lambda to help us detect and remove Personally identifiable information (PII) from a document uploaded in an S3 bucket. To do this, we’ll have to configure the following resources:
S3 bucket: First, we must create an S3 bucket to upload our documents.
IAM role: Then, we’ll create an IAM role allowing our Lambda function to fetch and upload objects from an S3 bucket. This will allow our Lambda function to receive the documents available in the S3 bucket and then upload a document without any PII in another bucket.
Lambda function: We’ll configure a Lambda function in any programming language we are comfortable working with and perform the following steps:
Attach the role we created to our function to allow the Lambda function to fetch data from S3.
Provide a code for PII detection to AWS Lambda and deploy it.
Add a trigger to our Lambda function that will invoke it whenever an object is uploaded to our S3 bucket.
Once we have configured all the resources mentioned above, we’ll have to test them to ensure they work as expected. We can also enable AWS Cloudwatch logs to better understand how our function is performing.
Following is a high-level architecture diagram of the resources we’ll have to configure for this use case.
Following are some of the best practices we should keep in mind while working with Lambda functions:
Environment variables: We should use environment variables rather than hardcoding parameters, such as the name of an S3 bucket our function uses.
Recursive invocation: We should avoid scenarios where a Lambda function invokes itself, as this could lead to an unintended volume of function invocations and greatly increase costs.
IAM policies: Ensure that the policies you use to create an execution role for AWS Lambda are not overly permissive.
Using CloudWatch: Amazon CloudWatch can give us insights about our function’s health and performance. We can use these metrics to create alarms if our function works unexpectedly.
This was your first step toward an exciting cloud computing career. Some next topics to look at are:
HTTP request implementations
External storage management
Utilizing Lambda Layers
Workflow and session management
Educative offers a wide range of Cloud Labs, with access to the AWS console and step-by-step instructions that give you hands-on experience building solutions using AWS Lambda.
To help you along that journey, Educative has created the course Running Serverless Applications with AWS Lambda.
This course by award-winning serverless computing author Gojko Adzic gives you hands-on experience with advanced AWS topics. By the end of the course, you’ll be an expert in managing user workflows, handling HTTP events, and designing your robust applications.
In addition, Educative offers a wide range of Cloud Labs with access to the AWS Management Console and step-by-step instructions for deploying AWS solutions.
Happy learning!
Free Resources