The Twelve Factor App

The 12 Factor App

XI. Logs

XII. Admin processes

I. Codebase

Treat logs as event streams

Run admin/management tasks as one-off processes

One codebase tracked in revision control, many deploys

• Apps should never concern with managing log threads or storage
• Processes should write all logs to stdout a a stream
• Execution environment captures and routes the log stream
• Use modern log tools such as splunk for capture & analysis

• One-to-one correspondence between an app and a codebase
• All "deploys" stem from single codebase

• Admin processes (such as database migrations or maintenance via console access) should be standalone processes
• Always run in the same environment as the released app, and if possible
• Strongly favor REPL shells provided by framework or platform (i.e. sqlplus, rake, python interpreter.

Future Proofing Application Deployment

X. Dev/prod parity

WHY A NEW STANDARD? – INDUSTRY PRESSURES

Keep development, staging, and production as similar as possible

• Need faster release cycles
• Need to build QA into release process
• Need to reduce operational overhead
• Need for portability
• Need for scalability
• Need for cloud-readiness

EMERGING STANDARD

• Enables fast releases
• Avoids disparity between "Developer's world" and the "Ops world"
• Where possible, should have parity for backing store types as well (databases, etc.)

Need to establish a standard that promotes these characteristics

Platform and language agnostic approach for app architecture & deployment, particularly well-suited to cloud platforms.

The Twelve Factor

App

NEW PLATFORMS & SERVICES

Apps built with 12 Factor thinking enable new hosting models (ex. PaaS)

and new software delivery models focussed on automation, portability, and scalability.

IX. Disposability

III. Config

As standards establish, the apps will find more hosting options, and the hosting platforms more customers.

Expect rapid expansion and convergence around such a standard

Maximize robustness with fast startup and graceful shutdown

Always store configuration in the environment

Features:

• Declarative formats
• Clean contract with OS for max portability
• Deployable to cloud platforms
• Minimize divergence between Dev & Prod
• Horizontal scaling

• Processes can be started or stopped at any time
• Fast startup
• Killed off on a SIGTERM
• Robust against hard failure

• Enables fault-tolerance and rapid- release

• Configuration means whatever may vary between deploys of the same codebase
• Includes URLs and database connctions strings, passwords, hostnames, etc.
• Litmus test: can the codebase be made public without leaking sensitive values?

CONNECTIONS TO IT ROLES

• DevOps practices need the 12 Factor standard to accelerate time to market

• Systems engineers needs 12 Factor in order to reduce the variety of infrastructure designs and services needed to host application

• Operations needs insulation from the specifics of applications and platforms, so they can be more efficient

• Developers need insulation from variations in OS and platform, networks and infrastructure environments.

Manifesto developed by Heroku designers and app builders

VIII. Concurrency

IV. Backing Services

Scale out via the process model

Treat backing services as attached resources

http://github.com/huit/docker-drupal

EXAMPLE

• Scale horizontally by spawning more app processes
• Enabled by statelessness of each unit
• Processes never daemonize, but stay in the foreground
• Launched by OS process manager such as systemd or cloud service, which manages monitoring and restarting.

• Any service an app consumes during normal operation, such as a SQL database, SMTP server, memcached, message queues, S3 object store, generic APIs, etc.
• The code for a twelve-factor app makes no distinction between local and third party services.
• All are attached resources, which can be attached or deattached at will.
• Identified by URLs or connect strings, set as env variables.

DOCKER

UNIX-inspired

Image registry

Clean API

VII. Port binding

VI. Processes

V. Build, release, run

Image build service

Docker Engine

Export services via port binding

Strictly separate build and run stages

Execute the app as one or more stateless processes

An easy, lightweight virtualized environment for portable applications.

Linux Containers (LXC)

Image Specification

(Dockerfile)

DEMO

http://github.com/huit/docker-drupal

• Clear stages
• Build stage: transform codebase into an executable called a "build"
• Release stage: combines a build with configs to create a "release"
• Run stage: runs the released app in an execution enviroment.
• Makes it impossible to change code at runtime
• Runs occur whenever a process starts, even after a reboot, so should be as streamlined as possible

• Any running app is composed of one or more processes
• 12 factor processes are stateless, i.e. do not carry over state between transactions
• State – session state or persisted data – must be stored in an attached service such as a SQL database or memcached service.

• Enables concurrency and horizontal scaling, and fault tolerance

• Processes communicate by binding to a port and listening for requests
• Apps are completely self-contained, and don't require runtime injection into a system web server or similar container
• All processing occurs in user space
• Allows chaining of services, with one becoming a backing service for the next.

• Softer version: if you need a container, bring it along with you and run in user space.

SUMMARY

Apps and processes need to be refactored to better meet the challenges of current marketplace – 12 Factor provides an app-focussed roadmap to meet these

Adherent apps are inherently scalable, portable, and simple to release rapidly and confidently

Rich and rapidly changing landscape of services and tools

DOCKER is generating lots of interest as a lynchpin technology which establishes and clean contract between Dev and Ops

http://12factor.net

Note: almost all content and images in this presentation is copyright Adam Wiggin, http://12factor.net. This presentation is an attempt to capture and condense for a captive audience.