Build Modern Applications that Align with Twelve-Factor Methods (API303) - AWS re:Invent 2018

© 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved.
Building Modern Applications that
Align with 12-Factor Methods
Adam Larter
Principal Solutions Architect, Developer Specialist
Australia
A P I 3 0 3

Presentation will be on
Slideshare within the week

The “12 factor” manifesto & serverless applications
• 12-factor applications were popularized by developers building large-
scale applications on platforms such as Heroku
• 12-factor guidelines are considered best practices for developers and
operations engineers regardless of the application’s use case and scale
• Many of the 12-factor guidelines align directly with best practices for
serverless applications and are enhanced due to the nature of AWS
Lambda, Amazon API Gateway, AWS Step Functions and other services
• However, some of the 12-factor guidelines don’t directly align with
serverless applications or are interpreted differently

From: 12factor.net

https://commons.wikimedia.org/wiki/File:HK_Toll_
road_gates_n_Autotoll_sign_in_yellow_color.JPG
12-factor serverless real-world application
Toll road vehicle number plate processor
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.

12-factor serverless real-world application
• Images captured at gantry using
motion-detection camera & uploaded to
Amazon Simple Storage Service (Amazon S3)
• Amazon S3 trigger calls Lambda function to
pass image to Amazon Rekognition
to extract text from the image
• Look up the plate in database & charge account
• If the account has insufficient funds,
prompt account holder for an account top-up
• If the number plate is not registered,
request manual intervention from an admin
• If confidence is low, request manual intervention
from an admin
https://commons.wikimedia.org/wiki/File:HK_Toll_
road_gates_n_Autotoll_sign_in_yellow_color.JPG

Trigger on
upload
Start
End
Toll road gantry—Architecture
Lambda functionBucket with objects

The 12 factors
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

Compute and invocation
The 12 factors
• Codebase
• Dependencies
• Config
• Build, release, run
• Dev/prod parity
• Concurrency
• Process
• Port-binding
• Disposability
• Logs
• Admin processes
• Backing services
Isolation & dependency
management
Deployment automation Compute and invocation Application support

Today’s agenda
• Logs
• Admin processes
• Backing services
Application support
• Codebase
• Dependencies
• Config
management
Part 1
• Dev/prod parity
Deployment automation
Part 2
• Concurrency
• Process
• Port-binding
• Disposability
Part 3

If there are multiple codebases, it’s not
an app—it’s a distributed system.
Track in multiple repositories.
1. Codebase
One codebase tracked in revision
control, many deploys

Trigger on
upload
Start
End
Lambda FunctionBucket with objects
PROCESS
ACQUIRE

Scheduled
event getActivityTask()
sendTaskSuccess()
Number plate
{
...
numberPlate: "SOB640"
...
}
Toll road gantry—ArchitectureAGENT
WEBSITE
Manual inspection via email notification
Email
Lambda function
Lambda function

Use a dependency isolation tool to
prevent dependency leak. Declare all
dependencies and never rely on
implicit existence of packages.
2. Dependencies
Explicitly declare and
isolate dependencies

Config is anything that may vary
between deploys of the application.
Strictly separate config from code
using environment variables.
3. Config
Store config in
the environment

Separating config from code
• Lambda environment variables
• Key/Value pairs available via standard environment variable APIs such as process.env
• Amazon API Gateway stage variables
• Key-value pairs available for configuring API Gateway functionality
or to pass on to HTTP endpoints
• With IaC, your AWS CloudFormation/SAM templates are also code so
configuration must be separated from the templates
• We will use Amazon Elastic Compute Cloud (Amazon EC2) Systems Manager Parameter Store
and access the parameters directly from AWS CloudFormation

AWS Systems Manager Parameter Store
Access secrets in the Parameter Store
from AWS 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 Secrets Manager
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!

Task 1—Baseline for configuration
BASELINE
Amazon
DynamoDB
table name
Manual image
inspection target
email address
Number plate
regular expression
Charge per
vehicle detected
Created using AWS CloudFormation
Created manually
Created manually

• Create and configure your AWS Cloud9 IDE
• Deploy the Baseline environments for staging and prod
• Configure SSM parameters and Secrets Manager secrets
• Populate DynamoDB
bit.ly/12FactorWorkshop1

• Codebase
• Dependencies
• Config
management
Part 1
• Dev/prod parity
Deployment automation
Part 2
• Concurrency
• Process
• Port-binding
• Disposability
Part 3

Automation
sam package --template template.yml
--s3-bucket tollroadgantryworkshop-012345678912
--output-template template-export.yml
--region ap-southeast-1
sam deploy --template-file template-export.yml
--stack-name TollRoadGantrySystem-Baseline-Staging
--region ap-southeast-1
sam package == aws cloudformation package
sam deploy == aws cloudformation deploy

AWS Serverless Application Model (AWS SAM)
• CloudFormation extension optimized for serverless
• New serverless resource types:
functions, APIs, and tables
• Supports anything AWS CloudFormation
supports—mix AWS SAM and AWS CloudFormation in
the same template
• Open specification (Apache 2.0)

Code becomes a build, which is combined
with the target environment’s config to
create a release then executed in the run
space—each stage is strictly separated.
5. Build, release, run
Strictly separate
build and run stages

AWS code services
Source Build Test Production
Third-party
tooling

12-factor apps are designed for
continuous deployment by keeping
the gap between development and
production small.
10. Dev/prod parity
Keep development, staging, and
production as similar as possible

AWS CodePipeline No build phase for prod
Same deployment artifact

• Deploy the process, acquire, agent and website CI/CD pipelines
• Verify your email address for use with Amazon Simple Email Service (Amazon SES)

