Twelve-Factor Serverless Applications - MAD303 - Anaheim AWS Summit

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T
Twelve-factor serverless applications
Chris Munns
Principal developer advocate–Serverless
AWS
M A D 3 0 3

About me
Chris Munns - munns@amazon.com, @chrismunns
• Principal Developer Advocate – Serverless
• New Yorker
Previously:
• AWS Business Development Manager, DevOps, July 2015–Feb. 2017
• 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

The “twelve-factor” model and serverless applications
• Twelve-factor applications were popularized by developers building large scale applications
on platforms such as Heroku
• In recent years the twelve-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 twelve-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 twelve-factor guidelines don’t directly align with serverless
applications or are interpreted very differently

From12factor.net
© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T Copyright © 2012 Adam Wiggins.

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
Web apps Backends Data
processing
Chatbots Amazon Alexa IT automation
• Static
websites
• Complex
web apps
• Packages
for Flask
and
Express
• Apps and
services
• Mobile
• IoT
• Real-time
• MapReduce
• Batch
• Powering
chatbot logic
• Powering
voice-
enabled apps
• Alexa Skills
Kit
• Policy engines
• Extending AWS
services
• Infrastructure
management

The twelve factors
Let’s explore how the twelve factors apply to a serverless application
1. Code base
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 API Gateway), 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. Include those packages inside of your deployment
package or into a 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
integrated development
environment (IDE) plugins
• Compiled class and
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/Visual
Studio 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 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:
• 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 Key Management Service (AWS KMS) encryption
• API Gateway stages:
• Key-value pairs available for configuring API Gateway functionality or to pass on to HTTP
endpoints as Uniform Resource Identifier (URI) parameters or configuration parameters
to a Lambda invocation
• AWS Systems Manager parameter store:

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 Simple
Notification Service (Amazon SNS)/Lambda
• Can be secured with AWS Identity and Access
Management (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

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

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
Simple Storage Service (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 Serverless Application Model
(AWS SAM)/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
Lambda
MyApplication

An example minimal production pipeline:
This pipeline:
• Five stages
• Builds code artifact
• Three deployed to “environments”
• Uses AWS SAM/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
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
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 reuse
• There is no promise of execution environment reuse 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 three 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
Lambda
function
/order
Asynchronous (event)
Amazon
SNS
Lambda function
Amazon
S3
reqs
Poll-based
Amazon
DynamoDB
Amazon
Kinesis
changes
Lambda service
Lambda
function

8. Concurrency
12factor.net: “Scale out via the process model”
Serverless apps: Doesn’t apply as Lambda functions will automatically scale 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 percentage 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.722965 sec $0.024628
256 MB 6.678945 sec $0.028035
512 MB 3.194954 sec $0.026830
1024 MB 1.465984 sec $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.722965 sec $0.024628
256 MB 6.678945 sec $0.028035
512 MB 3.194954 sec $0.026830
1024 MB 1.465984 sec $0.024638
Green == Best Red == Worst
-10.25698 sec +$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 + virtual
private cloud (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 SAM to deploy your application
• Can pass environment/stage variables via parameters, mappings, and
imports
• Having a continuous integration and continuous delivery process and tooling
that supports multiple environments or accounts

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 that 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
Amazon API Gateway and takes care of all
mapping/permissions necessary.
Creates a DynamoDB table with five
read-and-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 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, and
runtimes
Can tail production logs from 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 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 because 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 Elastic Compute Cloud Run
Command.
👍

The twelve factors and serverless applications
As we’ve seen, twelve-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

FIN, ACK (in closing)
As we’ve reviewed the twelve-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 closely with twelve-factor guidance
already, so you might be really close to meeting the “twelve-factor” bar
already!

aws.amazon.com/serverless/sam

aws.amazon.com/serverless

Twelve-Factor Serverless Applications - MAD303 - Anaheim AWS Summit

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Twelve-Factor Serverless Applications - MAD303 - Anaheim AWS Summit

Semelhante a Twelve-Factor Serverless Applications - MAD303 - Anaheim AWS Summit (20)

Mais de Amazon Web Services

Mais de Amazon Web Services (20)

Twelve-Factor Serverless Applications - MAD303 - Anaheim AWS Summit