Overview
In the modern era, software is commonly delivered as a service, often referred to as software-as-a-service.
The twelve-factor app is a methodology for building software-as-a-service applications that:
Use declarative formats for setup automation, to minimize time and cost for new developers joining the project.
Have a clean contract with the underlying operating system, offering maximum portability between execution environments.
Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration.
Minimize divergence between development and production, enabling continuous deployment for maximum agility.
Can scale up without significant changes to tooling, architecture, or development practices.
The twelve-factor methodology can be applied to applications written in any programming language, and which use any combination of backing services (database, queue, memory cache, etc).
Background
The Heroku team created the 12 Factor App methodology to help teams build and deploy software-as-a-service applications.
Their motivation was to raise awareness of some systemic problems they saw in modern application development, to provide a shared vocabulary for discussing those problems, and to offer a set of broad conceptual solutions to those problems with accompanying terminology. The format is inspired by Martin Fowler’s books Patterns of Enterprise Application Architecture and Refactoring.
Applications deployed onto Kubernetes are often built using the 12 Factor App methodology following the same principles.
Who should read this document?
- Any developer building applications which run as a service.
- Ops engineers who deploy or manage such applications.
- Platform Engineers managing Kubernetes environments.
The Twelve Factors
| Number | Description | Link |
|---|---|---|
| 1 | One codebase tracked in revision control, many deploys | Codebase |
| 2 | Explicitly declare and isolate dependencies | Dependencies |
| 3 | Store config in the environment | Config |
| 4 | Treat backing services as attached resources | Backing services |
| 5 | Strictly separate build and run stages | Build,Release,Run |
| 6 | Execute the app as one or more stateless processes | Processes |
| 7 | Export services via port binding | Port binding |
| 8 | Scale out via the process model | Concurrency |
| 9 | Maximize robustness with fast startup and graceful shutdown | Disposability |
| 10 | Keep development, staging, and production as similar as possible | Parity |
| 11 | Treat logs as event streams | Logs |
| 12 | Run admin/management tasks as one-off processes | Admin |