Manuallycreated
Createdbyscript
Process Acquire Website Agent

Configuration is shared
between components
via SSM Parameter Store
Process Acquire Website Agent

Apps should be stateless and share
nothing. Any data that needs to
persist must be stored in a stateful
backing service (typically, a database).
6. Process
Execute the app as
one or more stateless processes

WEBSITE
{
...
...
}
sendTaskSuccess()
Lambda function

Apps should be completely
self-contained and expose
protocol-as-a-service by
binding to a network port.
7. Port binding
Export services
via port binding

AWS Lambda execution model
/order
events/triggers
Synchronous Asynchronous Stream-based
Lambda function Lambda function
events/triggers
Lambda function

Resources are disposable, meaning
they can be started and stopped at a
moment’s notice. Processes should
minimize startup time and
terminate gracefully. 9. Disposability
Maximize robustness with
fast startup & graceful shutdown

In 12-factor apps, processes are
first-class citizens. Keep individual tasks
bound to individual processes and scale
your application out horizontally.
8. Concurrency
Scale out via the
process model

Building applications out of distributed functions
• “I want to sequence functions”
• “I want to run functions in parallel”
• “I want to select functions based on input data or current state”
• “I want to retry functions with backoff”
• “I want try/catch/finally”
• “I have code that runs for hours or needs manual intervention”
Coordination of asynchronous functions

What would an orchestration solution look like?
• Scales out
• Doesn’t lose state
• Deals with errors/timeouts/retries
• Easy to build & operate—declarative, not code-based
• Automatable
• Auditable
• Visible and traceable
Coordination must-haves

• Fully managed service
making it easy to coordinate the
components of distributed applications
and microservices using visual
workflows
• You construct your application’s flows
as a state machine, a series of
steps that together capture the
behavior of the application
AWS Step Functions

AWS Step Functions: State types
Parallel steps Choice state Catch failure
Retry failure Wait state

Quick anatomy of a state machine
• Each state is named uniquely but arbitrarily
• StartAt—the entry point
• Each state has a type—choice, pass, parallel, fail, wait, task …
• Every non-fatal state has a next state
• A fatal state is denoted by End:true or Type:Fail
• Task states have a resource attribute that defines
how the state will complete
• Tasks can declare a retry clause based on the type of
application-defined error that has occurred

“I want to retry functions”
We get transient errors from a RESTful
service we depend on, once every four or
five times we call it. But if we keep
retrying, it eventually works.

{
"Comment": "Call out to a RESTful service",
"StartAt": "Call out",
"States": {
"Call out": {
"Type": "Task",
"Resource":
"arn:aws:lambda:ap-southeast-2:123456789012:function:RESTCall",
"Retry": [
{ "ErrorEquals": [ ”MyTransientError" ], "MaxAttempts": 10 }
],
"End": true
}
}
}
AWS Step Functions: Error handling & retries

“I want to handle errors depending on type”
Depending on the application-defined
error that is thrown from each step, I
want to branch and implement relevant
decision logic.

"state.process.Type.NumberPlateDetected":
{
"Type": "Task",
"Resource": "arn:aws:lambda:xxxxx",
"Next": "state.process.Complete",
"Catch": [
{
"ErrorEquals": ["DatabaseAccessError"],
"ResultPath": "$.Exception",
"Next": "state.error.GeneralException"
},
{
"ErrorEquals": ["States.ALL"],
"ResultPath": "$.Exception",
"Next": "state.error.GeneralException"
}]
}
AWS Step Functions: Error handling

Throwing errors from NodeJS

Tasks, activities and Lambda functions
• A task is a unit of work.
• Tasks can be implemented by a Lambda function or an activity
that is a placeholder for any compute engine to implement—
on-cloud or off-cloud.
• The activity must be resolved by either calling the
SendTaskSuccess or SendTaskFailure APIs.
• By implementing a task as an activity, you can implement manual
steps in the state machine. A Lambda function won’t be called
automatically for an activity task.

"state.process.Type.Unknown":
{
"Type": "Task",
"Resource" : "arn:aws:states:::activity:ManuallyDecide",
"TimeoutSeconds": 3600,
"HeartbeatSeconds": 60,
"Next": ”ContinueTaskAfterManualStep"
}
AWS Step Functions: Activities
If HeartbeatSeconds is provided, the provider must call SendTaskHeartbeat()
within the specified time or the task will fail

Waiting for a manual activity to complete
• state.process.Type.ManualDecisionRequired is of type activity
• A polling agent periodically checks for activity tasks and obtains a
token to refer to the activity via a call to
stepfunctions::getActivityTask()
• Email sent to an operator with “manual decision” links
• When clicked, the links resolve the task as successful or not
• Implemented by a Lambda function behind API Gateway

Scheduled
event getActivityTask()
sendTaskSuccess()
Number plate
{
...
...
}
Toll road gantry—ArchitectureAGENT
WEBSITE
Manual Inspection via email notification
Email
Lambda function
Lambda function

• Implement the AWS Lambda functions
• Implement the AWS Step Function
• End-to-end test

bit.ly/12FactorWorkshop1

Thank you!
Adam Larter
Principal Solutions Architect, Developer Specialist
Australia
alarter@amazon.com | www.linkedin.com/in/adamlarter

Build Modern Applications that Align with Twelve-Factor Methods (API303) - AWS re:Invent 2018

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Build Modern Applications that Align with Twelve-Factor Methods (API303) - AWS re:Invent 2018

Similar to Build Modern Applications that Align with Twelve-Factor Methods (API303) - AWS re:Invent 2018 (20)

More from Amazon Web Services

More from Amazon Web Services (20)

Build Modern Applications that Align with Twelve-Factor Methods (API303) - AWS re:Invent 2018