The document discusses the 12 Factor App methodology for building scalable software-as-a-service applications. The 12 factors are: use one codebase tracked in version control; declare and isolate dependencies; store config in the environment; treat backing services as attached resources; separate build and run stages; execute the app as stateless processes; export services via port binding; scale out via processes; maximize robustness with fast startup and graceful shutdown; keep development, staging, and production environments similar; treat logs as event streams; and run admin/management tasks as one-off processes.
7. 12 Factor App – Codebase
One codebase, multiple deploys
Use version control like ‘git’
If there are multiple codebases, it’s not an app – it’s a
distributed system
Multiple apps sharing the same code is a violation of
twelve-factor
The codebase is the same across all deploys, although
different versions may be active in each deploy
9. 12 Factor App – Dependencies
Explicitly Declare and isolate
Declare dependencies in a manifest
Use isolation tools
Specific version are important
Never rely on implicit existence of system wide packages
Eg. nodejs ‘package.json’ / Ruby Gem file etc
11. 12 Factor App – Config
Store in the environment
Information required to host a deployment of your codebase
Mainly DB Credentials, path, resources etc
Should be strictly separated from code
Configuration belongs in the environment not in the application
No config in git
Use Environment vars (like ENV['DATABASE_URL'] )
13. 12 Factor App – Backing Services
As attached resources
Backing Services
Data store
SMTP
Cache
Amazon S3
Twitter
Make no distinction between local and third party services
15. 12 Factor App – Build, Release, Run
Strictly separate build & run stage
BUILD = Codebase + dependencies + assets
RELEASE = Build + config
RUN = Run process against Release
Strict separation between stages
Cannot change code at runtime
Rollback = use the last release instead
Every release should always have a unique release ID
17. 12 Factor App – Processes
Execute the app as one or more stateless process
Does the running of the release
Is stateless
Share nothing with other process
Use single transaction only caches
No sticky sessions - Use session state data with memcached/redis
Asset pre-compilation instead of over runtime calculation
19. 12 Factor App – Port Binding
Export services via port binding
The contract with the execution environment is binding to a port to serve request .
App is completely self-contained
Booking
http://192.168.123.45:5555
Shop
http://23.123.34.54:5505
21. 12 Factor App – Concurrency
Scale out via the process model
Scale out via the process model (by running multiple process of different types)
Process are the first class citizens
Assign to work to a process type (web, db, worker etc)
Can then handle own multiplexing
Process don't demonize or write PID files
Instead using system process manager
23. 12 Factor App – Disposability
Maximize robustness with fast startup and graceful shutdown
Process are disposable (they can be started or stopped at a moment’s notice)
Start quickly
Shutdown gracefully
Be robust against sudden death
24. 12 Factor App
Dev Prod Parity
Keep development, staging and production as similar as possible
25. 12 Factor App – Dev Prod Parity
Keep development, staging and production as similar as possible
Gaps
The time gap: A developer may work on code that takes days, weeks, or even months to go into production.
The personnel gap: Developers write code, ops engineers deploy it.
The tools gap: Developers may be using a stack like Nginx, SQLite, and OS X, while the production deploy uses
Apache, MySQL, and Linux.
Make the time gap small: a developer may write code and have it deployed hours or even just minutes
later.
Make the personnel gap small: developers who wrote code are closely involved in deploying it and
watching its behavior in production.
Make the tools gap small: keep development and production as similar as possible.
27. 12 Factor App – Logs
Treat logs as event streams
Dont route or store logs in files
Stream to stout instead and be captured and handled by environment
28. 12 Factor App
Admin processes
Run admin/management tasks as one-off processes
29. 12 Factor App – Admin processes
Run admin/management tasks as one-off processes
Database migration
Console view
Running one time scripts
Run as seperate process
Run against the same release
Admin code ships with app code