AWS Lambda Meets Container Images

Serverless architectures are all about offloading as much operational overhead to the cloud as possible. For the past six years, this primarily meant writing business logic as small pieces of code (< 250MB in size) that are zipped up and given to the cloud to run on demand.

This simple model deceptively belies the true power of serverless applications. Because modern applications are often composed of a set of small microservices, each compute resource can itself be minimal in size. Companies from startups to multinational banks are building and refactoring apps to serverless models.

However, adopting serverless means adopting lots of changes to engineering processes. This can be a significant point of friction that prevents organizations from jumping on the serverless bandwagon. To grow the success of a new technology, there needs to be an easy path to transition to it.

Enter container image support for AWS Lambda Functions

You may work at an engineering organization that has a lot of mature processes for container-based applications. There may be standardization where every application is packaged into a container image that is then sent through various tools and services to be scanned for vulnerabilities and then deposited into safe Container Image repositories.

If you wanted to adopt serverless in these organizations you'll often face a gantlet of cultural skepticism that is borne of the pain caused by the adoption of container-based applications only a few short years earlier. Adopting a new technology that affects the entire build toolchain is not trivial. Security scanning tools built for Container Images don't work for AWS Lambda zip packages, as one simple example.

But what if you could get the best of both worlds? What if you could keep your Container Image toolchain but adopt Lambda Functions for runtime? This is what is possible today with Container Images for Lambda Functions! You can publish Container Images to an AWS ECR Repository (or sync them over from your existing third-party repository) and tell Lambda to run the image.

🚧 Note: Before you get too excited about the possibility of taking existing Container Images and running them unmodified, see the caveat below.

But wait! There's more...

On top of the ability for Lambda to run functions packaged as container images, Lambda also will be able to execute images up to 10 GB in size (up from 250 MB for zip packages). This greatly increases the capabilities for Lambda to run workloads of any kind, including machine learning applications that need a lot of seed data.

How do I package my Lambda function as a container image?

Here at Stackery our goal is to help your engineering organization adopt serverless using best practices formed around the AWS Well-Architected Framework. We're excited to be a launch partner for Container Image support for AWS Lambda. You can use Container Images in two ways with Stackery.

Using existing AWS ECR Repositories

You may already have a sophisticated toolchain for building and publishing Docker Images. If you publish or sync these images to an AWS ECR repository you can configure Lambda Functions within Stackery to use the images from this repository directly.

With Stackery's built-in environment management, you can also easily parameterize the ECR repo to use different images for production, staging, and dev/test/qa environments.

Building Images

If you don't already have a mature toolchain for building Container Images but want the benefits they can provide (e.g. the larger image size), Stackery will scaffold a directory for your image sources inside your repository, add an AWS ECR Repository to your stack, and add an AWS CodeBuild Project to build the image for you on every deployment[gif]This will get you up and running with a function packaged as container image in no time!

An Important Caveat

One thing that is bound to happen when people hear "AWS Lambda" and "Containers" in the same sentence is the idea that you can run existing, unmodified HTTP (or otherwise) container-based applications as services via Lambda. This isn't true.

This important launch enables the use of existing Container Image tooling for building and packaging Lambda Functions, but the Functions will still need an entrypoint that receives a Lambda Event and returns and appropriate response before being put to sleep.

However, if you do want to run container-based services in a well-architected fashion without the challenges of creating and maintaining complex Kubernetes infrastructure, let Stackery help you set up services using AWS ECS Fargate. No matter how you need to build your architecture, Stackery has you covered. 😃