Upgrade to Pro — share decks privately, control downloads, hide ads and more …

The 12 Factor App.

The 12 Factor App.

A methodology for building modern, scalable, maintainable software-as-a-service apps.

Kenneth Reitz

January 27, 2012
Tweet

More Decks by Kenneth Reitz

Other Decks in Programming

Transcript

  1. The Twelve-Factor App

    View full-size slide

  2. The twelve-factor app is a methodology for building
    software-as-a-service apps that:

    View full-size slide

  3. Use declarative formats for setup automation, to minimize
    time and cost for new developers joining the project.

    View full-size slide

  4. Have a clean contract with the underlying operating
    system, offering maximum portability between execution
    environments.

    View full-size slide

  5. Are suitable for deployment on modern cloud platforms,
    obviating the need for servers and systems administration.

    View full-size slide

  6. Minimize divergence between development and
    production, enabling continuous deployment for maximum
    agility.

    View full-size slide

  7. And can scale up without significant changes to tooling,
    architecture, or development practices.

    View full-size slide

  8. I. Codebase
    • One codebase tracked in revision control,
    many deploys.
    • If there are multiple codebases, it’s not an
    app – it’s a distributed system.

    View full-size slide

  9. II. Dependencies
    • Explicitly declare and isolate dependencies.
    • A twelve-factor app never relies on implicit
    existence of system-wide packages.
    • Do not rely on the implicit existence of any
    system tools.
    • pip + virtualenv + requirements.txt

    View full-size slide

  10. III. Config
    • Store config in the environment.
    • Resource handles to the database,
    Memcached, and other backing services.
    • Per-deploy values such as the canonical
    hostname for the deploy.
    • Django & Flask make this simple.

    View full-size slide

  11. IV. Backing Services
    • Treat backing services as attached
    resources.
    • Make no distinction between local and
    third party services.

    View full-size slide

  12. V. Build, release, run.
    • Strictly separate build and run stages.
    • It is impossible to make changes to the
    code at runtime.
    • This allows for rollbacks and other release
    management suites.

    View full-size slide

  13. VI. Processes
    • Execute the app as one or more stateless
    processes.
    • $ python app.py
    • A production deploy of a sophisticated app
    may use many process types, instantiated
    into zero or more running processes.

    View full-size slide

  14. VII. Port binding
    • Export services via port binding.
    • The web app exports HTTP as a service by
    binding to a port, and listening to requests
    coming in on that port.
    • Gunicorn, Gevent, Eventlet.

    View full-size slide

  15. VIII. Concurrency
    • Scale out via the process model.
    • Using this model, the developer can
    architect their app to handle diverse
    workloads by assigning each type of work
    to a process type.
    • Rely on the operating system's process
    manager.

    View full-size slide

  16. IX. Disposability
    • Maximize robustness with fast startup and
    graceful shutdown.
    • They can be started or stopped a moment’s
    notice.

    View full-size slide

  17. X. Dev/prod parity
    • Keep development, staging, and production
    as similar as possible.
    • Failing to do so increases: the time gap,
    personnel gap, and the tools gap.

    View full-size slide

  18. Traditional app Twelve-factor app
    Time between deploys Weeks Hours
    Code authors vs code
    deployers
    Different people Same people
    Dev vs production
    environments
    Divergent
    As similar as
    possible

    View full-size slide

  19. XI. Logs
    • Treat logs as event streams.
    • Apps never concern themselves with
    routing or storage of the output stream.

    View full-size slide

  20. XII. Admin processes
    • Run admin/management tasks as one-off
    processes in an identical environment.
    • Run against a release, using the same code
    and config as any process run against that
    release.
    • $ manage.py syncdb

    View full-size slide

  21. 12factor.net

    View full-size slide