Twelve-Factor Serverless Applications

P U B L I C S E C T O R
S U M M I T
Washington, DC

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.P U B L I C S E C TO R
S U M M I T
12 Factor Serverless
Applications
Eric Johnson
Senior Developer Advocate - Serverless
AWS
3 1 1 0 2 3

S U M M I T
Who Am I?
• @edjgeek
• Sr. Developer Advocate – Serverless, AWS
• Serverless/Tooling/Automation Geek
• Dad of five
• Husband of one
• Musician Drummer

S U M M I T

S U M M I T
The “12 Factor” model & serverless applications
• 12 Factor applications were popularized by developers building large scale
applications on platforms such as Heroku
• In recent years the 12 Factor guidelines have been considered best practices for
both developers and operations engineers regardless of the application’s use-case
and at nearly any scale
• Many of the 12 Factor guidelines align directly with best practices for serverless
applications and are improved upon given the nature of AWS Lambda, Amazon API
Gateway, and other AWS services
• However, some of the 12 Factor guidelines don’t directly align with serverless
applications or are interpreted very differently

S U M M I T
Serverless applications
Event source Function Services
Changes in
data state
Requests to
endpoints
Changes in
Resource state
Node.js
Python
Java
C#
Go
Ruby
Runtime API

S U M M I T
Common Lambda Use Cases
Amazon API Gateway Amazon
S3
Amazon SNS
Amazon
SQS
Amazon
Kinesis
Amazon
CloudWatch
Web or Mobile
Backend
File Processing Queue Processing
Notification ProcessingReal-Time Stream
Processing
Schedule Jobs

S U M M I T
The 12 factors
Let’s explore how the 12 Factors apply to a serverless application:
1. Codebase
2. Dependencies
3. Config
4. Backing services
5. Build, release, run
6. Process
7. Port Binding
8. Concurrency
9. Disposability
10.Dev/prod parity
11.Logs
12.Admin processes

S U M M I T
1. Codebase
12Factor.net: “One codebase tracked in revision control, many deploys”
Serverless Apps: All code should be stored in revision control (a
development best practice). The same repository should be used for all
environments deployed to. The bounds of an “application” differ in
serverless terms:
• If events are shared (ie. a common Amazon API Gateway) then
Lambda function code for those events should be put in the same
repository
• Otherwise break “services” along event source into their own
repositories

S U M M I T
2. Dependencies
12Factor.net: “Explicitly declare and isolate dependencies”
Serverless Apps: Code that needs to be used by multiple functions should
be packaged into its own library. Place those packages inside of your
deployment package or into a AWS Lambda Layer.
Node.js, Python, Ruby
• .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
Go
• .zip file consisting of
your Go binary and
any dependencies
• Use “go get” to install
dependencies

S U M M I T
Lambda Layers
Lets functions easily share code: Upload layer
once, reference within any function
Layer can be anything: dependencies, training
data, configuration files, etc.
Promote separation of responsibilities, lets
developers iterate faster on writing business
logic
Built in support for secure sharing by ecosystem

S U M M I T
Using Lambda Layers
• Put common components in a ZIP file and
upload it as a Lambda Layer
• Layers are immutable and can be versioned to
manage updates
• When a version is deleted or permissions to use
it are revoked, functions that used it previously
will continue to work, but you won’t be able to
create new ones
• You can reference up to five layers, one of which
can optionally be a custom runtime
Lambda
Layers
arn:aws:lambda:region:accountId:layer:shared-lib :1
Lambda
Layers
arn:aws:lambda:region:accountId:layer:shared-lib:2
Lambda
Layers
arn:aws:lambda:region:accountId:layer:shared-lib:3

S U M M I T
3. Config
12Factor.net: “Store config in the environment”
Serverless Apps: Many ways to do this in serverless applications:
• Lambda Environment Variables:
• Key-value pairs available via standard environment variable APIs such as
process.env for Node.js or os.environ for Python
• Support KMS encryption
• API Gateway Stages:
• Key-value pairs available for configuring API Gateway functionality or to pass on to
HTTP endpoints as URI parameters or configuration parameters to a Lambda
invocation
• AWS Systems Manager Parameter Store:

S U M M I T
AWS Systems Manager – Parameter Store
Centralized store to manage your
configuration data
• supports hierarchies
• plain-text or encrypted with KMS
• Can send notifications of changes to Amazon
SNS/ AWS Lambda
• Can be secured with IAM
• Calls recorded in AWS CloudTrail
• Can be tagged
• Integrated with AWS Secrets Manager
• Available via API/SDK
Useful for: centralized environment
variables, secrets control, feature flags
from __future__ import print_function
import json, boto3
ssm = boto3.client('ssm', 'us-east-1')
def get_parameters():
response = ssm.get_parameters(
Names=['LambdaSecureString'],WithDe
cryption=True
)
for parameter in
response['Parameters']:
return parameter['Value']
def lambda_handler(event, context):
value = get_parameters()
print("value1 = " + value)
return value # Echo back the first key
value

S U M M I T
4. Backing services
12Factor.net: “Treat backing services as attached resources”
Serverless Apps: No differences. Resources that AWS Lambda
functions connect to, such as databases, should have their endpoints
and access credentials made available via config resources or IAM
policies
👍

S U M M I T
5. Build, release, run
12Factor.net: “Strictly separate build and run stages”
Serverless Apps: No differences. Development best practices such as
Continuous Integration and Continuous Delivery should be followed.
• Use AWS CodeBuild and AWS CodePipeline to support this:
AWS CodePipelineAWS CodeBuild

S U M M I T
buildspec.yml Example
version: 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

S U M M I T
buildspec.yml Example
• 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
version: 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

S U M M I T
An example minimal Developer’s pipeline:
MyBranch-Source
Source
CodeCommit
Build
test-build-source
CodeBuild
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
MyDev-Deploy
create-changeset
AWS CloudFormation
execute-changeset
AWS CloudFormation
Run-stubs
AWS Lambda
MyApplication

S U M M I T
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 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

S U M M I T
6. Process
12Factor.net: “Execute the app as one or more stateless processes”
Serverless Apps: This is inherent in how Lambda is designed already:
• Lambda Functions should be treated as stateless despite the potential to
store some state in-between execution environment re-use.
• There is no promise of execution environment re-use between function
invocations.
• Data that needs to be kept should be stored off Lambda in a stateful
service such as a database or cache.

S U M M I T
7. Port Binding
12Factor.net: “Export services via port binding”
Serverless Apps: In Lambda/serverless applications this factor doesn’t
apply the same due to a difference in how Lambda Functions are accessed:
• Instead of a “port” Lambda functions are invoked via one or more
triggering services or AWS’s APIs for Lambda
• When it comes to Lambda functions there are 3 models for how they can
be invoked; synchronously, asynchronously, and poll-based
• Instead of having one function support multiple invocation sources,
create independent functions

S U M M I T
AWS Lambda API
1. Lambda directly invoked
via invoke API
SDK clients
Lambda
function
API provided by the Lambda service
Used by all other services that invoke
Lambda across all models
Supports sync and async
Can pass any event payload structure you
want
Client included in every SDK

S U M M I T
Lambda execution model
Synchronous (push)
Amazon
API Gateway
AWS Lambda
function
/order
Asynchronous
(event)
Amazon
SNS
AWS Lambda
function
Amazon
S3
reqs
Poll-based
Amazon
DynamoDB
Amazon
Kinesis
changes
AWS Lambda
service
function

S U M M I T
8. Concurrency
12Factor.net: “Scale out via the process model”
Serverless Apps: Doesn’t apply as Lambda functions will scale
automatically based on load. You can fork threads inside of your function
execution but there are practical limits due to the memory and CPU/network
constraints of your functions based on how you configure them.
👍

S U M M I T
Tweak your function’s computer power
Lambda exposes only a memory control, with the % of CPU core and
network capacity allocated to a function proportionally
Is your code CPU, Network or memory-bound? If so, it could be
cheaper to choose more memory.

S U M M I T
Smart resource allocation
Match resource allocation (up to 3 GB!) to logic
Stats for Lambda function that calculates 1,000 times all prime numbers
<= 1,000,000
128 MB 11.722965sec $0.024628
256 MB 6.678945sec $0.028035
512 MB 3.194954sec $0.026830
1024 MB 1.465984sec $0.024638
Green==Best Red==Worst

S U M M I T
Smart resource allocation
Match resource allocation (up to 3 GB!) to logic
Stats for Lambda function that calculates 1,000 times all prime numbers
<= 1,000,000
128 MB 11.722965sec $0.024628
256 MB 6.678945sec $0.028035
512 MB 3.194954sec $0.026830
1024 MB 1.465984sec $0.024638
Green==Best Red==Worst
-10.25698sec +$0.00001

