Building CICD Pipelines for Serverless Applications

© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Building CI/CD Pipelines for Serverless
Applications
Prakash Palanisamy, Solutions Architect | 11th Oct, 2018

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

Amazon S3 Amazon
DynamoDB
Amazon
Kinesis
AWS
CloudFormation
AWS CloudTrail Amazon
CloudWatch
Amazon
Cognito
Cron events
DATA STORES ENDPOINTS
DEVELOPMENT AND MANAGEMENT TOOLS EVENT/MESSAGE SERVICES
Example event sources that trigger AWS Lambda
… and a few more with more on the way!
AWS
CodeCommit
AWS IoT AWS Step
Functions
Amazon
Alexa
Amazon
SES
Amazon
SQS
Amazon
SNS
Amazon
API Gateway

Understanding “CI & CD”
Source Build Test Production
Continuous integration
Continuous delivery
Continuous deployment

CI/CD for serverless applications
There are a number of different paradigms we need to take
into account when doing CI&CD for serverless applications:
• Lambda functions are a unit of deployment
• We’ll typically have multiple Lambda functions per application
• Each function will have an event trigger
• Could be shared or unique to each function
• A serverless application is typically a combination of AWS Lambda +
other AWS services

CI/CD for serverless applications
We’ll want to deliver our serverless application via a
traditional development pipeline:
• Pipeline initiated after code is committed to a repository
• Built, tested, and verified at the code level exactly once
• Aim for single artifact per deploy
• Integration tested at functional and end-to-end levels
• Deployed to independent environments for each stage of this process
• Allow for those independent environments to be deployed exactly the
same way across infrastructure + application

Development Workflow Checklist
q Model your application and infrastructure resources
q Configure multiple environments
q Automate your delivery process
q Collect metrics and logs

An example of services for building serverless applications:
Best practice: Manage these AWS resources with “Infrastructure as Code”
practices/tools!
Amazon S3 Amazon
DynamoDB
AWS Step
Functions
Amazon
SQS
Amazon
SNS
Amazon
API Gateway
Amazon
Kinesis

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
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

CloudFormation template
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'

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
Tells CloudFormation that 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
Tells CloudFormation that 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

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

SAM template properties
AWS::Serverless::Function
AWS::Serverless::Api
AWS::Serverless::SimpleTable
Starting SAM Version 2016-10-31

Starting SAM Version 2016-10-31
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

From SAM Version 2016-10-31
StageName: prod
DefinitionUri: swagger.yml
CacheClusterEnabled: true
CacheClusterSize: 28.4
Variables:
VarName: VarValue

From SAM Version 2016-10-31
PrimaryKey:
Name: id
Type: String
ProvisionedThroughput:
ReadCapacityUnits: 5
WriteCapacityUnits: 5

SAM template capabilities
• Can mix in other non-SAM CloudFormation resources in
the same template
• Examples: Amazon S3, Amazon Kinesis, AWS Step Functions
• Supports use of parameters, mappings, outputs, etc.
• Supports intrinsic functions
• Can use ImportValue
(exceptions for RestApiId, Policies, StageName attributes)
• YAML or JSON

AWS 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

ü Model your application and infrastructure resources
q Configure multiple environments

Configure multiple environments
Good developers know they need different environments for building,
testing, and running their applications!
Why?
• Avoid overlapping usage of resources
• Safely test new code without impacting your customers
• Safely test infrastructure changes
How?
• AWS account strategies
• Using infrastructure as code tools
• Using variables unique to each environment
• Automating application delivery/testing

