AWS Dev Lounge: Applying the Twelve-Factor Application Manifesto to Developing Serverless Applications

Adam Larter
Principal Solutions Architect, Developer Specialist, AWS AU/NZ
2018
D
LOUNGE
EV
Applying the 12-Factor Application Manifesto
to Developing Serverless Applications
2018
alarter@amazon.com | www.linkedin.com/in/adamlarter

D
LOUNGE
EV
Serverless is a mindset change toward
automation, agility, and innovation

D
LOUNGE
EV
The “12 Factor” manifesto & 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 differently

D
LOUNGE
EV
From: 12factor.net

D
LOUNGE
EV
The “12 Factor” App - Goals
• Minimise the effort of getting a new developer set up
• Minimise dependencies on the underlying platform
running the application
• Maximise the portability of the application between
different runtime environments
• Make deploying your application to modern cloud
platforms easy
• Focuses on environment parity between dev/prod
• Allows applications to embrace horizontal scaling

D
LOUNGE
EV
No servers to provision
or manage
Scales with usage
Never pay for idle Availability and fault
tolerance built in
Serverless means…

D
LOUNGE
EV
Serverless application
SERVICES (ANYTHING)
Changes in
data state
Requests to
endpoints
Changes in
resource state
EVENT SOURCE FUNCTION
Node.js
Python
Java
C# (.Net Core)
Go

D
LOUNGE
EV
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
</></>

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

D
LOUNGE
EV
We want to extract vehicle number
plates from images of cars passing
through a toll gantry. The system should
charge drivers in real-time. If the driver
has insufficient funds or there is a
problem reading the number plate, the
system should cater for manual tasks
‘
Toll Road Gantry – Problem Statement

D
LOUNGE
EV
Toll Road Gantry - Overview
• Images captured at gantry using motion-detection camera
• Captured images uploaded to S3
• S3 trigger calls Lambda function to pass image to
Amazon Rekogniton to extract text from the image
• If the text ‘looks like’ a number plate,
we look-up the plate in our database and charge the driver
• If the driver has insufficient funds, we prompt for an account top-up
• If the number plate is not registered, we
request manual intervention from an administrator
• If we are not confident that we can ‘see’ a number plate, we request
manual intervention from an administrator

D
LOUNGE
EV
Amazon
S3
AWS
Lambda
Trigger on
upload
Amazon
Rekognition
Start
End
Toll Road Gantry - Architecture

D
LOUNGE
EV
Amazon
S3
AWS
Lambda
Trigger on
upload
Amazon
Rekognition
Start
End
PROCESS
ACQUIRE

D
LOUNGE
EV
Am azon
CloudW atch
AW S
Lam bda
AW S Step
Functions
Am azon
SES Am azon API
Gatew ay
M anual Inspection via Em ail Notification
Scheduled
event getActivityTask()
sendTaskSuccess()
Num ber Plate
{
...
numberPlate: "SOB640"
...
}
AW S
Lam bda
AGENT

D
LOUNGE
EV
1. Codebase
• A twelve-factor app is always tracked in a
version control system – in a repo
• A codebase is any single repo
• There is always a one-to-one correlation between the codebase
and the app:
• If there are multiple codebases, it’s not an app –
it’s a distributed system.
• Multiple apps sharing the same code is a
violation of 12-factor – factor the code into a library
• There is only one codebase per app, but there will be
many deploys of the app
One codebase tracked in revision control, many deploys

D
LOUNGE
EV
1. Codebase
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 (eg: 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
One codebase tracked in revision control, many deploys

D
LOUNGE
EV
2. Dependencies
• A 12-Factor app never relies on implicit existence of
system-wide packages. It declares all dependencies,
completely and exactly, via a dependency declaration manifest
• It uses a dependency isolation tool to prevent dependency leak from
other and does not depend on the existence of system tools
• Simplifies getting a new developer up and running (all dependencies
are in the source control system – or referenced using dependency
management)
Explicitly declare and isolate dependencies

D
LOUNGE
EV
2. Dependencies
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:
Explicitly declare and isolate 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
• Maven / Gradle for
dependency
management
C# (.NET Core)
• Either .zip file with all
code/dependencies, or a
standalone .dll
• Can use Nuget
• All assemblies (.dll) at
root level

D
LOUNGE
EV
3. Config
Store config in the environment
A 12-Factor App has strict separation of config from code, including:
• Resource handles to database, cache and other backing services
• Credentials
• Per-deploy values
• An app's config is everything that is likely to vary between deploys
(staging, production, developer environments, etc)
• Does not include ‘internal’ configs such as
routes or framework settings
• Store configuration in environment variables
and not in source control

D
LOUNGE
EV
3. Config
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
Store config in the environment
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 and AWS Secrets Manager
Many ways to do this in serverless applications

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’],
WithDecryption=True
)
for parameter in response['Parameters']:
return parameter['Value']
def lambda_handler(event, context):
value = get_parameters()
print("value1 = " + value)
return value # Echo back first key/val
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
AWS Systems Manager – Parameter Store

