DockerCon 2021 - Building AWS Lambda functions from container images

You can now build AWS Lambda functions from container images!
Attend this session to learn how it works, see it in action, and find out how you can combine the power of event-driven serverless computing and your existing container image tooling.This session covers one of the most requested new features for AWS Lambda: container image support. With container image support, developers can now package their Lambda functions and required dependencies using familiar container image tooling. You can also build and test your functions using familiar tools and services to analyze their contents and perform audits. Learn about the new developer workflow that is possible with this capability and how to potentially improve your continuous integration and deployment pipelines. Lastly, hear an explanation of container image security and how to share container images inside your organization.

Transcript

1. Julian Wood Building AWS Lambda functions from container images Senior Developer Advocate AWS Serverless @julian_wood
2. Today’s focus:
3. Container image support for AWS Lambda! Today’s focus:
4. Serverless applications Event source Services (anything) Changes in data state Requests to endpoints Changes in Resource state Function Node.js Python Java Go Ruby .Net (C#/Powershell) Custom Runtime API
5. Anatomy of a Lambda function Handler function Function to be executed upon invocation Event object Data sent during Lambda function invocation Context object Methods available to interact with runtime information (request ID, log group, more) CODE EDITOR let response; exports.handler = async (event, context) => { try { response = { 'statusCode': 200, 'body': JSON.stringify({ message: 'hello world’, }) } } catch (err) { console.log(err); return err; } return response };
6. AWS Lambda container image support Package and deploy functions as container images • Why use Lambda • Lambda container image benefits • Working with Lambda container images • Developer workflow • What changes and what stays the same
7. Why use Lambda?
8. Why Lambda? Operational support AWS Lambda is the general compute option that provides the greatest level of operational support by AWS Designed to simplify high availability, scale and security concerns
9. AWS manages Customer manages Data source integrations Physical hardware, software, networking, and facilities Provisioning Application code Container orchestration, provisioning Cluster scaling Physical hardware, host OS/kernel, networking, and facilities Application code Data source integrations Security config and updates Network config Management tasks Container orchestration control plane Physical hardware software, networking, and facilities Application code Data source integrations Work clusters Security config and updates, network config, firewall, management tasks Physical hardware software, networking, and facilities Application code Data source integrations Scaling Security config and updates Network config Management tasks Provisioning, managing scaling and patching of servers Why Lambda? Operational support AWS Lambda Serverless functions AWS Fargate Serverless containers Amazon ECS/EKS Container management as a service Amazon EC2 Infrastructure as a service Most Least What you manage
10. AWS Shared Responsibility Model: Managed container services Operating System & Network Configuration Customer data Application identity and access management AWS (what we manage) Customer (what you manage) AWS Identity & Access Management Platform Management Code Encryption At Rest Network Traffic Protection Firewall Configuration Data Encryption & Integrity Authentication Application Management Internet Access Monitoring & Logging Compute Storage Database Networking AWS Infrastructure Regions, AZs & Data centers
11. AWS Shared Responsibility Model: Lambda Compute Storage Database Networking AWS Infrastructure Regions, AZs & Data centers Operating System & Network Configuration Customer data Application identity and access management AWS Identity & Access Management Platform Management Code Encryption At Rest Network Traffic Protection Firewall Configuration Data Encryption & Integrity Authentication Application Management Internet Access Monitoring & Logging (Tools provided by platform) AWS (what we manage) Customer (what you manage)
12. Why Lambda? Application integrations 140+ AWS service integrations • polling • queueing • batching • event routing • retries • stream checkpointing • graceful error back-offs Amazon Kinesis AWS AppSync Amazon Simple Notification Service Amazon Simple Queue Service AWS Step Function Amazon EventBridge Amazon DynamoDB Amazon API Gateway Amazon Elastic File System Amazon Simple Storage Service (S3) Amazon CloudFront Amazon CloudWatch Amazon MQ Amazon RDS
13. Why Lambda? Automatic scaling • Burst capacity of up to 3,000 in select Regions ◦ (us-west-2, us-east-1, eu-west-1) • Enables scaling from 0 to 3,000 concurrent executions in seconds • After the initial burst, functions concurrency can scale by an additional 500 instances each minute • Provisioned Concurrency available for highly consistent function executions
14. Why Lambda? Cost considerations • Only pay for use, never pay for idle resources by default • Scales to zero • Precise cost measurements: 1 ms billing • Allocate memory for cost/performance • No need to pay for patching and maintenance
15. Lambda container image benefits
16. Benefit: Agility Flexibility and familiarity of container tooling (Docker, CI / CD, security, governance) Plus operational simplicity of AWS Lambda Equals more agility when building applications
17. Benefit: Dependency management • Manage all dependencies as immutable artifact • Add dependences in Dockerfile • Install native operating system packages • Install language-compatible dependencies
18. Benefit: Familiar container tooling • Use the same build and pipeline tools to deploy • Use the same container registry to store application artifacts (Amazon ECR, Docker Hub) • Tools that can inspect Dockerfiles work the same
19. Benefit: Larger Lambda functions Developers can now configure Lambda functions for: 10 GB deployment package max 10 GB in memory with up to 6 vCPUs proportional to memory configuration Build compute-intensive workloads: • Machine learning, genomics, gaming, HPC applications Build memory-intensive workloads: • Batch, ETL, analytics, media processing Configured memory (MB) Allocated cores 128 – 1769 1 1770 – 3538 2 3539 – 5307 3 5308 – 7076 4 7077 – 8845 5 8846 – 10240 6
20. Benefit: Immutability • Lambda treats container images as immutability entities • When invoked, functions deployed as container images are run without modification • Invoked functions are immutable across environments: • Desktop, CI / CD • Elastic Container Registry • Lambda execution environment OS and runtime patching no longer performed by AWS Any image change requires a separate redeployment step
21. Benefit: Flexibility ◦ Use your preferred base image to deploy Lambda-based applications. ◦ Simplifies running images on additional compute services. ◦ (Runtime Interface Emulator)
22. Amazon ECS AWS Fargate Amazon EKS On-premises Hybrid cloud Benefit: Portability AWS Lambda Lambda container image
23. Working with Lambda container images
24. Container image format & distros Lambda supports container images that have manifest files following these formats: • Docker image manifest V2, schema 2 (used with Docker version 1.10 and newer) • Open Container Initiative (OCI) Specifications (v1.0.0 and up) Can use non-Amazon Linux distributions such as Alpine or Debian Images can be up to 10 GB More here: https://docs.aws.amazon.com/lambda/latest/dg/images-create.html
25. Container image registry Container images are stored in Amazon Elastic Container Registry (ECR) • Fully managed container registry • Required for deploying Lambda functions • Public and private repositories • Cross-account sharing controls • Can replicate images across Regions • Encryption at rest and in transport to Lambda • Integrated vulnerability scanning Amazon Elastic Container Registry
26. Base images AWS provided Lambda base images for every managed runtime • Patched and maintained by AWS • Images available from both Docker Hub and Amazon ECR Public Bring your own base image • Linux kernels supported Multi-stage builds • Node.js • Python • Java • Provided.al2 • .Net • Ruby • Go (Runtime API) CODE EDITOR $ cat Dockerfile FROM public.ecr.aws/lambda/nodejs:12 COPY app.js package*.json ./ RUN npm install CMD [ "app.lambdaHandler" ]
27. Dockerfile for Lambda functions Use the Node.js v12 base image from Amazon ECR Public Copy the application files to the image Run the npm command to install dependencies in the image When the container runs, use my application’s handler CODE EDITOR FROM public.ecr.aws/lambda/nodejs:12 COPY app.js package*.json ./ RUN npm install CMD [ "app.lambdaHandler" ] The container image includes your function and becomes the entire filesystem
28. Dockerfile for Lambda functions Lambda supports the following container image settings in the Dockerfile: • ENTRYPOINT – Specifies the absolute path to the entry point of the application. • CMD – Specifies parameters that you want to pass in with ENTRYPOINT. • WORKDIR – Specifies the absolute path to the working directory. • ENV – Specifies an environment variable for the Lambda function. Lambda ignores the values of any unsupported container image settings in the Dockerfile.
29. Intoducing the RIC and the RIE There are two extra components we’ve released as part of container image support: • AWS Lambda Runtime Interface Client(s) (RIC) • Allows container-based function code to interact with Lambda Runtime API • AWS has released these for each managed runtime • Open-sourced (for example: https://github.com/aws/aws-lambda-nodejs-runtime-interface-client) • AWS Lambda Runtime Interface Emulator (RIE) • Mimics the Runtime API locally for testing purposes • Exposes an HTTP interface that converts requests to JSON for the RIC • Also open-sourced: https://github.com/aws/aws-lambda-runtime-interface-emulator/
30. Developer workflow
31. Developer workflow: Build and local test docker build / sam build Container image 1. Add base layer image 2. Copy function code 3. Install dependencies Local testing (with RIE) • docker run • sam local invoke Lambda function local test Code Dockerfile Container image
32. Developer workflow: Deploy and run Amazon Elastic Container Registry Container image 1. Tag image 2. Upload image to registry Invoke Status: ACTIVE Ready for invoke Lambda function 1. Pull image from Amazon ECR 2. Optimize image 3. Deploy image to Lambda CreateFunction Container image Status: PENDING AWS Lambda docker tag docker push Container image
33. Developer workflow: Deploy and run Amazon Elastic Container Registry Container image 1. Tag image 2. Upload image to registry Invoke Status: ACTIVE Ready for invoke Lambda function 1. Pull image from Amazon ECR 2. Optimize image 3. Deploy image to Lambda CreateFunction Container image Status: PENDING AWS Lambda docker tag docker push On create / update Lambda caches the image in the service to speed up cold start of functions during execution or for provisioned concurrency spin-up Container image
34. Developer workflow: Deploy and run Amazon Elastic Container Registry Container image 1. Tag image 2. Upload image to registry Invoke Status: ACTIVE Ready for invoke Lambda function 1. Pull image from Amazon ECR 2. Optimize image 3. Deploy image to Lambda CreateFunction Container image Status: PENDING AWS Lambda docker tag docker push sam deploy AWS SAM packages the container, pushes it to a repo, and creates or updates the Lambda function with a single command Container image
35. What changes and what stays the same
36. What changes and what stays the same? What changes? • Larger function size • Use preferred base image (Requires RIC to talk to Runtime API) • No auto-updates without a redeploy (immutable) What stays the same? • Operational models • Invoke model • Performance • Storage options • Logging / metrics / tracing • Other service limits • Pricing
37. What’s the same? Performance Memory and CPU configurations match zip archive functions Performance varies based on image size, composition, runtimes and dependencies Cold start times targeted to be same as zip archive (small % of production traffic) Container images are proactively cached near to where the function runs for faster start-up
38. What’s the same? Pricing Now 1 ms billing granularity, reduced from 100 ms. No additional changes to any Lambda pricing calculations or dimension. You do pay for the ECR repository.
39. What’s the same? Operational Models • Automatic scaling characteristics • High availability (multi-AZ deployments) • Security and isolation
40. Lambda function isolation • AWS Lambda runs your functions on Lambda Workers which are EC2 Nitro instances • Execution environments isolated from each other using hardware-virtualized MicroVMs • Execution environments are never reused across different function versions or customers • In-memory & disk state is not accessible or shared across execution environments • Writeable /tmp directory is backed by an EC2 instance store and is encrypted at-rest Firecracker Virtual Machine Monitor MicroVM Execution Environment MicroVM Execution Environment MicroVM Execution Environment MicroVM Execution Environment Bare metal EC2 Nitro instance AWS owned VPC
41. Storage in Lambda Lambda function Memory (128 MB – 10240 MB) /tmp space (512 MB) Deployment package (10 GB for container images) Amazon S3 bucket Amazon EFS file system internal storage external storage
42. Create and package your functions Lambda console Lambda container image Lambda zip archive
43. Summary Container image support can simplify the way you build Lambda-based applications: • Unified tooling with container-based workloads • Easier dependency management • Larger application artifacts Same benefits of Lambda as a compute service and simplified developer experience with AWS SAM Much more here: s12d.com/lambda-containers
44. Serverlessland.com
45. Julian Wood Senior Developer Advocate AWS Serverless @julian_wood Thank You!