Slide 1
Slide 1 text
The Twelve-Factor App
Slide 2
Slide 2 text
The twelve-factor app is a methodology for building
software-as-a-service apps that:
Slide 3
Slide 3 text
Use declarative formats for setup automation, to minimize
time and cost for new developers joining the project.
Slide 4
Slide 4 text
Have a clean contract with the underlying operating
system, offering maximum portability between execution
environments.
Slide 5
Slide 5 text
Are suitable for deployment on modern cloud platforms,
obviating the need for servers and systems administration.
Slide 6
Slide 6 text
Minimize divergence between development and
production, enabling continuous deployment for maximum
agility.
Slide 7
Slide 7 text
And can scale up without significant changes to tooling,
architecture, or development practices.
Slide 8
Slide 8 text
No content
Slide 9
Slide 9 text
I. Codebase
• One codebase tracked in revision control,
many deploys.
• If there are multiple codebases, it’s not an
app – it’s a distributed system.
Slide 10
Slide 10 text
II. Dependencies
• Explicitly declare and isolate dependencies.
• A twelve-factor app never relies on implicit
existence of system-wide packages.
• Do not rely on the implicit existence of any
system tools.
• pip + virtualenv + requirements.txt
Slide 11
Slide 11 text
III. Config
• Store config in the environment.
• Resource handles to the database,
Memcached, and other backing services.
• Per-deploy values such as the canonical
hostname for the deploy.
• Django & Flask make this simple.
Slide 12
Slide 12 text
IV. Backing Services
• Treat backing services as attached
resources.
• Make no distinction between local and
third party services.
Slide 13
Slide 13 text
No content
Slide 14
Slide 14 text
V. Build, release, run.
• Strictly separate build and run stages.
• It is impossible to make changes to the
code at runtime.
• This allows for rollbacks and other release
management suites.
Slide 15
Slide 15 text
VI. Processes
• Execute the app as one or more stateless
processes.
• $ python app.py
• A production deploy of a sophisticated app
may use many process types, instantiated
into zero or more running processes.
Slide 16
Slide 16 text
VII. Port binding
• Export services via port binding.
• The web app exports HTTP as a service by
binding to a port, and listening to requests
coming in on that port.
• Gunicorn, Gevent, Eventlet.
Slide 17
Slide 17 text
VIII. Concurrency
• Scale out via the process model.
• Using this model, the developer can
architect their app to handle diverse
workloads by assigning each type of work
to a process type.
• Rely on the operating system's process
manager.
Slide 18
Slide 18 text
No content
Slide 19
Slide 19 text
IX. Disposability
• Maximize robustness with fast startup and
graceful shutdown.
• They can be started or stopped a moment’s
notice.
Slide 20
Slide 20 text
X. Dev/prod parity
• Keep development, staging, and production
as similar as possible.
• Failing to do so increases: the time gap,
personnel gap, and the tools gap.
Slide 21
Slide 21 text
Traditional app Twelve-factor app
Time between deploys Weeks Hours
Code authors vs code
deployers
Different people Same people
Dev vs production
environments
Divergent
As similar as
possible
Slide 22
Slide 22 text
XI. Logs
• Treat logs as event streams.
• Apps never concern themselves with
routing or storage of the output stream.
Slide 23
Slide 23 text
XII. Admin processes
• Run admin/management tasks as one-off
processes in an identical environment.
• Run against a release, using the same code
and config as any process run against that
release.
• $ manage.py syncdb
Slide 24
Slide 24 text
12factor.net