The “Twelve-Factor” application model has come to represent twelve best practices for building modern, cloud-native applications. With guidance on things like configuration, deployment, runtime, and multiple service communication, the Twelve-Factor model prescribes best practices that apply to everything from web applications to APIs to data processing applications. Although Serverless computing and AWS Lambda have changed how application development is done, the “Twelve-Factor” best practices remain relevant and applicable in a Serverless world. In this talk, we’ll apply the “Twelve-Factor” model to Serverless application development with AWS Lambda and Amazon API Gateway and show you how these services enable you to build scalable, low cost, and low administration applications.
2. About me:
Mike Morain - mamorain@amazon.co.uk, @mikemorain
• Specialist Solutions Architect - DevTech
• Coloradan living in London, UK
• Previously:
• AWS Specialist SA – AWS Marketplace - Software Partners
• Software Development Consultant – Slalom Consulting
• Developed software for many industries, including in retail, hospitality,
health care, telecom, enterprise software, security, among others.
• Say ‘cloud native’ and ‘DevOps’ on stage a lot
5. 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
15. 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
16. The 12 Factors:
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
Let’s explore how the 12 Factors apply to a serverless
application:
17. 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
18. 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. Include those packages inside
of your deployment package. Every language Lambda supports has a
model for this:
2. Dependencies
Node.js & Python
• .zip file consisting of
your code and any
dependencies
• Can use npm/pip.
• All dependencies must
be at root level
Java
• Either .zip file with all
code/dependencies, or
standalone .jar with
compiled class &
resource files at root
level, required jars in /lib
directory
• Can use Maven
C# (.NET Core)
• Either .zip file with all
code/dependencies,
or a standalone .dll
• Can use Nuget
• All assemblies (.dll)
at root level
19. 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:
20. 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 CloudTrail
• Can be tagged
• Available via API/SDK
Useful for: centralized environment
variables, secrets control, feature
flags
from __future__ import print_function
import json
import 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
21. 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
!
22. 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 CodeBuild AWS CodePipeline
24. 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
• 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/test tools or
commands in “build”
• Execute the CloudFormation
“package” command to package
your serverless application with
SAM in “post_build”
• Create and store an artifact in S3
Serverless App buildspec.yml Example
25. Delivery via CodePipeline
Pipeline flow:
1. Commit your code to a source code repository
2. Package/Test in CodeBuild
3. Use CloudFormation actions in 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 Lambda variables
5. Test our application between stages/environments
Optional: Make use of Manual Approvals
26. An example minimal Developer’s pipeline:
MyBranch-Source
Source
AWS CodeCommit
MyApplication
Build
test-build-source
AWS 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
27. Source
Source
AWS CodeCommit
MyApplication
An example minimal production 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 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
28. 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 container re-use.
• There is no promise of container 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.
29. 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 via stream
• Instead of having one function support multiple invocation sources,
create independent functions and make use of shared code via
dependencies (shared packages) to support shared capabilities
30. 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
31. 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
32. 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.
!
33. 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.
!
34. 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
38. 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 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
40. 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
41. 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
42. 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.
!
43. 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
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
44. 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!