Local Testing and Deployment Best Practices for Serverless Applications - AWS Online Tech Talks

© 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Chris Munns – Senior Developer Advocate - Serverless
Local Testing and Deployment
Best Practices for Serverless
Applications

About me:
Chris Munns - munns@amazon.com, @chrismunns
• Senior Developer Advocate - Serverless
• New Yorker
• Previously:
• Business Development Manager – DevOps, July ’15 - Feb ‘17
• AWS Solutions Architect Nov, 2011- Dec 2014
• Formerly on operations teams @Etsy and @Meetup
• Little time at a hedge fund, Xerox and a few other startups
• Rochester Institute of Technology: Applied Networking and
Systems Administration ’05
• Internet infrastructure geek

https://secure.flickr.com/photos/mgifford/4525333972
Why are we
here today?

No servers to provision
or manage
Scales with usage
Never pay for idle Availability and fault
tolerance built in
Serverless means…

Serverless application
SERVICES (ANYTHING)
Changes in
data state
Requests to
endpoints
Changes in
resource state
EVENT SOURCE FUNCTION
Node.js
Python
Java
C#

Common Lambda use cases
Web
Applications
• Static
websites
• Complex web
apps
• Packages for
Flask and
Express
Data
Processing
• Real time
• MapReduce
• Batch
Chatbots
• Powering
chatbot logic
Backends
• Apps &
services
• Mobile
• IoT
</></>
Amazon
Alexa
• Powering
voice-enabled
apps
• Alexa Skills
Kit
IT
Automation
• Policy engines
• Extending
AWS services
• Infrastructure
management

Amazon S3 Amazon
DynamoDB
Amazon
Kinesis
AWS
CloudFormation
AWS CloudTrail Amazon
CloudWatch
Amazon
Cognito
Amazon SNSAmazon
SES
Cron events
DATA STORES ENDPOINTS
DEVELOPMENT AND MANAGEMENT TOOLS EVENT/MESSAGE SERVICES
Event sources that trigger AWS Lambda
… and more!
AWS
CodeCommit
Amazon
API Gateway
Amazon
Alexa
AWS IoT AWS Step
Functions

AWS Serverless Application Model (SAM)
CloudFormation extension optimized for
serverless
New serverless resource types: functions, APIs,
and tables
Supports anything CloudFormation supports
Open specification (Apache 2.0)
https://github.com/awslabs/serverless-application-model

Create templates of your infrastructure
CloudFormation provisions AWS resources
based on dependency needs
Version control/replicate/update templates like
code
Integrates with development, CI/CD,
management tools
JSON and YAML supported
AWS CloudFormation

