12 factor app
•
6 likes•1,800 views
http://12factor.labianchin.me/ - Official presentation link http://12fator.labianchin.me/ - Portuguese version A quick overview of the 12 factor app. Presented in conferences and inside company.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to 12 factor app
Similar to 12 factor app (20)
Recently uploaded
Recently uploaded (20)
12 factor app
- 1. 12 Factor App Building and releasing at the web-scale 1 / 17
- 2. Motivation Heroku PaaS with Cedar stack as way of building portable apps Easy to deploy and scalable, for any language IaaS => Infra, PaaS => Apps Docker, CoreOS, Dokku, Flynn, Deis, ... 12 Factor: Best practices on how PaaS apps should architected PaaS-friendly apps need to not care where they are 2 / 17
- 3. Introduction Declarative formats for setup automation Maximum portability between execution environments Deployment on modern cloud platforms Minimize divergence between prod/dev Enables continuous deployment Scale up easily 3 / 17
- 4. I. Codebase One codebase tracked in revision control, many deploys Single app per codebase 4 / 17
- 5. II. Dependencies Explicitly declare and isolate dependencies Never rely on the implicit existence of any system tools Supports reproducible builds Examples of tools: gem/bundle, pip/virtualenv, autoconf, ... HIGH importance 5 / 17
- 6. III. Config Store configuration in the environment (NOT code) Config is anything that may vary between deploys: Resource handles Credentials Canonical hostname for the deploy Strict separation of config from code Does not include internal application config (like Spring) 6 / 17
- 7. IV. Backing services Treat backing services as attached resources No distinction between local and third party services Allows great flexibility Loose coupling to the attached deploy Resources can be attached and detached to deploys at will, no code changes 7 / 17
- 8. V. Build, release, run Strictly separate build, release and run stages Build : Converts code repo into an executable bundle Release : Build with deploy's current config, ready for immediate execution Run : Launches a set of app's processes against a selected release 8 / 17
- 9. VI. Processes Execute the app as one or more stateless processes Stateless and share-nothing Session data should be stored with a time-expiration, e.g. Memcached or Redis Stateless means: More robust Easier to manage Incurs fewer bugs Scales better 9 / 17
- 10. VII. Port binding Export services via port binding Exports HTTP as a service by binding to a port Routing layer to handle requests routing to a hostname Uses Webserver libraries such as Jetty for JVM or Thin for Ruby One app can become the backing service for another app 10 / 17
- 11. VIII. Concurrency Scale out via the process model Processes are a first class citizen Never daemonize or write PID files Relies on OS process manager (upstart, systemd, launchd, foreman, ...) to: Manage output streams Respond to crashed processes Handle restarts and shutdowns 11 / 17
- 12. IX. Disposability Maximize robustness with fast startup and graceful shutdown Can be started or stopped at a moment’s notice Maximize robustness with fast startup and graceful shutdown Gracefully shut down when receiving a SIGTERM signal Processes should be robust against sudden death 12 / 17
- 13. X. Dev/prod parity Keep development, staging, and production as similar as possible Designed for continuous deployment Keep the gap between development and production small: Time gap: long time to prod Personnel gap: developers code, ops deploy Tools gap: different stack Resists to use different backing services between dev and prod 13 / 17
- 14. XI. Logs Treat logs as event streams Event stream is written to STDOUT Use log routers (such as Logplex and Fluent) 14 / 17
- 15. XII. Admin processes Run admin/management tasks as one-off processes Run against a release: same code and config as any process run against that release Must ship with application code to avoid synchronization issues e.g. Database migration 15 / 17