Overview of Serverless Application Deployment Patterns - AWS Online Tech Talks

© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Chris Munns – Senior Developer Advocate – AWS
Serverless
Jan 23, 2018
Overview of Serverless
Application Deployment
Patterns

About me:
Chris Munns - munns@amazon.com, @chrismunns
• Senior Developer Advocate - Serverless
• New Yorker
• Previously:
• AWS 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…

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

Lambda execution model
Synchronous
(push)
Asynchronous
(event)
Stream-based
Amazon
API Gateway
AWS Lambda
function
Amazon
DynamoDBAmazon
SNS
/order
AWS Lambda
function
Amazon
S3
reqs
Amazon
Kinesis
changes
AWS Lambda
service
function

Amazon API Gateway
Internet
Mobile Apps
Websites
Services
AWS Lambda
functions
AWS
API Gateway
Cache
Endpoints on
Amazon EC2
All publicly and
privately accessible
endpoints
Amazon
CloudWatch
Monitoring
Amazon
CloudFront
Any other
AWS service
Regional API Endpoints

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

Serverless
Deployment
Patterns
https://www.flickr.com/photos/volvob12b/15012162252/

version NEW
How do we deploy a new version of our code?
version OLD
?

Serverless Deployment Pattern Considerations
Minimizing Impact
to consumers
Rollback technique Execution model
factors
Deployment Speed

Serverless Deployment Patterns
All at once
All traffic goes from
version OLD to
NEW at once.
Canaries/Linear
A small % of
production traffic is
sent to version NEW,
the remainder to
version OLD. After
some period of
waiting for validation,
traffic is shifted
incrementally (with
further validation) or
fully to version NEW.
Blue/Green
Version NEW is
deployed and
tested against
before taking
production traffic.
After validated all
traffic goes from
version OLD to
NEW at once.

Serverless Deployment Patterns Consideration Matrix
Consumer impact Rollback Event Model
Factors
Deployment
Speed
All at once All at once Redeploy
older version
Any event model
at low concurrency
rate
Immediate
Blue/Green All at once with some
level of production
environment testing
beforehand
Revert traffic
to OLD
Better for async
and sync event
models at medium
concurrency
workloads
Minutes to
hours of
validation and
then immediate
to customers
Canaries/
Linear
1-10% typical initial
traffic shift, then
phased increases or
all at once
Revert traffic
to OLD
Better for high
concurrency
workloads
Minutes to
hours

Tools for Serverless
Application
Deployment
https://secure.flickr.com/photos/lox/9408028555

Meet
SAM!

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

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
Handler: index.gethtml
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:
Properties:
CodeUri: s3://sam-demo-bucket/todo_list.zip
Handler: index.gethtml
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

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

SAM Template Properties
AWS::Serverless::Function
AWS::Serverless::Api
AWS::Serverless::SimpleTable
Handler: index.js
Runtime: nodejs4.3
CodeUri: 's3://my-code-bucket/my-function.zip'
Description: Creates thumbnails of uploaded
images
MemorySize: 1024
Timeout: 15
Policies: AmazonS3FullAccess
Environment:
Variables:
TABLE_NAME: my-table
Events:
PhotoUpload:
Type: S3
Properties:
Bucket: my-photo-bucket
Tracing: Active|PassThrough
Tags:
AppNameTag: ThumbnailApp
DepartmentNameTag: ThumbnailDepartmentFrom SAM Version 2016-10-31

AWS::Serverless::Function Event source types
From SAM Version 2016-10-31
S3
SNS
Kinesis | DynamoDB
Api
Schedule
CloudWatchEvent
IoTRule
AlexaSkill
Note: Events are a map of string to Event Source
Object
Event Source Objects have the following structure:
Type:
Properties:
For Example:
Events:
MyEventName:
Type: S3
Properties:
Bucket: my-photo-bucket

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

AWS 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
Uses open source docker-lambda images to
mimic Lambda’s execution environment:
• Emulates timeout, memory limits,
runtimes
https://github.com/awslabs/aws-sam-local

Deploying your
applications
https://secure.flickr.com/photos/simononly/15386966677

Stage Variables and Lambda Aliases
Using Stage Variables in API Gateway together with Lambda function Aliases
you can manage a single API configuration and Lambda function for multiple
environment stages
myLambdaFunction
1
2
3 = prod
4
5
6 = beta
7
8 = dev
My First API
Stage variable = lambdaAlias
Prod
lambdaAlias = prod
Beta
lambdaAlias = beta
Dev
lambdaAlias = dev

Lambda Alias Traffic Shifting & Safe Deployments
“By default, an alias points to a single Lambda function version. When the alias is
updated to point to a different function version, incoming request traffic in turn instantly
points to the updated version.”

points to the updated version.
This exposes that alias to any potential instabilities introduced by the new version.”