AWSTemplateFormatVersion: '2010-09-09'
Resources:
GetHtmlFunctionGetHtmlPermissionProd:
Type: AWS::Lambda::Permission
Properties:
Action: lambda:invokeFunction
Principal: apigateway.amazonaws.com
FunctionName:
Ref: GetHtmlFunction
SourceArn:
Fn::Sub: arn:aws:execute-api:${AWS::Region}:${AWS::AccountId}:${ServerlessRestApi}/Prod/ANY/*
ServerlessRestApiProdStage:
Type: AWS::ApiGateway::Stage
Properties:
DeploymentId:
Ref: ServerlessRestApiDeployment
RestApiId:
Ref: ServerlessRestApi
StageName: Prod
ListTable:
Type: AWS::DynamoDB::Table
Properties:
ProvisionedThroughput:
WriteCapacityUnits: 5
ReadCapacityUnits: 5
AttributeDefinitions:
- AttributeName: id
AttributeType: S
KeySchema:
- KeyType: HASH
AttributeName: id
GetHtmlFunction:
Type: AWS::Lambda::Function
Properties:
Handler: index.gethtml
Code:
S3Bucket: flourish-demo-bucket
S3Key: todo_list.zip
Role:
Fn::GetAtt:
- GetHtmlFunctionRole
- Arn
Runtime: nodejs4.3
GetHtmlFunctionRole:
Type: AWS::IAM::Role
Properties:
ManagedPolicyArns:
- arn:aws:iam::aws:policy/AmazonDynamoDBReadOnlyAccess
- arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
AssumeRolePolicyDocument:
Version: '2012-10-17'
Statement:
- Action:
- sts:AssumeRole
Effect: Allow
Principal:
Service:
- lambda.amazonaws.com
ServerlessRestApiDeployment:
Type: AWS::ApiGateway::Deployment
Properties:
RestApiId:
Ref: ServerlessRestApi
Description: 'RestApi deployment id: 127e3fb91142ab1ddc5f5446adb094442581a90d'
StageName: Stage
GetHtmlFunctionGetHtmlPermissionTest:
Type: AWS::Lambda::Permission
Properties:
Action: lambda:invokeFunction
Principal: apigateway.amazonaws.com
FunctionName:
Ref: GetHtmlFunction
SourceArn:
Fn::Sub: arn:aws:execute-api:${AWS::Region}:${AWS::AccountId}:${ServerlessRestApi}/*/ANY/*
ServerlessRestApi:
Type: AWS::ApiGateway::RestApi
Properties:
Body:
info:
version: '1.0'
title:
Ref: AWS::StackName
paths:
"/{proxy+}":
x-amazon-apigateway-any-method:
x-amazon-apigateway-integration:
httpMethod: ANY
type: aws_proxy
uri:
Fn::Sub: arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-
31/functions/${GetHtmlFunction.Arn}/invocations
responses: {}
swagger: '2.0'
CloudFormation template

SAM template
AWSTemplateFormatVersion: '2010-09-09’
Transform: AWS::Serverless-2016-10-31
Resources:
GetHtmlFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: s3://sam-demo-bucket/todo_list.zip
Runtime: nodejs4.3
Policies: AmazonDynamoDBReadOnlyAccess
Events:
GetHtml:
Type: Api
Properties:
Path: /{proxy+}
Method: ANY
ListTable:
Type: AWS::Serverless::SimpleTable

SAM template
AWSTemplateFormatVersion: '2010-09-09’
Transform: AWS::Serverless-2016-10-31
Resources:
GetHtmlFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: s3://sam-demo-bucket/todo_list.zip
Runtime: nodejs4.3
Policies: AmazonDynamoDBReadOnlyAccess
Events:
GetHtml:
Type: Api
Properties:
Path: /{proxy+}
Method: ANY
ListTable:
Type: AWS::Serverless::SimpleTable
Tells CloudFormation this is a SAM
template it needs to “transform”
Creates a Lambda function with the
referenced managed IAM policy,
runtime, code at the referenced zip
location, and handler as defined.
Also creates an API Gateway and
takes care of all
mapping/permissions necessary
Creates a DynamoDB table with 5
Read & Write units

SAM template
From: https://github.com/awslabs/aws-serverless-samfarm/blob/master/api/saml.yaml
<-THIS
BECOMES THIS->

SAM Template Capabilities
• Can mix in other non-SAM CloudFormation
resources in the same template
• i.e. S3, Kinesis, Step Functions
• Supports use of Parameters, Mappings,
Outputs, etc
• Supports Intrinsic Functions
• Can use ImportValue
(exceptions for RestApiId, Policies, StageName attributes)
• YAML or JSON

SAM commands – Package & Deploy
Package
•Creates a deployment package (.zip file)
•Uploads deployment package to an Amazon S3 Bucket
•Adds a CodeUri property with S3 URI
Deploy
•Calls CloudFormation ‘CreateChangeSet’ API
•Calls CloudFormation ‘ExecuteChangeSet’ API

Introducing SAM Local
CLI tool for local testing of serverless apps
Works with Lambda functions and “proxy-
style” APIs
Response object and function logs available
on your local machine
Currently supports Java, Node.js and
Python
https://github.com/awslabs/aws-sam-local

Introducing SAM Local
Supports live debugging (Java and Node.js)
Uses open source docker-lambda images to
mimic Lambda’s execution environment:
• Emulates timeout, memory limits, runtimes
• Does not emulate CPU limits
• Partial API Gateway emulation (proxy calls)
SAM Local is open source & accepting pull
requests!
https://github.com/awslabs/aws-sam-local

SAM Local CLI
$ sam --help
NAME:
sam -
___ _____ ___ _ __ __
/_ / / __| / __| /_ | / |
/ _ // /__ __ / _ | |/| |
/_/ __/_/ |___/ |___/_/ __| |_|
AWS Serverless Application Model (SAM) CLI
The AWS Serverless Application Model extends AWS CloudFormation to provide a simplified way of defining the Amazon API Gateway APIs, AWS Lambda functions,
and Amazon DynamoDB tables needed by your serverless application. You can find more in-depth guide about the SAM specification
here:nhttps://github.com/awslabs/serverless-application-model.
USAGE:
sam [global options] command [command options] [arguments...]
VERSION:
0.2.0
COMMANDS:
local Run your Serverless application locally for quick development & testing
validate Validates an AWS SAM template. If valid, will print a summary of the resources found within the SAM template. If the template is invalid, returns
a non-zero exit code.
package Package an AWS SAM application. This is an alias for 'aws cloudformation package'.
deploy Deploy an AWS SAM application. This is an alias for 'aws cloudformation deploy'.
help, h Shows a list of commands or help for one command
GLOBAL OPTIONS:
--help, -h show help
--version, -v print the version

SAM Local CLI
COMMANDS:
validate Validates an AWS SAM template. If valid, will print a summary of the resources found
within the SAM template. If the template is invalid, returns a non-zero exit code.

SAM Local CLI
COMMANDS:
Any command with --help at the end will provide more context
on that command. Let’s check out “sam validate”

SAM Local CLI
COMMANDS:
$ sam validate --help
NAME:
sam validate - Validates an AWS SAM template. If valid, will print a summary of the resources found
USAGE:
sam validate [command options] [arguments...]
OPTIONS:
--template value, -t value AWS SAM template file (default: "template.[yaml|yml]")
[$SAM_TEMPLATE_FILE]

SAM Local CLI
$ sam validate --template mysamtemplate.yaml
Valid!
$ sam validate --template saml.yaml (mess with spacing)
invalid YAML template: yaml: line 25: did not find expected key

SAM Local CLI
COMMANDS:
Let’s check out “sam local”

SAM Local CLI
$ sam local --help
..
USAGE:
sam local command [command options] [arguments...]
COMMANDS:
start-api Allows you to run your Serverless application locally for quick development & testing. When run
in a directory that contains your Serverless functions and your AWS SAM template, it will create a local HTTP
server hosting all of your functions. When accessed (via browser, cli etc), it will launch a Docker container
locally to invoke the function. It will read the CodeUri property of AWS::Serverless::Function resource to find
the path in your file system containing the Lambda Function code. This could be the project's root directory for
interpreted languages like Node & Python, or a build directory that stores your compiled artifacts or a JAR file.
If you are using a interpreted language, local changes will be available immediately in Docker container on every
invoke. For more compiled languages or projects requiring complex packing support, we recommended you run your
own building solution and point SAM to the directory or file containing build artifacts.
invoke Invokes a local Lambda function once and quits after invocation completes.
Useful for developing serverless functions that handle asynchronous events (such as S3/Kinesis etc), or if you
want to compose a script of test cases. Event body can be passed in either by stdin (default), or by using the --
event parameter. Runtime output (logs etc) will be outputted to stderr, and the Lambda function result will be
outputted to stdout.
generate-event Generates Lambda events (e.g. for S3/Kinesis etc) that can be piped to 'sam local invoke'

SAM Local CLI
$ sam local start-api --help
NAME..
USAGE:
sam local start-api [command options] [arguments...]
OPTIONS:
--log-file value, -l value Optional logfile to send runtime logs to
--static-dir value, -s value Any static assets (e.g. CSS/Javascript/HTML) files located in this
directory will be presented at / (default: "public")
--port value, -p value Local port number to listen on (default: "3000")
--host value Local hostname or IP address to bind to (default: "127.0.0.1")
--env-vars value, -n value Optional. JSON file containing values for Lambda function's
environment variables.
--debug-port value, -d value Optional. When specified, Lambda function container will start in
debug mode and will expose this port on localhost. [$SAM_DEBUG_PORT]
--docker-volume-basedir value, -v value Optional. Specifies the location basedir where the SAM file exists.
If the Docker is running on a remote machine, you must mount the path where the SAM file exists on the docker
machine and modify this value to match the remote machine. [$SAM_DOCKER_VOLUME_BASEDIR]

SAM Local CLI
$ sam local invoke --help
NAME:
sam local invoke - Invokes a local Lambda function once and quits after invocation completes.
..
USAGE:
sam local invoke [command options] <function-identifier>
OPTIONS:
--log-file value, -l value Optional. Logfile to send runtime logs to
--env-vars value, -n value Optional. JSON file containing values for Lambda function's
environment variables.
--event value, -e value JSON file containing event data passed to the Lambda function during
invoke
--debug-port value, -d value Optional. When specified, Lambda function container will start in
debug mode and will expose this port on localhost. [$SAM_DEBUG_PORT]
--docker-volume-basedir value, -v value Optional. Specifies the location basedir where the SAM file exists.
If the Docker is running on a remote machine, you must mount the path where the SAM file exists on the docker
machine and modify this value to match the remote machine. [$SAM_DOCKER_VOLUME_BASEDIR]

SAM Local CLI
$ sam local generate-event --help
NAME:
sam local generate-event - Generates Lambda events (e.g. for S3/Kinesis etc) that can be piped to 'sam local
invoke'
USAGE:
sam local generate-event command [command options] [arguments...]
COMMANDS:
s3 Generates a sample Amazon S3 event
sns Generates a sample Amazon SNS event
kinesis Generates a sample Amazon Kinesis event
dynamodb Generates a sample Amazon DynamoDB event
api Generates a sample Amazon API Gateway event
schedule Generates a sample scheduled event

SAM Local CLI
COMMANDS:
Behave the same exact way as the AWS CLI commands do

SAM Best Practices
• Unless function handlers share code, split them into their
own independent Lambda functions files or binaries
• Another option is to use language specific packages to share
common code between functions
• Unless independent Lambda functions share event
sources, split them into their own code repositories with
their own SAM templates
• Locally validate your YAML or JSON SAM files before
committing them. Then do it again in your CI/CD process

Lambda Environment Variables
• Key-value pairs that you can dynamically pass to
your function
• Available via standard environment variable APIs
such as process.env for Node.js or os.environ for
Python
• Can optionally be encrypted via AWS Key
Management Service (KMS)
• Allows you to specify in IAM what roles have access to
the keys to decrypt the information
• Useful for creating environments per stage (i.e. dev,
testing, production)

API Gateway Stage Variables
• Stage variables act like environment variables
• Use stage variables to store configuration values
• Stage variables are available in the $context object
• Values are accessible from most fields in API Gateway
• Lambda function ARN
• HTTP endpoint
• Custom authorizer function name
• Parameter mappings

Lambda and API Gateway Variables + SAM
Parameters:
MyEnvironment:
Type: String
Default: testing
AllowedValues:
- testing
- staging
- prod
Description: Environment of this stack of
resources
SpecialFeature1:
Type: String
Default: false
AllowedValues:
- true
- false
Description: Enable new SpecialFeature1
…
…
#Lambda
MyFunction:
Type: 'AWS::Serverless::Function'
Properties:
…
Environment:
Variables:
ENVIRONMENT: !Ref: MyEnvironment
Spec_Feature1: !Ref: SpecialFeature1
…
#API Gateway
MyApiGatewayApi:
Type: AWS::Serverless::Api
Properties:
…
Variables:
ENVIRONMENT: !Ref: MyEnvironment
SPEC_Feature1: !Ref: SpecialFeature1
…

Create multiple environments from one template:
• Use Parameters and Mappings when possible to
build dynamic templates based on user inputs and
pseudo parameters such as AWS::Region
• Use ExportValue & ImportValue to share resource
information across stacks
• Build out multiple environments, such as for
Development, Test, Production and even DR using
the same template, even across accounts
SAM Template
Source
Control
Dev
Test
Prod
SAM Best Practices

Source
Source
AWS CodeCommit
MyApplication
Local development should lead to a formal pipeline!
Build
test-build-source
AWS CodeBuild
Deploy Testing
create-changeset
AWS
CloudFormation
execute-changeset
AWS
CloudFormation
Run-stubs
AWS Lambda
Deploy Staging
create-changeset
AWS
CloudFormation
execute-changeset
AWS
CloudFormation
Run-API-test
Runscope
QA-Sign-off
Manual Approval
Review
Deploy Prod
create-changeset
AWS
CloudFormation
execute-changeset
AWS
CloudFormation
Post-Deploy-Slack
AWS Lambda
This CodePipeline
pipeline:
• Five Stages
• Builds code artifact w/ CodeBuild
• Three deployed to “Environments”
• Uses SAM/CloudFormation to
deploy artifact and other AWS
resources
• Has Lambda custom actions for
running my own testing functions
• Integrates with a 3rd party
tool/service
• Has a manual approval before
deploying to production

aws.amazon.com/serverless/developer-tools

Additional Resources
Serverless Application Model (SAM) - https://github.com/awslabs/serverless-
application-model
AWS SAM Local - https://github.com/awslabs/aws-sam-local
Learn more:
AWS Serverless: https://aws.amazon.com/serverless
AWS Serverless tools: https://aws.amazon.com/serverless/developer-tools
AWS Lambda: https://aws.amazon.com/lambda
Amazon API Gateway: https://aws.amazon.com/api-gateway
AWS CloudFormation: https://aws.amazon.com/cloudformation

Chris Munns
munns@amazon.com
@chrismunnshttps://www.flickr.com/photos/theredproject/3302110152/

?
https://secure.flickr.com/photos/dullhunk/202872717/

Local Testing and Deployment Best Practices for Serverless Applications - AWS Online Tech Talks

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Local Testing and Deployment Best Practices for Serverless Applications - AWS Online Tech Talks

Similar a Local Testing and Deployment Best Practices for Serverless Applications - AWS Online Tech Talks (20)

Más de Amazon Web Services

Más de Amazon Web Services (20)

Local Testing and Deployment Best Practices for Serverless Applications - AWS Online Tech Talks