S U M M I T
9. Disposability
12Factor.net: “Maximize robustness with fast startup and graceful
shutdown”
Serverless Apps: Shutdown doesn’t apply as Lambda functions and their
invocation are tied directly to incoming events. Speed at startup does
matter though and is a factor of deployment package size + language used
+ VPC (or not) + pre-handler code calls.
👍

S U M M I T
AWS X-Ray
Profile and troubleshoot serverless
applications:
• Lambda instruments incoming
requests for all supported
languages and can capture calls
made in code
• API Gateway inserts a tracing
header into HTTP calls as well as
reports data back to X-Ray itself
var AWSXRay = require(‘aws-xray-sdk-core‘);
var AWS = AWSXRay.captureAWS(require(‘aws-
sdk’));
S3Client = AWS.S3();

S U M M I T
X-Ray Trace Example

S U M M I T
10. Dev/prod parity
12Factor.net: “Keep development, staging, and production as similar as
possible”
Serverless Apps: This can be made incredibly easy with serverless
applications by:
• Making use of environment/stage variables or Parameter Store for
configuration information, backend resources, etc
• Using Serverless Application Models (SAM) to deploy your application
• Can pass environment/stage variables via Parameters, Mappings,
Imports
• Having a CI/CD process and tooling that supports multiple environments
or accounts

S U M M I T
Meet
SAM!

S U M M I T
AWS Serverless Application Model (SAM)
AWS CloudFormation extension optimized for
serverless
Special serverless resource types: functions,
APIs, tables, Layers, and Applications
Supports anything AWS CloudFormation supports
Open specification (Apache 2.0)
https://aws.amazon.com/serverless/sam

S U M M I T
AWS 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: nodejs6.10
Policies: AmazonDynamoDBReadOnlyAccess
Events:
GetHtml:
Type: Api
Properties:
Path: /{proxy+}
Method: ANY
ListTable:
Type: AWS::Serverless::SimpleTable

S U M M I T
AWS SAM Template
Tells AWS CloudFormation this is a
SAM template it needs to “transform”
Creates a AWS Lambda function with
the referenced managed AWS IAM
policy, runtime, code at the referenced
zip location, and handler as defined.
Also creates an Amazon API Gateway
and takes care of all
mapping/permissions necessary
Creates a Amazon DynamoDB table
with 5 Read & Write units
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: nodejs6.10
Policies: AmazonDynamoDBReadOnlyAccess
Events:
GetHtml:
Type: Api
Properties:
Path: /{proxy+}
Method: ANY
ListTable:
Type: AWS::Serverless::SimpleTable

S U M M I T
https://github.com/awslabs/aws-serverless-samfarm/blob/master/api/saml.yaml
<-THIS
BECOMES THIS-
>
AWS SAM Template

S U M M I T
AWS SAM Command Line Interface (AWS SAM CLI)
CLI tool for local development, debugging, testing, deploying,
and monitoring of serverless applications
Supports API Gateway “proxy-style” and Lambda service API
testing
Response object and function logs available on your local
machine
Uses open source docker-lambda images to mimic Lambda’s
execution environment such as timeout, memory limits,
runtimes
Can tail production logs from AWS CloudWatch logs
Can help you build in native dependencies
https://aws.amazon.com/serverless/sam

S U M M I T
11. Logs
12Factor.net: “Treat logs as event streams”
Serverless Apps: Logging (as well as Metric collection) are considered a
“universal right” in Lambda:
• Console output automatically collected and sent to Amazon CloudWatch
Logs
• Logs can be turned into Metrics
• Logs can be sent to Amazon S3 or Amazon ElasticSearch Service easily
for further inspection and trending
• Metrics for Lambda and API Gateway for several key stats are
automatically collected and sent to CloudWatch
• You can easily send more using the CloudWatch SDK

S U M M I T
12. Admin processes
12Factor.net: “Run admin/management tasks as one-off processes”
Serverless Apps: Doesn’t apply to Lambda since you already limit your
functions based on use case. True administrative tasks would occur via
their own Lambda Functions or via tools such as Amazon EC2 Run
Command.
👍

S U M M I T
The 12 Factors & Serverless Applications:
As we’ve seen, 12 Factor application design can still be applied to
serverless applications taking into account some small differences!
= Works similarly = Not relevant
1. Codebase 5. Build, release, run 9. Disposability
2. Dependencies 6. Process 10. Dev/prod parity
3. Config 7. Port Binding 11. Logs
4. Backing services 8. Concurrency 12. Admin processes

