Send the link below via email or IMCopy
Present to your audienceStart 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
The Twelve Factor App
Transcript of The Twelve Factor App
Future Proofing Application Deployment
An easy, lightweight virtualized environment for portable applications.
The Twelve Factor
One codebase tracked in revision control, many deploys
One-to-one correspondence between an app and a codebase
All "deploys" stem from single codebase
Clean contract with OS for max portability
Deployable to cloud platforms
Minimize divergence between Dev & Prod
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
Linux Containers (LXC)
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
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
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
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.
: if you need a container, bring it along with you and run in user space.
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.
Maximize robustness with fast startup and graceful shutdown
Processes can be started or stopped at any time
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.)
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
that promotes these characteristics
: 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.
Image build service
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
CONNECTIONS TO IT ROLES
practices need the 12 Factor standard to accelerate time to market
needs 12 Factor in order to reduce the variety of infrastructure designs and services needed to host application
needs insulation from the specifics of applications and platforms, so they can be more efficient
need insulation from variations in OS and platform, networks and infrastructure environments