D
LOUNGE
EV
Access secrets in the Parameter Store
from CloudFormation
• Create Parameters in your
CFN/SAM template
• Set the Type to
AWS::SSM::Parameter::Value<String>
• Use the Default property to
define the path in Parameter Store
• Use references ( Ref: ) in your
template to make use of the values
AWS Systems Manager – Parameter Store

D
LOUNGE
EV
Service features:
• Securely encrypt, store, and
retrieve credentials for your
databases and other services
• Scheduled rotation with control
over rotation logic via Lambda
function
• Connection strings, key/value
pairs, JSON blobs… anything!
AWS Secrets Manager

D
LOUNGE
EV
4. Backing services
Treat backing services as attached resources
The code for a 12-Factor app makes no distinction between
local and third party services.
• A backing service is any service the app consumes
over the network as part of its normal operation
• Databases, cache, etc
• API-accessible services
• Mail
• 12-Factor treats backing services as attached resources
• Backing services should be able to be switched out –
attached/detached at will

D
LOUNGE
EV
4. Backing services
No differences for serverless applications
Resources that Lambda functions connect to, such as databases,
should have their endpoints and access credentials made available
via config resources and IAM policies
!
Treat backing services as attached resources

D
LOUNGE
EV
Strictly separate build and run stages
A 12-Factor App codebase is transformed into a deploy through:
• Build stage – takes the source from the repo and builds an
immutable deployment artefact bundle
• Release stage – takes the deployment artefact and combines it
with the environment’s configuration
• Run stage – runs the app in the target environment, executing
processes against the selected release
Code becomes a build, which is combined with the target
environment’s configuration to create a release then executed in
the run space - each stage is strictly separated

D
LOUNGE
EV
AWS
CodeBuild
AWS
CodePipeline
Strictly separate build and run stages
No differences for serverless applications
Development best practices such as Continuous Integration and
Continuous Delivery should be followed.
Use AWS CodeBuild and AWS CodePipeline to support this

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

D
LOUNGE
EV
Delivery via CodePipeline
Pipeline flow:
1. Commit your code to a source code repository
2. Package/Test in AWS CodeBuild
3. Use CloudFormation actions in CodePipeline to
create or update stacks via SAM templates
Optional:
• Make use of ChangeSets
• Make use of Safe Lambda Deployment
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

D
LOUNGE
EV
AWS Serverless Application Model (SAM)
CloudFormation extension optimized for
serverless
New serverless resource types:
functions, APIs, and tables
Supports anything CloudFormation supports
Open specification (Apache 2.0)
https://github.com/awslabs/serverless-application-model

D
LOUNGE
EV
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
SAM template
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

Gradual Code Deployment – Canaries
SAM usually uses CloudFormation to
deploy new/updates to Lambda functions
If you enable Safe Lambda Deployments,
SAM will instead use AWS CodeDeploy for
automated gradual deployment
Automatically & gradually shift traffic
to the new version and roll back if a problem
is encountered (based on canaries/alarms)
Serverless has new ways to do familiar things

D
LOUNGE
EV
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

D
LOUNGE
EV
Source
Source
AWSCodeCommit
MyApplication
An example minimal production pipeline:
Build
test-build-source
AWSCodeBuild
Deploy Testing
create-changeset
AWS
CloudFormation
execute-changeset
AWS
CloudFormation
Run-stubs
AWSLambda
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
AWSLambda
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

D
LOUNGE
EV
6. Process
A 12-Factor App has processes that are stateless and share nothing
• Any data that needs to persist must be stored in a
stateful backing service, typically a database
• Never assume any data from a previous transaction
will be cached in memory or on local storage
• “Sticky sessions” are a violation of 12-factor
• Session state should be persisted to Memcached or database
Execute the app as one or more stateless processes

D
LOUNGE
EV
6. Process
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 DynamoDB or ElastiCache
Execute the app as one or more stateless processes

D
LOUNGE
EV
7. Port Binding
A 12-Factor App is completely self-contained and exposes
Protocol-as-a-Service by binding to a network port
• For example – web application binding an HTTP listener
to port 80/443
• The app itself should be able to run/host the HTTP endpoint
(Go, Python, DotNet, Java support this)
• Languages like PHP break this guideline because
they need a web server to host the process
• Allows the app to become a backing service for other apps
• Provides a common interface to all your apps
Export services via port binding

