"12-Factor App" Summary

28 February 2015

I recently had a chance to go through the principles of the 12-Factor App as listed on 12factor.net. It's written by some of the fine folk at Heroku. The principles describe the best practices they see for how to get a modern web app deployed properly. It's a short read. This summary is even shorter.

1. Codebase
  • Always in src ctrl
  • One codebase per app (many repos = distributed system)
  • A deploy = instance of app running
2. Dependencies
  • All app and system dependencies explicitly declared
  • Do not dep on implicit existence of system tools (eg, ImageMagick)
  • Required sys tools vendored into app
3. Config
  • Strict separation between code and config
  • Config stored in env vars
4. Backing Services
  • Should be loosely coupled, swappable
  • Changes in services (eg, db) should not require code change
5. Build, release, run
  • Strict separation: build (binary), release (binary + env config), run (exec runtime)
  • Ordered -- can't make change upstream
  • Every release has unique id
6. Processes
  • Independent, stateless, share nothing
  • Sharing happens in backing service (eg, db)
  • No sticky sessions w/ process affinity
7. Port Binding
  • Can talk a protocol (eg, HTTP) by binding comm to a port
  • Allows an app to become a backing service for another app via a url
  • What does the alternative look like here? Seems like a given.
8. Concurrency
  • Process is first-class citizen patterned after unix service daemons
  • Process can multiplex internally (eg, threads or something like node.js)
  • Scaling becomes a simple addition of the same process
9. Disposability
  • Startups are fast
  • Requests are short
  • Shutdowns are graceful; requests can finish; jobs returned to queue
10. Dev/Prod Parity
  • Time from dev to prod deploy should be short (eg, hrs)
  • Devs who wrote the code should be around to op the code
  • Toolchains and tech stacks should be as similar as possible
  • Backing servies should be the same, even if adapters supposedly abstract implementations
11. Logs
  • Logs are treated as streams, simply written by an app to stdout
  • Let log storage, collating, and analysis be done in the env or or w/ other tools
  • Logs should provide visibility to how an app works over time
12. Admin Processes
  • Run as one-off processes in REPL
  • Env shares same code and config as long-running processes

If you have the extra little time required, I encourage you to check out 12factor.net and draw some of your own conclusions.

What other insights do you have on these principles?