Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

The Twelve Factor App

No description
by

Rob Parrott

on 7 June 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of The Twelve Factor App

The 12 Factor App
Future Proofing Application Deployment
DOCKER
An easy, lightweight virtualized environment for portable applications.
The Twelve Factor
App

I. Codebase
One codebase tracked in revision control, many deploys
One-to-one correspondence between an app and a codebase
All "deploys" stem from single codebase

http://12factor.net

Features:
Declarative formats
Clean contract with OS for max portability
Deployable to cloud platforms
Minimize divergence between Dev & Prod
Horizontal scaling
EMERGING STANDARD
NEW PLATFORMS & SERVICES
Manifesto developed by Heroku designers and app builders
Platform and language agnostic approach for app architecture & deployment, particularly well-suited to cloud platforms.

WHY A NEW STANDARD? – INDUSTRY PRESSURES
Clean API
Linux Containers (LXC)
II. Dependencies
Explicitly declare and isolate dependencies
Never rely on the implicit presence of system-wide packages, tools & libs
Always provide a package list with app that states the requirements
Utilize a native package manager, such as
bundler for ruby
Composer for PHP
PIP & VirtualEnv for Python
Never expect to "shell out" to system to use system tools
III. Config
Always store configuration in the environment
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?

IV. Backing Services
Treat backing services as attached resources
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.

V. Build, release, run
Strictly separate build and run stages
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

VI. Processes
Execute the app as one or more stateless processes
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

VII. Port binding
Export services via port binding
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.

VIII. Concurrency
Scale out via the process model
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.

IX. Disposability
Maximize robustness with fast startup and graceful shutdown
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

X. Dev/prod parity
Keep development, staging, and production as similar as possible
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.)

XI. Logs
Treat logs as event streams
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

XII. Admin processes
Run admin/management tasks as one-off processes
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.

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
Need to establish a
standard
that promotes these characteristics
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.
UNIX-inspired
Image registry
Image build service
Image Specification
(Dockerfile)

EXAMPLE
DEMO
SUMMARY
Apps built with 12 Factor thinking enable new hosting models (ex. PaaS)
and new software delivery models focussed on automation, portability, and scalability.
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
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://github.com/huit/docker-drupal
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
.

Docker Engine
http://github.com/huit/docker-drupal
Full transcript