AWS Lambda Deployment Options
Table of contents
- There are many ways to make a taco
- Getting familiar with ingredients
- Method # 1: Fast and furious - Using one of provided runtimes
- Method # 2: Chef's Special - Using a custom runtime
- Method # 3: Homemade recipe - Using a container image
- The choice is yours
There are many ways to make a taco
As with many things in life, when it comes to deploying AWS Lambda functions, there is more than one way to get the job done. In this post, we will explore available methods for deploying code to Lambda functions and find out when it is more appropriate to use each method.
Getting familiar with ingredients
Before looking into available methods, let’s go over the components of a Lambda function. Lambda function consists of 3 components that allow the function to run:
- Operating system - the component that provides a platform for running the runtime and the handler.
- Runtime - the component that receives events from AWS Lambda service, executes handler, and routes responses received from the handler back to the AWS Lambda service.
- Handler - the code that processes events and returns responses.
Method # 1: Fast and furious - Using one of provided runtimes
A developer chooses one of the provided runtimes and implements the handler.
Lambda supports multiple major programming languages and environments through provided runtimes. Each runtime contains a language-specific environment that passes events to the handler and relays responses back to the AWS Lambda service. After choosing a runtime, a developer is only responsible for implementing the handler.
Currently Lambda provides runtimes for the following popular programming languages and environments:
- Node.js,
- Python,
- Java,
- .NET,
- Go,
- Ruby.
Here are the advantages of using provided runtimes:
- This is the simplest and fastest way to build and deploy Lambda functions. The code of the function does not need to be aware of AWS Lambda runtime API. It only needs to handle events and return responses. This allows developers to immediately start working on application’s specific functionality without writing any infrastructure code.
- This method will create the smallest deployment package optimized for the AWS environment which will give you shortest deployment and cold start times.
Here are the main disadvantages of this method:
- Only several programming languages and environments are supported. For example, there is no provided runtime for the latest version of Node.js environment.
- The requirement to follow runtime deprecation schedule, and update functions to new versions of runtime as old versions are getting phased out.
Here is the list of scenarios when it is appropriate to use this method:
- Your programming language and environment are supported by one of provided runtimes;
- You are building functions for serverless applications that will continue to evolve and will be actively maintained in the future;
- You are creating a prototype.
This method is the best way to get started with building lambda functions if this technology is a new one for you.
Method # 2: Chef's Special - Using a custom runtime
A developer provides a runtime and a handler.
This method allows running any code as a function as long as this code can run on Amazon Linux. In addition to handling events and returning responses, you will be responsible for receiving requests from AWS Lambda service and sending back responses using Lambda runtime API. This may feel intimidating at first, but AWS has decent documentation and you may be able to reuse the runtime implementation if one is already available for your programming language and environment. For example, AWS provides tools and examples for building lambda functions using custom runtimes for .NET and C++.
Here are the advantages of this method:
- It allows to run almost any code as a lambda function as long as the code can run on Amazon Linux. There are no other restrictions on versions of programming languages or runtime environments;
- It allows implementing custom initialization and shutdown behavior;
- The deprecation schedule of custom runtimes depends only on Amazon Linux depreciation schedule, which is typically supported much longer than runtimes for specific versions of programming languages and environments.
Here are the disadvantages of this method:
- It requires additional code and configuration to implement communication with Lambda runtime API unless AWS provided required tools and examples for your programming language and environment;
- The increased size of deployment packages leads to slightly longer deployment times and cold start times.
Here is the list of scenarios when it is appropriate to use this method:
- Provided runtimes do not support the required version of programming language or environment, and the unzipped deployment package size does not exceed 250 MB;
- There is a need to avoid dependency on depreciation schedules of provided runtimes.
Method # 3: Homemade recipe - Using a container image
A developer creates a container image that includes the operating system, a runtime and a handler.
A container image can be created using one of three image types:
- AWS base image for Lambda. These images include the operating system and the runtime. The developer is responsible only for implementing the handler. AWS provides tools for some programming languages and environments that completely automate the process of building such images, making creating them as easy as creating packages for provided runtimes;
- AWS base image for custom runtimes. These images are based on the Amazon Linux operating system. The developer is responsible for adding the runtime and implementing the handler;
- Non-AWS base image. The developer is responsible for choosing the operating system, adding runtime and implementing the handler.
The advantages of this method:
- It provides maximum flexibility for customization of the function's environment;
- It allows choosing from multiple levels of abstraction: a developer can choose between building own image, building runtime and handler, or building only handler;
- It allows using the maximum size of deployment package: the maximum supported uncompressed image size can be up to 10 GB.
The disadvantages are:
- Increased complexity of build process due to the requirement of using containerization tools for building an image;
- Large package sizes that take longer to deploy. Note that this disadvantage can be mitigated by using image layers.
Here is the list of scenarios when it is appropriate to use this method:
- Provided runtimes do not support the required version of a programming language;
- The size of dependencies required by your Lambda function exceeds 250 MB;
- It is necessary to customize the environment for your Lambda function.
The choice is yours
Congratulations! You just learned all available methods for creating and deploying Lambda functions in AWS. Let’s do a quick recap.
There are three methods for deploying Lambda functions:
- The easiest method to build a function is by using one of the provided runtimes. All you need to do is implement a handler using one of several supported programming languages and environments;
- Custom runtime allows using almost any programming language and environment but requires implementation of a runtime and a handler;
- Custom container image allows complete customization of a function's environment by choosing the operating system, a runtime and a handler.
No one of these methods is superior to the others. Each method has its own advantages and limitations. So, when implementing a new Lambda function, remember to choose the approach that best suits requirements of your particular project.