Twelve-factor serverless applications - MAD302 - Santa Clara 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 2

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

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 AWS Lambda use cases
Web apps Backends Data
processing
Chatbots Amazon Alexa IT automation
• Static
websites
• Complex
web apps
• Packages
for Flask
and
Express
• Apps &
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 12 factors
Let’s explore how the 12 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 Amazon 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 an 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 / 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 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:

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/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/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 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 % 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 SAM to deploy your application
• Can pass environment/stage variables via parameters,
mappings, and imports
• Having a CI/CD process and tooling that supports multiple
environments or accounts

AWS Serverless Application Model (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 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 five 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 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 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 Amazon 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 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

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 closely with 12 factor guidance
already, so you might be really close to meeting the “12 factor”
bar already!

Twelve-factor serverless applications - MAD302 - Santa Clara AWS Summit

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Twelve-factor serverless applications - MAD302 - Santa Clara AWS Summit

Semelhante a Twelve-factor serverless applications - MAD302 - Santa Clara AWS Summit (20)

Mais de Amazon Web Services

Mais de Amazon Web Services (20)

Twelve-factor serverless applications - MAD302 - Santa Clara AWS Summit