“
Pinpoint Moves Production Times from
Weeks to Minutes with AWS Lambda
Pinpoint needed to simplify—both their
internal workflow and analytics
processing pipeline, as well as the
process for building microservices
across their various teams and
products.
Pinpoint switched from using
Kubernetes to AWS Lambda to rewrite
their entire API tier, internal workflow,
and analytics processing pipeline.
• Deploys fixes and features multiple
times a day
• Simplifies internal workflow and
analytics processing
• Scales the adoption of
microservices across teams and
products
SolutionChallenge Benefits
Company: Pinpoint
Industry: Software Data Science
Country: United States
Website: www.pinpoint.com
”
“
- Jeff Haynie, Co-founder and CEO at Pinpoint
We can have a commit roll into production…in literally
minutes, as well as provide a bunch of flexible routing
options dynamically.
Pinpoint provides actionable insights for
software executives. By applying data
science to unearth how organizations
really work, Pinpoint helps leaders
advance the way people and teams
deliver software.
About Pinpoint

“
Autodesk Saves 99% with AWS Lambda,
Amazon DynamoDB & Amazon API Gateway
Setting up accounts was a
bottleneck for Autodesk’s two-
person team. The account creation
process was manual with static
configurations, and making any
changes or updates required a team
member to sign into hundreds of
accounts, one at a time, resulting in
two-week turnarounds.
Autodesk built “Tailor,” a solution using
Amazon DynamoDB for data
persistence and Amazon API Gateway
for API endpoints, and automated all
processes using AWS Lambda.
Autodesk developers now submit an
online form to request a new account
and an API request triggers the
account-creation process.
• Saves 99% of previous costs
• Supports queries by account
number, email address, or IP
address
• Saves up to one month of
development time
Company: Autodesk
Industry: Software products for
Entertainment,
Architecture, Construction,
Engineering, Manufacturing
& Media Industries
Website: www.autodesk.com
Autodesk offers software products
aimed at the architecture, construction,
engineering, manufacturing, media and
entertainment industries.
Headquartered in California, Autodesk
has 10,000 employees in offices around
the world.
“ Prior to implementing Tailor, our cost to provision each
account was about $500 in employee time. It’s just shy
of $6 per account (now), which means we can create
about 10 times as many accounts for the same cost.
- Alan Williams, Enterprise Architect at Autodesk
About Autodesk

“
FINRA Doubles Cost Efficiency with AWS
Lambda
Data is ingested into Amazon S3 via
FTP and AWS Lambda performs the
validations. Amazon EC2 manages
data feeds coming into, and notifications
going out of, AWS Lambda. Amazon
SQS is used for input /output messaging
notifications while Amazon VPC
partitions the system into separate test
and production accounts.
• Delivered solution in three months
• Accelerated data validation by
700%
• Increased cost efficiency by a factor
of two
Company: FINRA
Industry: Financial Regulatory Non-
Profit
Website: www.finra.org
The Financial Industry Regulatory
Authority (FINRA) is a not-for-profit
organization which protects investors
and ensures market integrity through
effective regulation of 3,800 broker-
dealers. They write and enforce rules,
examine firms for compliance, foster
market transparency, and educate
investors.
“ Using AWS Lambda, we’ve increased cost efficiency
by a factor of two. We only pay for what we use, and
we don’t have to manage on-premises server
infrastructure.”
- Tim Greisback, Senior Director of Technology, FINRA
About FINRA
FINRA validates the data of 50,000
broker-dealer OATS (Order Audit
Trail System) files and formats them
according to 200 rules, which totals
half a trillion validations each day.
FINRA needed a solution that could
scale with processing demand,
which can double or triple in
response to market conditions.

S U M M I T
FIN, ACK (in closing)
As we’ve reviewed the 12 Factor methodology for applications we’ve
seen which factors do and do not apply the same for serverless
applications:
• Thinking about code reusability and how to scope your functions to
the smallest size necessary provides many benefits
• Factors related to underlying process management, network ports,
concurrency, and admin processes are largely not an issue in
serverless applications due to Lambda’s product design and
features
• Best practices for serverless align pretty closely with 12 Factor
guidance already, so you might be really close to meeting the “12
Factor” bar already!

S U M M I T
aws.amazon.com/serverless/sam

S U M M I T
aws.amazon.com/serverless

Thank you!
S U M M I T
Eric Johnson
@edjgeek

Twelve-Factor Serverless Applications

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Twelve-Factor Serverless Applications

Similar to Twelve-Factor Serverless Applications (20)

More from Amazon Web Services

More from Amazon Web Services (20)

Twelve-Factor Serverless Applications