The Twelve Factor Apps

The Twelve Factor Apps
Tomi Vanek, November 2015
http://12factor.net/

sportrider.com, totalmotorcycle.com, autoevolution.com

Scalable and reliable
Flexible to extend / change
Easy to run and administer
Extremely

The Twelve Factors
7. Port binding
8. Concurrency
9. Disposability
10. Dev/Prod parity
11. Logs
12. Admin processes
1. Codebase
2. Dependencies
3. Config
4. Backing Services
5. Build, release, run
6. Processes

Application
Architecture
Developm
ent
Operations

Application
Architecture
Developm
ent
Operations
Building Block
Code &
Configuration
Composite
Application
Build & Run

Building Block
Stateless
Small code base
Code & Configuration
Protection against software
erosion
Distributed development
Composite Application
Modular
Scalable and reliable
Open infrastructure
Lang/platform independence
Build & Run
Easy to deploy
Faster feature delivery
Quality first development

Execute the app as one or more stateless processes
! Processes: Stateless (no state in memory, on disc), share
nothing
! Application is self-contained (no app server)
! Any persistent data stored in stateful backing service
(typically database)
! NO sticky sessions
6. Processes

Scale out via the process model
Process Formation
8. Concurrency
! Scalability per processes
! Each process type (service type) is scaled
independently according requirements
! NO “daemonization” (background
services) - instead explicit process
manager for start / stop / restart and
stream management of processes

! Each running process writes its event stream, unbuffered, to
stdout
! Stream captured by the execution environment and routed
to one or more final destinations for viewing and long-term
archival (Splunk)
! Archival destinations are managed by the execution
environment (not configurable by the app)
Treat logs as event streams
11. Logs

Treat backing services as attached resources
4. Backing Services
! Attached resources, accessed via a URL or
other locator/credentials stored in the
configuration
! No distinction between local and remote
services
! Resources can be attached and detached
to deploys

Export services via port binding
! Services published / available per HTTP URL + port
! Process binding to a port
! May be also other communication protocols than HTTP (XMPP, Redis, …)
7. Port Binding

! Processes can be started or stopped at a moment’s notice
! Minimize process startup time (few seconds)
! Shut down gracefully the processes when they receive a SIGTERM signal from
the process manager (refusing any new requests, allowing any current requests
to finish, and then exiting)
Maximise robustness 
with fast startup and graceful shutdown
9. Disposability

Requirements:
! HTTP request: short processing time (few seconds)
! Long polling: client is able to reconnect after connection
! Worker processes: return current job to the work queue
! All jobs are reentrant (transactions or idempotent operations)
! Robust against sudden death, in the case of a failure in the underlying hardware
9. Disposability

1. Codebase
! One codebase per app.
! Each component in a distributed system is an app,
and each can individually comply with twelve-factor.
! Do not share the same code in multiple apps. Refactor
shared code into libraries which can be included
through the dependency manager.
One codebase tracked in revision control, many deploys

Explicitly declare and isolate dependencies
2. Dependencies
! Do not rely on the implicit existence of system-wide packages and
tools. No future guarantees of existence or version compatibility.
! Declare all dependencies, completely and exactly, via a dependency
declaration manifest.
! Use a dependency isolation tool during execution to ensure that no
implicit dependencies “leak in” from the surrounding system.
! Applied uniformly to both production and development.

Store config in the environment
Node.js:
Java
:
3. Configuration
! Strict separation of config from code.
! Config varies substantially across deploys,
code does not.
! “Config” does not include internal application
config. This type of config does not vary
between deploys
! Independently managed for each deploy.
Never grouped together as “environments”.

Operations
Application
Architecture
Developm
ent
Building Block
Code &
Configuration
Composite
Application
Build & Run

Strictly separate build and run stages
5. Build, Release, Run
! Build stage: transformed 
compiled code & packaged assets + dependencies --> build (executable bundle)
! Release stage: build + config 
immediately executable in an execution environment
! Run stage: runtime 
runs app in execution stage

! Time gap: minimize time to promote code to production
! Personnel gap: programmers participate on deployment,
observe app in production
! Tools gap: avoid different backing services / infrastructure
(DB, MQ, cache, OS, …)
Keep dev, staging and production as similar as possible
10. Development / Production Parity

Run admin/management tasks as one-off processes
! Run admin tasks in the same release / runtime environment
as the app (same code base, same configuration)
! REPL (admin console in app environment) for running
arbitrary code, or inspect application’s models: shell
commands inside the application
12. Admin Processes

Application
Architecture
Developm
ent
Operations
Building Block
(6) Processes
(8) Concurrency
(11) Logs
Code & Configuration
(1) Code base
(2) Dependencies
(3) Configuration
Composite Application
(4) Backing service
(7) Port binding
(9) Disposability
Build & Run
(5) Build, release, run
(10) Dev / prod parity
(12) Admin processes

The Twelve Factor Apps

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to The Twelve Factor Apps

Similar to The Twelve Factor Apps (20)

Recently uploaded

Recently uploaded (20)

The Twelve Factor Apps