12 Factor Apps

12 Factor Apps

• Methodology for building SaaS apps

Good code fails when you don’t have good process and a platform to help you. Good teams fail when you don’t have a good culture that embraces DevOps, microservices and not giant monoliths.

Goals

1. Minimize time and cost for new developers to join a project
2. Platform-agnostic code for maximum portability (i.e. cloud)
3. Minimize divergence between dev and prod code, enabling continuous deployment for maximum agility
4. Minimize scale up cost

These best practices are based on a few specific parameters for deployment of cloud-native applications:

1. It uses declarative formats for setup automation.
2. It works with a clean contract with the operating system for greater portability between environments
3. It limits the differences between development and production, for continuous deployment
4. And it allows for scaling up and down without major changes

The 12-factor methodology is programming language agnostic and works with any combo of backing services.

12 Factors

1. Codebase: Single repository per app (e.g. GitHub), deployed on various machines (e.g. staging, prod).
2. Dependencies: All dependencies are explicitly declared in a packaging system (e.g. Bundler, Chef) and isolated from the wider system when the app is run.
3. Config: Variables (i.e. values that vary between deploys, credentials) stored as environment variables (no code change, can’t be checked in to repo, OS agnostic, cleaner, scalable).
4. Backing Services: All external dependencies (e.g. database, SMTP) are treated as attached resources, able to be swapped out without any code changes
5. Build, Release, Run: Strictly separated, versioned, immutable, one-way process from code repository to build (most moving parts, complied and ready for execution), to release (build combined with a config), to run (fewest moving parts, launch in environment).
6. Processes: Executed code is stateless and shares nothing — all data is stored in a stateful backing service (e.g. database, S3) although temporary storage can be used (e.g. memory, disk), but never depended upon.
7. Port Binding: App is completely self-contained and provides its own webserver as a dependency — the only responsibility of the environment is binding to a port to serve requests.
8. Concurrency: More smaller first-class citizen processes assigned to different process types working independently (collectively referred to as the process formation) to maximise scalability
9. Disposability: Processes should start quick, shut down gracefully, be robust against sudden termination (e.g. hardware failure), and can be started or stopped at a moment’s notice.
10. Dev/Prod Parity: Deploy hourly (time gap), coders also deploy (personnel gap), dev and prod environments are as similar as possible (tool gap) — including backing services (i.e. no developer shortcuts such as lightweight database via adapter)
11. Logs: All running processed write to stdout captured and collated by the environment (e.g. Fluent, Papertrail) for tailing, indexing, graphical representation or analysis.
12. Admin: Scripts should be checked into the codebase and executed remotely on the intended environment.