Serverless and cloud computing have seen a major uptake in recent years, becoming industries unto themselves, with AWS Lambda leading the way. Companies are making the switch to serverless architecture for shorter time to market and decreased operational costs, but for developers the advantage lies in the ability to offload the burden of managing infrastructure to serverless platforms, so you can focus on building even better apps.
But we’re getting ahead of ourselves. In this post, we will look at:
- What is AWS Lambda?
- What are serverless applications?
- How does AWS Lambda work?
- AWS Lambda concepts
- Events that trigger AWS Lambda
- Languages supported by AWS Lambda
- When to use AWS Lambda
- When not to use AWS Lambda
- Limitations to AWS Lambda
- Alternatives to AWS Lambda
- Supporting AWS services
- How to get started
- Best practices
What is 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.
What are serverless applications
Serverless applications, at the most basic technical level, 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, network servers (such as web servers or message brokers) and business logic code, serverless applications only need to provide the code that should 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.
How does AWS Lambda work?
Clients send data to Lambda. Clients could be anyone who’s sending requests to AWS Lambda. This could be an application or other Amazon services.
Lambda receives requests and depending on the size, amount, or volume of the data, 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.
With an increased number of requests, an increasing number of containers are created. If the number of requests reduces, the number of containers are reduced as well.
AWS Lambda concepts
Function
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.
Runtime
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.
Event
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
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.
Trigger
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
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.
Events that trigger AWS Lambda
- HTTP requests via Amazon API Gateway
- Modifications to objects in Amazon S3 buckets
- Updates to a DynamoDB Table
- State transitions in AWS Step Functions
Languages supported by AWS Lambda
AWS Lambda supports:
AWS also provides a Runtime API which allows you to use any additional programming languages to use your functions.
It’s also suggested that you check deprecated runtimes to ensure you’re using the most updated runtime. Acceptable runtimes for a few of the above languages are: Java 11, Python 3.8, and Node.js 12.x. Some deprecated runtimes include: Node.js 8.10 and Python 2.7.
Keep the learning going.
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.
Running Serverless Applications with AWS Lambda
When to use AWS Lambda
Maximizing throughput
Lambda is great for use cases where throughput is critical and the tasks parallelise nicely. Typical web requests for dynamic content, involving access to a back-end database, or some user data manipulation usually fall into this category. Automatic email replies or chatbots are also a nice example. Any single request taking a few hundred milliseconds more than average won’t be noticeable to typical users and Lambda will ensure that everyone gets served relatively quickly regardless of traffic spikes.
Splittable, longer-running tasks
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.
High availability tasks
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 yet it’s not critically important if they are finished in one second or two seconds.
When not to use AWS Lambda
Latency guaranteed tasks
Lambda is currently not suitable for tasks that require guaranteed latency, such as in high-frequency trading systems or near-real-time control systems. If a task must be handled in under 10 or 20 ms, it’s much better to create a reserved cluster and have services directly connected to a message broker.
Longer-running tasks
Another category where Lambda isn’t suitable right now is tasks that could potentially run for longer than 15 minutes. One notable example is video transcoding for large files. Connecting to a socket and consuming a continuous data feed is also not a good use case for Lambda, due to the time limit.
Tasks that demand high-processing power
The third category where you should not use Lambda right now is tasks that require a huge amount of processing power and coordination. For example, video rendering. Tasks like that are better suited to a reserved infrastructure with a lot of CPUs (or even GPUs).
Tasks that require no on-demand computation
Lastly, tasks that require no on-demand computation, such as serving static web files, are a poor use case for Lambda. In theory, 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.
Limitations of AWS Lambda
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
Alternatives to AWS Lambda
Azure Function
Microsoft is one of the newer players in the serverless realm. It wasn’t until March 2016 that they entered the serverless app environment with the launch of Microsoft Azure Functions. Both Lambda and Azure support Node.js, Python, and C#, but Azure Functions also support F# and PHP. They also both support automatic scaling.
Google Cloud Function
Launched in the beginning of 2016, Google Cloud Function was created in response to well-received Lambda. Languages supported by GCF are Node.js, Python, Go. Whereas Lambda allows for unlimited functions perproject, GCF allows for 1,000 functions per project.
See more alternatives here.
Supporting Amazon AWS services
EC2
Amazon EC2 (Elastic Compute Cloud) is an IaaS (Infrastructure as a Service) that provides virtualized computing resources. Using Amazon EC2 eliminates your need to invest in hardware up front, so you can develop and deploy applications faster. Read more about EC2.
S3
Amazon S3 (Simple Storage Service) is the cloud storage service of AWS. It allows you to store and retrieve any amount of data, at any time, from anywhere on the web. Read more about S3.
CloudFront
CloudFront is a content delivery network service that speeds up distribution of your static and dynamic web content, such as .html, .css, .js, and image files, to your users. Read more on CloudFront.
Amazon API Gateway
Amazon API Gateway is an AWS service for creating, publishing, maintaining, monitoring, and securing REST, HTTP, and WebSocket APIs at any scale. Read more on Amazon API Gateway.
SAM (Serverless Application Model)
An open-source framework for building serverless applications. It is a set of products that simplify developing, testing, and deploying applications using AWS Lambda. One part of SAM runs on developer machines and build servers, helping to prepare for deployment. Another aspect of SAM runs in AWS data centres during the deployment process. More on SAM.
How to get started with AWS Lambda
Step 1
Head on over to their sign in page. If you don’t have an AWS account, go ahead and create one. Then find “Lambda” under “Compute” and click to open the AWS Lambda Console.
Step 2
Select a Lambda blueprint. In the AWS Lambda console, select “Create a Function”.
Step 3
Configure and create your lambda function. Here is where you enter the basic information about your Lambda function (i.e. things like name, role, and role name). Then click “create function”.
Step 4
Invoke Lambda function and verify results. Click “configure test event” in the upper right hand drop down menu.
Best practices for AWS Lambda
When to VPC-Enable a Lambda Function
You should only enable your functions for VPC access when you need to interact with a private resource located in a private subnet. An RDS instance is a good example.
Deploy Common Code to a Lambda Layer (i.e. the AWS SDK)
If you intend to reuse code in more than one function, consider creating a Layer and deploying it there. A great candidate would be a logging package that your team is required to standardize on.
Watch Your Package Size and Dependencies
Remove all unnecessary items, such as documentation and unused libraries.
Running serverless applications with AWS Lambda
Ready to get your start with serverless computing? Gojko Adzic is the author of our latest course, Running Serverless Applications with AWS Lambda. Adzic is one of the 2019 AWS Serverless Heroes, the winner of the 2016 European Software Testing Outstanding Achievement Award, and the 2011 Most Influential Agile Testing Professional Award. Adzic has written many award winning books such as Specification by Example and Serverless Computing; it's safe to say when it comes to serverless computing, Adzic knows what he’s talking about.
In this course, you will learn how to run serverless applications using AWS Lambda. You’ll start with the basics such as creating a web service where you’ll learn the steps to use AWS Serverless Application Model (SAM), a set of products that simplify developing, testing, and deploying applications using AWS Lambda. This is something most courses won’t cover. You’ll then move on to more advanced topics such as handling HTTP Requests, using external storage, and managing sessions and user workflows. By the end of this course, you will be ready to work with AWS Lambda in a professional setting, and you’ll have a great, transferable skill that employers will love to see.
Happy learning!
Top comments (0)