D
LOUNGE
EV
7. Port Binding
In Lambda/serverless applications this factor doesn’t apply in the
same way 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
Export services via port binding

Lambda execution model
Synchronous Stream-based
Amazon
API Gateway
AWSLambda
function
Amazon
DynamoDBAmazon
SNS
/order
AWSLambda
function
Amazon
S3
reqs
Amazon
Kinesis
changes
AWSLambda
service
AWSLambda
function
Asynchronous

D
LOUNGE
EV
AmazonS3 Amazon
DynamoDB
Amazon
Kinesis
AWS
CloudFormation
AWS
CloudTrail
Amazon
CloudWatch
Amazon
Cognito
AmazonSNSAmazon
SES
Cronevents
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
AWSIoT AWSStep
Functions

D
LOUNGE
EV
8. Concurrency
Scale out via the process model
In a 12-Factor App, processes are a first-class citizen
• Processes & threads – taking inspiration from Unix process model
for daemons
• Keep individual tasks bound to individual processes
• Web requests handled by dedicated processes
• Worker processes for long-running background tasks
• Small independent processes for specific tasks in a distributed workload
• Very important for scaling your application out horizontally

D
LOUNGE
EV
8. Concurrency
!
Doesn’t apply to Serverless
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.

D
LOUNGE
EV
• <1.8GB is still single core
• CPU bound workloads won’t see gains –
processes share same resources
• >1.8GB is multi-core
• CPU bound workloads will gains,
but need to multi-thread
• I/O bound workloads WILL likely see gains
• e.g. parallel calculations to return
Multi-threading?

Scaling out a workflow with Step Functions
Amazon
S3
AWS
Lambda
Trigger on
upload
Amazon
Rekognition
Start
End
8. Concurrency

D
LOUNGE
EV
9. Disposability
Maximize robustness with fast startup and graceful shutdown
A 12-Factor App’s resources are disposable, meaning they can be
started and stopped at a moment’s notice
• Facilitates fast, elastic scaling, rapid deployment of code or config
changes and robust deployment
• Processes should minimise startup time
• Processes should terminate gracefully
• Processes should be robust against sudden death and be designed
to handle unexpected termination

D
LOUNGE
EV
9. Disposability
!
Some application to Serverless
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.
Maximize robustness with fast startup and graceful shutdown

D
LOUNGE
EV
Anatomy of a Lambda function
Your
function
Language
runtime
Function
container
Compute
substrate

D
LOUNGE
EV
Lambda request lifecycle
Bootstrap
the runtime
Start your
code
Cold start Warm
start
Download
your code
Start new
container
AWS
optimisation
Your
optimisation

D
LOUNGE
EV
Lambda request lifecycle – AWS X-ray

D
LOUNGE
EV
Amazon S3 Trigger
AWS Lambda Service
Your function code

D
LOUNGE
EV
COLD START
TIME

D
LOUNGE
EV
10. Dev/prod parity
Keep development, staging, and production as similar as possible
A 12-Factor App is designed for continuous deployment by keeping
the gap between development and production small
Environments get out of sync due to:
• Time gap – move code between dev and staging as soon as possible
• Personnel gap – no handover of code (DevOps)
• Tools gap – don’t allow the environment tools and services to differ

D
LOUNGE
EV
10. Dev/prod parity
This can be made incredibly easy with serverless applications by:
• Making use of environment/stage variables, Parameter Store or
Secrets Manager 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
• Using SAM CLI for testing Lambda functions and API Gateway
Keep development, staging, and production as similar as possible

D
LOUNGE
EV
SAM CLI
https://github.com/awslabs/aws-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

D
LOUNGE
EV
11. Logs
A 12-Factor App never concerns itself with routing
or storage of its output stream
Treat logs as event streams
• Logs provide visibility into the behavior of a running app
• Logs are the stream of aggregated, time-ordered events collected
from all running processes
• Logs should be captured by the runtime environment and routed to
an appropriate destination for viewing or long-term archival
• Apps themselves should not attempt to write to or manage logfiles
(use a log router eg Fluent)

D
LOUNGE
EV
11. Logs
Logging (as well as Metric collection) are considered
a “universal right” in AWS Lambda:
• ‘Console’ output automatically collected and sent to
Amazon CloudWatch Logs
• Logs can be turned into Metrics – Active Alerting
• 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
Treat logs as event streams