points to the updated version.
This exposes that alias to any potential instabilities introduced by the new version.
To minimize this impact, you can implement the routing-config parameter of the Lambda
alias that allows you to point to two different versions of the Lambda function and dictate
what percentage of incoming traffic is sent to each version.”
– AWS Lambda docs on “Traffic Shifting Using Aliases”
aws lambda update-alias --name alias name --function-name function-
name --routing-config AdditionalVersionWeights={”6"=0.05}

Lambda Alias Traffic Shifting
myLambdaFunction
1
2
3 = prod
4
5
6 = prod 5%
My First API
Prod
lambdaAlias = prod
aws lambda update-alias --name prod --function-name myLambdaFunction
--routing-config AdditionalVersionWeights={”6"=0.05}

Lambda Alias Traffic Shifting
myLambdaFunction
5
6 = prod
My First API
Prod
lambdaAlias = prod
aws lambda update-alias --name prod --function-name myLambdaFunction
--function-version 6 --routing-config ''

Lambda Alias Traffic Shifting & AWS Step Functions
Blog link: http://amzn.to/2FjlWA7

SAM Globals + Safe Deployments
Globals:
Function:
Runtime: nodejs4.3
AutoPublishAlias: !Ref ENVIRONMENT
MyLambdaFunction:
Properties:
Handler: index.handler
DeploymentPreference:
Type: Linear10PercentEvery10Minutes
Alarms:
# A list of alarms that you want to monitor
- !Ref AliasErrorMetricGreaterThanZeroAlarm
- !Ref LatestVersionErrorMetricGreaterThanZeroAlarm
Hooks:
# Validation Lambda functions that are run before & after traffic shifting
PreTraffic: !Ref PreTrafficLambdaFunction
PostTraffic: !Ref PostTrafficLambdaFunction
NEW!

Lambda Alias Traffic Shifting & AWS SAM
AutoPublishAlias
By adding this property and specifying an
alias name, AWS SAM will do the
following:
• Detect when new code is being
deployed based on changes to the
Lambda function's Amazon S3 URI.
• Create and publish an updated version
of that function with the latest code.
• Create an alias with a name you
provide (unless an alias already exists)
and points to the updated version of
the Lambda function.
Deployment Preference Type
Canary10Percent30Minutes
Linear10PercentEvery10Minutes
Linear10PercentEvery1Minute
AllAtOnce
In SAM:

Lambda Alias Traffic Shifting & AWS SAM
Alarms: # A list of alarms that you want to monitor
- !Ref AliasErrorMetricGreaterThanZeroAlarm
- !Ref LatestVersionErrorMetricGreaterThanZeroAlarm
Hooks: # Validation Lambda functions that are run
before & after traffic shifting
PreTraffic: !Ref PreTrafficLambdaFunction
PostTraffic: !Ref PostTrafficLambdaFunction
In SAM:
Note: You can specify a maximum of 10 alarms

NEW: Can deploy AWS Lambda!!
Uses AWS SAM to deploy serverless applications
Supports Lambda Alias Traffic Shifting enabling
canaries and blue|green deployments
Can rollback based on CloudWatch Metrics/Alarms
Pre/Post-Traffic Triggers can integrate with other
services (or even call Lambda functions)
AWS CodeDeploy + Lambda
NEW!

CodeDeploy comes with a number of added
capabilities:
• Custom deployment configurations.
Examples:
• “Canary 5% for 1 hour”
• “Linear 20% every 1 hour”
• Notification events via SNS on
success/failure/rollback
• Console with visibility on deploy status,
history, and rollbacks.
AWS CodeDeploy + Lambda
NEW!

Amazon API Gateway Canary Support
Use canary release deployments to gradually roll out new APIs
in Amazon API Gateway:
• configure percent of traffic to go to a new stage deployment
• can test stage settings and variables
• API gateway will create additional Amazon CloudWatch Logs
group and CloudWatch metrics for the requests handled by
the canary deployment API
• To rollback: delete the deployment or set percent of traffic to 0
NEW!

v1API
Clients
All publicly and
privately
accessible
endpoints
Backends
in AWS
api.mydomain.com/prod
All traffic to currently deployed version

API
Clients
All publicly and
privately
accessible
endpoints
Backends
in AWS
v1
50%
v2
50%
50% traffic to new deployment of stage, rest to previous version

API
Clients
All publicly and
privately
accessible
endpoints
Backends
in AWS
v1
90%
v2
10%

API
Clients
All publicly and
privately
accessible
endpoints
Backends
in AWS
v1
90%
v2
10%
No changes to client

v2API
Clients
All publicly and
privately
accessible
endpoints
Backends
in AWS
All traffic to new deployed version

Interesting use-cases
• Explore new technologies in your API backend:
• New languages
• New frameworks
• Try Lambda in place of other HTTP endpoints!
• Compare/contrast performance with individual logs and
metrics
• Migrate an API from on-premises to AWS via endpoint
integrations in VPC (new)
• API-GW -> Network Load Balancer (NLB) -> on-prem
over Direct Connect or VPN connection
• Can test method by method or even action by action, no need
for an all at once move!

Lambda
• Single function is only
granularity
• Transparent to invoking
services
• Rollback by setting weight to 0
• Supports automating
increments changes via SAM
• new version has unique logs &
metrics
Comparing Lambda vs. API Gateway Canaries
API Gateway
• Entire stage is maximum
granularity
• Transparent to clients
• Rollback by setting weight to
zero or deleting canary
• Currently no native automated
tooling
• new version has unique logs &
metrics

CloudWatch Metrics
• 7 Built in metrics for Lambda
• Can call “put-metric-data”
from your function code for
custom metrics
• New: Function
Concurrency
• 7 Built in metrics for API-
Gateway
Metrics and logging are a universal right!
CloudWatch Logs
• Lambda Logging
• Custom logging from your
code with your language’s
equivalent of console.log()
• API Gateway Logging
• New: Custom formats
• Log Pivots
• Build metrics based on log
filters

Type: "AWS::CloudWatch::Alarm”
Properties:
ActionsEnabled: True
AlarmActions:
- "arn:aws:sns:us-east-1:1234567890abc:MunnsDemoALERT"
AlarmDescription: “Error if 5 errors in a single datapoint”
AlarmName: "SAM Lambda Error Alarm"
ComparisonOperator: "GreaterThanOrEqualToThreshold"
Dimensions:
-
Name: FunctionName
Value: ”my-function”
-
Name: Resource
Value: ”my-function"
EvaluationPeriods: 1
MetricName: "Errors"
Namespace: "AWS/Lambda"
Period: 300
Statistic: “Average”
Threshold: 5.0

Building your
pipeline
https://www.flickr.com/photos/seattlemunicipalarchives/12504672623/

Continuous delivery service for fast and
reliable application updates
Model and visualize your software release
process
Builds, tests, and deploys your code every time
there is a code change
Integrates with third-party tools and AWS
AWS CodePipeline

An example minimal Developer’s pipeline:
MyBranch-Source
Source
CodeCommit
MyApplication
Build
test-build-source
CodeBuild
MyDev-Deploy
create-changeset
AWS CloudFormation
execute-changeset
AWS CloudFormation
Run-stubs
AWS Lambda
This pipeline:
• Three Stages
• Builds code artifact
• One Development environment
• Uses SAM/CloudFormation to
deploy artifact and other AWS
resources
• Has Lambda custom actions for
running my own testing functions

An example minimal production pipeline:
This pipeline:
• Five Stages
• Builds code artifact
• 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
Source
Source
CodeCommit
MyApplication
Build
test-build-source
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

Where and what to test?
Source
MyApplication
Build
Deploy Testing
Deploy Staging
Deploy Prod
• Code review via Pull
Requests
• (NEW In CodeCommit)
• Lint/syntax check
• Unit tests pass
• Code successfully
compiles
• All at once deploy
• Mocked/stubbed
integration tests
• Tests against real
dependencies (potentially
against production ones)
• Deploy new version and
direct all requests to it
1.
2.
3.
4.
5.
All at once model

Source
MyApplication
Build
Deploy Testing
Deploy Staging
Deploy Prod
Requests
• Unit tests pass
compiles
• Mocked/stubbed
integration tests
• Tests against
dependencies
• Deploy green version
• Run tests against green
& validate
• Direct 100% to green
1.
2.
3.
4.
5.
Blue/Green model

Source
MyApplication
Build
Deploy Testing
Deploy Staging
Deploy Prod
Requests
• Unit tests pass
compiles
• Mocked/stubbed
integration tests
• Tests against
dependencies
• Deploy canaries
• Complete wait period
successfully
• Deploy 100%
1.
2.
3.
4.
5.
Canary model

Environments, Stages, Versioning, & Canaries?
A few best practices:
1. Use blue|green or canaries for production deployments with a
rollback as automated as possible
2. In Lambda Versioning is useful if you need to support multiple
versions to multiple consumers/invocation points
3. In API-Gateway Stages work similarly and are useful if you need to
support multiple API versions
4. Try to always have separate “stacks” for Development, Testing,
Staging, Production environments
1. Do not use Stages or Versioning for this
2. Think about having different accounts all together for different
environments

FIN, ACK
With the recent feature releases you can easily deploy Lambda functions in a
safe and controlled manner!
Some key takeaways:
• automatic rollbacks should be your first line of recovery for deployment
related issues
• different event models and different workload sizes can cause you to use
different deployment patterns
• decide on the most key metric to rollback or fail a deployment on related to
how a bad deployment might impact your customers
• AWS SAM + AWS CodeDeploy enable you to easily do all at once,
blue|green, and canary based deployments for serverless applications!

aws.amazon.com/serverless

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

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

Overview of Serverless Application Deployment Patterns - AWS Online Tech Talks

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Overview of Serverless Application Deployment Patterns - AWS Online Tech Talks

Ähnlich wie Overview of Serverless Application Deployment Patterns - AWS Online Tech Talks (20)

Mehr von Amazon Web Services

Mehr von Amazon Web Services (20)

Overview of Serverless Application Deployment Patterns - AWS Online Tech Talks