The Twelve-Factor App
The Twelve-Factor App is a methodology for software as a service applications published by Heroku in 2011 which describes the best practices for software written against their platform. Many in the industry equate 12 Factor App with Cloud Native but the former is silent on many aspects intrinsic to modern cloud native architectures such as immutability, zero down-time deployments, self-healing and so on. [ More ]
I. Single Code Base: One single code base managed using a SCM (Source Code Management) tool with versioning capabilities such as Git.
II. Ship Dependencies: Applications should not rely on the availability of libraries or tools on the landing runtime environment; they should instead bundle all dependencies with them.
III. External Configuration: Configuration should be externalised away from the application; it should be injected from the runtime environment.
IV. External Backing Services: The application should not bundle its own data stores; it should, instead, rely on external attached resources referenced by an URL.
V. Build, Release, Run: An application’s life cycle is understood as a pipeline consisting of a build stage (turning code into binaries), release (combining code with env-specific configuration) and run (executing the binaries). All of these stages produce uniquely identifiable assets.
VI. Stateless Process: The application should be stateless and make no client assumptions by storing data neither in the local host or even in memory. All persistence use cases should be delegated to an external backing service.
VII. Port Binding Abstraction: Application are autonomous and can service requests directly (typically by embedding their own HTTP server) rather than requiring a landing application server environment.
VIII. Share-Nothing Concurrency: The de facto scaling model is that of the UNIX, share-nothing process; there should not be shared-state assumptions such as those related to VM-level threads.
IX. Disposability: Applications can be started or stopped at a moment’s notice to facilitate elastic scaling.
X. Dev/Prod Parity: Developers should strive to use, in their local environment, the same backing services as those found in production.
XI. Logs on Stdout: Applications are not concerned with the management of log files; they should simply write to stdout and let the environment process and aggregate them.
XII. Bundle Admin Tasks: All administration management code (e.g. database migration code) should be part of the same application’s code base rather than an orthogonal process.