What is it?

As a brief overview, AWS Lambda is a function-based computing service that takes the efforts of provisioning and maintaining its infrastructure out of your hands. With Lambda, you don’t need to worry about scaling your infrastructure and removing unnecessary resources as this is all handled for you. We’ll take a deeper dive into how this service works, but first let’s take a look at why this tool is a worthy addition to your stack.

Advantages

Many of the advantages of using AWS Lambda relates to the advantages of adopting the serverless-approach in general. As mentioned in the intro, a major benefit of going serverless is the time and effort saved from creating and maintaining your infrastructure. AWS provisions and manages the infrastructure your Lambda functions run on, scales the instances to handle times of excessive load, and implements proper logging and error handling. Anyone that’s been involved in the creation or maintenance of infrastructure will understand the gravity of this advantage. Not only is there a large amount of time involved in building a system that suits the needs of your application, there is also a considerable amount of time required to maintain that system as your application evolves. Time saved means quicker time to market for your application, greater agility as your team is able to most faster, and more time spent on more important tasks such as bug fixes or new features.

As for why AWS Lambda is one of the most popular serverless solutions, AWS has done a very good job of ensuring Lambda accommodates applications at scale as well as applications in early stages. For applications with large amounts of load, AWS allows you to run your Lambda function simultaneously with other Lambda functions; meaning, you won’t need to worry about clogged-up queues. Not only that, multiple instances of the same Lambda function can be provisioned and run at the same time. Both advantages ensure that no matter how much load your application is under, Lambda will be able to handle it. Another advantage of using AWS Lambda is that you only pay for what you need, accomodating for applications that are not yet at scale or have widely differing loads. AWS charges you for the number of requests your Lambda functions receive and the time it takes to execute those requests per 100ms. Despite its wide array of advantages, there isn’t a single solution that exists without its share of disadvantages and AWS Lambda is no exception.

Disadvantages

Moving the task of maintaining your infrastructure away from your team and in the hands of a provider results in less control and flexibility, which is the biggest disadvantage of the serverless approach. On top of that, services that help implement the serverless approach come with their own set of infrastructure-related limitations; in Lambda’s case, these limitations are the following:

• Functions will timeout after 15 minutes.
• The amount of RAM available ranges from 128MB to 3008MB with a 64MB increment between each option.
• The Lambda code should not exceed 250mb in size, and the zipped version should be no larger than 50mb
• There is a limit of 1,000 requests that can run concurrently, any request above this limit will be throttled and will need to wait for other functions to finish running.

Whether or not these limitations will impact your application is dependent on the nature of your Lambda functions; usually, the solution is to refactor your Lambda functions to improve their efficiency. If any of these limitations begin to impact your Lambda functions, the first thing to do is to investigate why and whether your functions could be improved. For example, is the reason your function is timing out is that there’s inefficient algorithms involved? Are there any unnecessary dependencies in your Lambda code, causing its size to exceed the limit?

Cost was mentioned in our list of advantages, but although you only pay for what your application requires this does not necessarily result in a cost effective solution; during times of high load, the cost of the same infrastructure on AWS EC2 or other services may be cheaper. The price of other services based on your application’s needs should be considered especially if your application experiences a consistently high load. The final disadvantage worth mentioning is the small latency time between when an event occurs and when the function runs. This small latency times only occurs in some cases — during a cold start. In most cases, these latency times are so minuscule that it’s hardly an issue but it’s still worth considering if your application is already bordering on potential load problems; I’ll talk about cold starts in more detail in a later section.

When to use Lambda?

AWS Lambda is a suitable computing platform for many application scenarios provided that you can write your application code in languages and runtime environments supported by the service. When you want to focus only on your application code, on your business logic, and leave the server maintenance, provisioning and scalability to others for a good price, then you definitely need to migrate to AWS Lambda.

Lambda is perfect for building APIs, together with API Gateway you can efficiently achieve fast time to market and optimize costs. There are different ways for using Lambda functions, different serverless design patterns which everyone could follow depending on their needs.

A variety of tasks could be implemented with Lambda functions. You can create cron job with the help of CloudWatch and automate some processes. There are no restrictions for usage flows (you have for memory and time) and going to full-fledged microservices applications using Lambda is nice and smooth.

The typical example with image resizing and Lambda shows we can create service-oriented actions which don’t have to be running all the time. Even for distributed systems Lambda functions are good choice.

So, you have no need for provisioning and managing of computing resources — try AWS Lambda; you don’t execute heavy processing consuming resources — try AWS Lambda; your code doesn’t execute every second — try AWS Lambda.

How does it work?

If you’ve decided that Lambda may be a worthy addition to your stack, the next step is to understand the inner workings of a Lambda function. On a very basic level, serverless applications are made up of 2 or 3 components; these are event sources, functions and (in some cases) services. An event source encapsulates anything that can invoke a function, such as uploads to an S3 bucket, changes to data state, or requests to an endpoint. When any one of the designated events occurs, your Lambda function will run in its own container. The resources allocated to that container and the number of containers used is determined by the size of the data and the computational requirements of the function, this is all handled by AWS. Once the request is completed, your Lambda function will either return a result back to the invocation source or a connected service, or it could make changes to a connected service (such as a database).

Before you can run a Lambda function, you’ll need to create one and to successfully do so, you’ll need a basic understanding of what’s involved. A Lambda function consists of 3 or 4 parts; the handler function, the event object, the context object and in some cases a callback function. The handler function is the function that will be executed upon invocation, this can either be async or non-async. Asynchronous functions take an event object and a context object whereas non-asynchronous functions take both these objects and a callback function. The event object contains data that was sent when the function’s event was triggered, this includes information such as the request body and the uri, the data that is passed through depends on the invocation service. The context object contains runtime information such as the function name, function version and log group. The callback function is only passed through to synchronous handlers and it takes two arguments: an error and a response. Once the Lambda function is created and pushed up to AWS, it is compressed along with its dependencies and stored in an S3 bucket.

async-handler .js

const fetchData = require('./fetch.js')
exports.handler = async (event, context) => {
return await fetchData(event, context)
}

non-async-handler.js

exports.handler = function(event, context, callback) {
try {
// your code would go here
callback(null, res)
} catch(err) {
callback(err)
}
}

Note: For non-async handlers, function execution continues until the event loop is empty or the function times out.