Twelve-Factor serverless applications - MAD307 - New York AWS Summit

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T
Twelve-Factor serverless applications
Eric Johnson
Senior Developer Advocate, Serverless
AWS
M A D 3 0 7

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

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

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

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

1. Code base
12Factor.net: “One code base 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 (i.e., 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

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

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

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

3. Config
12Factor.net: “Store config in the environment”
Serverless Apps: Many ways to do this in serverless applications:
• AWS 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 AWS KMS encryption
• API Gateway Stages:
• Key-value pairs available for configuring Amazon 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

AWS Systems Manager – Parameter Store
Centralized store to manage your
configuration data
• Supports hierarchies
• Plaintext or encrypted with AWS KMS
• Can send notifications of changes to Amazon SNS/
AWS Lambda
• Can be secured with IAM
• Calls recorded in 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

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

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

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

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

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 AWS SAM or AWS 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

An example minimal production pipeline:
This pipeline:
• Five stages
• Builds code artifact
• Three deployed to “Environments”
• Uses AWS SAM or AWS CloudFormation to
deploy artifact and other AWS resources
• Has Lambda custom actions for running my
own testing functions
• Integrates with a third-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

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.

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

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

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

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

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.

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

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

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

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();

X-Ray trace example

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 AWS Serverless Application Models (AWS 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

Meet SAM!

AWS 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

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

AWS SAM template
Tells AWS CloudFormation this is an AWS
SAM template it needs to “transform”
Creates an 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 an 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

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

AWS SAM Command Line Interface (AWS SAM CLI)
CLI tool for local development, debugging, testing, deploying, and
monitoring of serverless applications
Supports Amazon 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 Amazon CloudWatch Logs
Can help you build in native dependencies
https://aws.amazon.com/serverless/sam

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

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

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. Code base 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, Cofounder 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 that 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.

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

aws.amazon.com/serverless/sam

aws.amazon.com/serverless

Twelve-Factor serverless applications - MAD307 - New York AWS Summit

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Twelve-Factor serverless applications - MAD307 - New York AWS Summit

Similar to Twelve-Factor serverless applications - MAD307 - New York AWS Summit (20)

More from Amazon Web Services

More from Amazon Web Services (20)

Twelve-Factor serverless applications - MAD307 - New York AWS Summit