Configure multiple environments
Same account, different stacks:
+ Easier management of resources
+ Easier visibility via
management/monitoring tools
- Can be harder to create
permission/access separation
Better for smaller teams/individuals
Two popular AWS account strategies:
Multiple accounts:
+ Assured separation of permissions
and access
+ Resource limits per account to
control usage
- Overhead of managing multiple
accounts and controls between them
Better for larger teams/companies
Check out AWS Organizations

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 KMS
• Allows you to specify in IAM what roles have access to the keys to decrypt the
information
• Useful for creating environments per stage (such as 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

Template File
Defining Stack
Source
Control
Dev
Test
Prod
Use the version
control system of
your choice to store
and track changes
to this template
Build out multiple
environments, such as
for development, test,
production and even
DR using the same
template, even across
accounts
Many environments from one template

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
…

ü Configure multiple environments

Building a deployment package
Node.js & Python
• .zip file consisting of
your code and any
dependencies
• Use npm/pip to install
libraries
• All dependencies must
be at root level
Java
• Either .zip file with all
code/dependencies, or
standalone .jar
• Use Maven / Eclipse IDE
plugins
• Compiled class & resource
files at root level, required
jars in /lib directory
C# (.NET Core)
• Either .zip file with all
code/dependencies, or
a standalone .dll
• Use NuGet /
VisualStudio plugins
• All assemblies (.dll) at
root level

Building a deployment package
GO
• .zip file consisting of your code
and any dependencies using
build-lambda-zip
• Use go get to download the
libraries
• All dependencies must be at
root level
PowerShell
• .zip file with all
code/dependencies.
• Use NuGet and PowerShell
Cmd-let
New-AWSPowerShellLambdaPa
ckage
• All dependencies at root level

Fully managed build service that compiles source code, runs
tests, and produces software packages
Scales continuously and processes multiple builds concurrently
You can provide custom build environments suited to your
needs via Docker images
Only pay by the minute for the compute resources you use
Launched with AWS CodePipeline and Jenkins integration
Can be used as a “Test” action in CodePipeline
AWS CodeBuild

• Variables to be used by phases
of build
• Examples for what you can do in
the phases of a build:
• You can install packages or run
commands to prepare your
environment in “install”.
• Run syntax checking,
commands in “pre_build”.
• Execute your build
tool/command in “build”
• Test your app further or ship a
container image to a repository
in post_build
• Create and store an artifact in S3
buildspec.yml Exampleversion: 0.1
environment_variables:
plaintext:
"INPUT_FILE": "saml.yaml”
"S3_BUCKET": ""
phases:
install:
commands:
- npm install
pre_build:
commands:
- eslint *.js
build:
commands:
- npm test
post_build:
commands:
- aws cloudformation package --template $INPUT_FILE --s3-
bucket $S3_BUCKET --output-template post-saml.yaml
artifacts:
type: zip
files:
- post-saml.yaml
- beta.json

Establish our testing/validation model
We want to make sure our code:
• Is without syntax issues
• Meets company standards for format
• Compiles
• Is sufficiently tested at the code level via unit tests
We want to make sure our serverless service:
• Functions as it is supposed to in relation to other components
• Has appropriate mechanisms to handle failures up or down stream
We want to make sure our entire application/infrastructure:
• Functions end to end
• Follows security best practices
• Handles scaling demands

Automates code deployments to any instance
Handles the complexity of updating your
applications
Avoid downtime during application deployment
Rollback automatically if failure detected
Deploy to Amazon EC2 or on-premises servers, in
any language and on any operating system
Integrates with third-party tools and AWS
AWS CodeDeploy

SAM Globals + Safe Deployments
Globals:
Function:
Runtime: nodejs4.3
AutoPublishAlias: !Ref ENVIRONMENT
MyLambdaFunction:
Type: AWS::Serverless::Function
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

Lambda Alias Traffic Shifting & AWS SAM
In SAM:
Note: You can specify a maximum of 10 alarms
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

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

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

Delivery via AWS CodePipeline
Pipeline flow:
1. Commit your code to a source code repository
2. Package/test in AWS CodeBuild
3. Use CloudFormation actions in AWS CodePipeline
to create or update stacks via SAM templates
Optional: Make use of ChangeSets
4. Make use of specific stage/environment parameter
files to pass in AWS Lambda variables
5. Test our application between stages/environments
Optional: Make use of manual approvals

CodePipeline + CloudFormation Parameters
Via referenced parameter file: Via Parameter Overrides:

Via referenced parameter file:
Pros:
• Allows developers to update and provide
parameters via file in the code repository
• Easier to change and iterate via
deployment
Cons:
• Potentially harder to control security or
confidential information passed in

Via Parameter Overrides:Pros:
• Tighter control over parameters
passed in
• Can restrict access to information
based on visibility to CodePipeline and
CloudFormation
Cons:
• Modification requires a change to the
pipeline and a re-execution
• Harder to track the changes to these
values unless you are tracking them
via CloudFormation to manage the
pipeline(as an example)

Source
Source
CodeCommit
MyApplication
An example minimal pipeline:
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
This pipeline:
• Five stages
• Builds code artifact
• Three deployed to
“environments”
• Uses CloudFormation to deploy
artifact and other AWS resources
• Has Lambda custom actions for
running my own testing functions
• Integrates with a third-party
tool/service
• Has a manual approval before
deploying to production

AWS Code Services
Source Build Test Production
Third-Party
Tooling
Software Release Steps:
AWS CodeCommit AWS CodeBuild AWS CodeDeploy
AWS CodePipeline

ü Configure multiple environments
ü Automate your delivery process

Metrics and logs
• Default (free) metrics:
• Invocations
• Duration
• Throttles
• Errors
• Create custom metrics for
health and status tracking
CloudWatch Metrics CloudWatch Logs
• Every invocation generates
START, END and REPORT
entries to CW Logs
• Emit your own log entries
• Use third-party tools for
aggregation and visualization

AWS X-Ray + AWS Lambda
• Collects data about requests that your application serves
• Provides diagnostic tools
• Visibility into the AWS Lambda service
• Breakdown of your function’s performance

Service map
Identify where your errors or latency problems are coming from

Trace view
Zoom in to determine the root cause

DEMO!

aws.amazon.com/serverless

aws.amazon.com/serverless/developer-tools

Additional resources
Serverless Application Model (SAM) - https://github.com/awslabs/serverless-
application-model
Learn more:
AWS Lambda: https://aws.amazon.com/lambda
Amazon API Gateway: https://aws.amazon.com/api-gateway
Products that helped us today:
AWS CloudFormation: https://aws.amazon.com/cloudformation
AWS CodePipeline: https://aws.amazon.com/codepipeline
AWS CodeDeploy: https://aws.amazon.com/codedeploy/
AWS CodeBuild: https://aws.amazon.com/codebuild

Thank you!!!

Building CICD Pipelines for Serverless Applications

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Building CICD Pipelines for Serverless Applications

Similar to Building CICD Pipelines for Serverless Applications (20)

More from Amazon Web Services

More from Amazon Web Services (20)

Building CICD Pipelines for Serverless Applications