12 Factor Apps

12 factor app is a framework for developing and operating cloud-native applications (modern).

1. Codebase

   • One codebase tracked in revision control, many deploys

2. Dependencies

   • all dependancies should be explicitly declared and dependancies should be isolated from the system (eg., pip to declare, virtualenv to isolate)
   • do not rely on the implicit existence of any system tools (e.g., shelling out to ImageMagick or curl)

   Simplifies setup for developers new to the app, consistent deployments.

3. Config

   • The twelve-factor app stores config in environment variables

   Unlike config files, there is little chance of them being checked into the code repo accidentally; and unlike custom config files, or other config mechanisms such as Java System Properties, they are a language- and OS-agnostic standard.

4. Backing servies

   Definition

   backing service: any service the app consumes over the network as part of it’s normal operation (db layer: mysql, caching layer: redis, stmp layer: amazon ses)

   Each distinct backing service is a resource.
   Example: MySQL database is a resource; two MySQL databases (used for sharding at the application layer) This qualifies as two distinct resources.

   Resources can be attached to and detached from deploys at will.
   Example: if the app’s database is misbehaving due to a hardware issue, the app’s administrator might spin up a new database server restored from a recent backup. The current production database could be detached, and the new database attached – all without any code changes.

5. Build - Release - Run stages

6. Processes

   Twelve-factor processes are stateless and share-nothing. Any data that needs to persist must be stored in a stateful backing service, typically a database.

   The memory space or filesystem of the process can be used as a brief, single-transaction cache. For example, downloading a large file, operating on it, and storing the results of the operation in the database. The twelve-factor app never assumes that anything cached in memory or on disk will be available on a future request or job – with many processes of each type running, chances are high that a future request will be served by a different process

7. Port binding

   Your app should include its own webserver, not depend on one being installed for you. Example: using flask for you python server vs php relying on apache to load your php as a module.

8. Concurrency

   Dont: Don’t manage process lifecycle internally: don’t spawn/restart/monitor child processes from within your app

   Do: Design around process types: separate web processes, worker processes, scheduled job processes, etc. Let the OS/platform manage processes: rely on systemd, Docker, Kubernetes, Foreman, etc. to start/stop/restart

   Your app runs as a simple process. The platform (Kubernetes, systemd, Docker Compose, whatever) decides how many copies to run and keeps them alive.

9. Disposability

   • Processes are disposable, meaning they can be started or stopped at a moment’s notice.
   • Processes should strive to minimize startup time.
   • Processes shut down gracefully when they receive a SIGTERM signal from the process manager. For a web process, graceful shutdown is achieved by ceasing to listen on the service port (thereby refusing any new requests), allowing any current requests to finish, and then exiting.

10. Keep development, staging, and production as similar as possible

    • The twelve-factor developer resists the urge to use different backing services between development and production.

11. Logging

    Running process writes its event stream, unbuffered, to stdout.

    In staging or production deploys, each process’ stream will be captured by the execution environment, collated together with all other streams from the app, and routed to one or more final destinations for viewing and long-term archival.
    These archival destinations are not visible to or configurable by the app, and instead are completely managed by the execution environment

12. Admin Processes

    I don’t find this rule relevant but my take away - run adhoc admin tasks INSIDE the environment using tools and dependences in the envrionment.

12factor apps