D
LOUNGE
EV
12. Admin processes
Run admin/management tasks as one-off processes
A 12-Factor App has one-off tasks for admin/management
• Tasks should operate in the same environment as the target
environment (so not from the administrator’s laptop)
• Admin code must be part of the release, not managed
separately as an external script
• Follows the dependency guidelines as the rest of the app
• Administrators must be able to remote into the
running environment

D
LOUNGE
EV
12. Admin processes
!
Run admin/management tasks as one-off processes
Doesn’t apply to Serverless
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.

D
LOUNGE
EV
1. Codebase
2. Dependencies
3. Config
4. Backing services
9. Disposability
10. Dev/prod parity
11. Logs
12. Admin processes
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 to serverless
The 12 Factors & Serverless Applications
6. Process
7. Port Binding
8. Concurrency
= Some relevance

D
LOUNGE
EV
Possible new factors for
Serverless 12-Factor Apps

D
LOUNGE
EV
• Use the right amount of compute for your
workload, and test your assumptions
• Review Lambda function resource usage in
CloudWatch Logs after execution
• Consider startup-latency and execution time as
well as RAM usage
• Match resource allocation (up to 3 GB) to logic
A. Right-size your serverless compute
Choose the right compute for the task

D
LOUNGE
EV
Example: Stats for a 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
Impact of memory allocation on execution duration

D
LOUNGE
EV
50% increase
in memory
95th
percentile
changes from
3s to 2.1s
https://blog.newrelic.com/2017/06/20/lambda-functions-xray-traces-custom-serverless-metrics/
Impact of memory allocation on startup latency

D
LOUNGE
EV
B. Avoid fat / monolithic functions
• Implement concise function logic
• Don’t move from monoliths to miniliths!
• Decouple your applications using messaging services
such as SNS/SQS/Kinesis/AmazonMQ
• Embrace asynchronous calls and eventual consistency
Functions should do one thing and do it well

D
LOUNGE
EV
C. Use functions to transform not transport
Read only the data you need
200 seconds and 11.2 cents
for key in src_keys:
response =
s3_client.get_object(Bucket=src_bucket,
Key=key)
contents = response['Body'].read()
for line in contents.split('n')[:-1]:
data = line.split(',’)
srcIp = data[0][:8]
….
95 seconds and costs 2.8 cents
for key in src_keys:
response =
s3_client.select_object_content
(Bucket=src_bucket, Key=key,
expression =
SELECT SUBSTR(obj._1, 1, 8), obj._2
FROM s3object as obj)
contents = response['Body'].read()
for line in contents:
….
Using S3Select:Retrieving entire object:

D
LOUNGE
EV
D. Do not orchestrate in code
• Orchestrating workflow logic in code makes it more difficult to
modify, maintain and debug distributed complexity
• Tasks may be long-running
• Tasks may need manual intervention
• Tasks may need to be retried
• Use AWS Step Functions to handle orchestration externally
Orchestrate distributed complexity in the environment

D
LOUNGE
EV
STARTJOB
JOB#XSTARTED
HTTPPOST
HTTPPOST
AREWETHEREYET?
NOPE!
WE’REDONE!
ZzZz
OR
time.sleep(10)

D
LOUNGE
EV
Amazon
S3
AWS
Lambda
Trigger on
upload
Amazon
Rekognition
Start
End

D
LOUNGE
EV
1. Codebase
2. Dependencies
3. Config
4. Backing services
9. Disposability
10. Dev/prod parity
11. Logs
12. No orchestration
in code
As we’ve seen, 12 Factor application design can still be applied to
serverless applications taking into account some small differences!
The 12 Factors & Serverless Applications
6. Right-sizing
7. Avoid miniliths
8. Transform not
transport

D
LOUNGE
EV
In closing
The 12-Factor methodology has factors that
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 AWS Lambda’s 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!

D
LOUNGE
EV
aws.amazon.com/serverless

D
LOUNGE
EV
aws.amazon.com/serverless/developer-tools

Adam Larter
Principal Solutions Architect, Developer Specialist, AWS AU/NZ
2018
D
LOUNGE
EV
Thank you!
2018
alarter@amazon.com | www.linkedin.com/in/adamlarter

AWS Dev Lounge: Applying the Twelve-Factor Application Manifesto to Developing Serverless Applications

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to AWS Dev Lounge: Applying the Twelve-Factor Application Manifesto to Developing Serverless Applications

Similar to AWS Dev Lounge: Applying the Twelve-Factor Application Manifesto to Developing Serverless Applications (20)

More from Amazon Web Services

More from Amazon Web Services (20)

AWS Dev Lounge: Applying the Twelve-Factor Application Manifesto to Developing Serverless Applications