Twelve-Factor App methodology

On this page

Software methodology

The Twelve-Factor App methodology is a methodology for building software-as-a-service applications. These best practices are designed to enable applications to be built with portability and resilience when deployed to the web.

We don't have any images related to Twelve-Factor App methodology yet.

You can add one yourself here.

We don't have any YouTube videos related to Twelve-Factor App methodology yet.

You can add one yourself here.

We don't have any PDF documents related to Twelve-Factor App methodology yet.

You can add one yourself here.

We don't have any Books related to Twelve-Factor App methodology yet.

You can add one yourself here.

We don't have any archived web articles related to Twelve-Factor App methodology yet.

You can submit a link to a page to archive here.

History

The methodology was drafted by developers at Heroku, a platform-as-a-service company, and was first presented by Adam Wiggins circa 2011.²

The Twelve Factors

The Twelve Factors³ ⁴

#	Factor	Description
I	Codebase	There should be exactly one codebase for a deployed service with the codebase being used for many deployments.
II	Dependencies	All dependencies should be declared, with no implicit reliance on system tools or libraries.
III	Config	Configuration that varies between deployments should be stored in the environment.
IV	Backing services	All backing services are treated as attached resources and attached and detached by the execution environment.
V	Build, release, run	The delivery pipeline should strictly consist of build, release, run.
VI	Processes	Applications should be deployed as one or more stateless processes with persisted data stored on a backing service.
VII	Port binding	Self-contained services should make themselves available to other services by specified ports.
VIII	Concurrency	Concurrency is advocated by scaling individual processes.
IX	Disposability	Fast startup and shutdown are advocated for a more robust and resilient system.
X	Dev/Prod parity	All environments should be as similar as possible.
XI	Logs	Applications should produce logs as event streams and leave the execution environment to aggregate.
XII	Admin Processes	Any needed admin tasks should be kept in source control and packaged with the application.

Criticism and adaptation

An Nginx architect argued that the relevance of the Twelve-Factor app concept is somewhat specific to Heroku, while introducing their own (Nginx's) proposed architecture for microservices.⁵ The twelve factors are however cited as a baseline from which to adapt or extend.⁶

External links

References

Hofmann, Michael; Schnabel, Erin; Stanley, Katherine (13 March 2017). Microservices Best Practices for Java. IBM Redbooks. pp. 2–3. ISBN 9780738442273. 9780738442273 ↩
Hofmann, Michael; Schnabel, Erin; Stanley, Katherine (13 March 2017). Microservices Best Practices for Java. IBM Redbooks. pp. 2–3. ISBN 9780738442273. 9780738442273 ↩
Hofmann, Michael; Schnabel, Erin; Stanley, Katherine (13 March 2017). Microservices Best Practices for Java. IBM Redbooks. pp. 2–3. ISBN 9780738442273. 9780738442273 ↩
Wiggins, Adam. "The Twelve-Factor App". Archived from the original on 13 June 2017. Retrieved 21 December 2017. https://web.archive.org/web/20170613060854/https://12factor.net/12factor.epub ↩
Horowitz, Ben (28 July 2016). "MRA, Part 5: Adapting the Twelve‑Factor App for Microservices". NGINX. Archived from the original on 22 December 2017. Retrieved 22 December 2017. https://www.nginx.com/blog/microservices-reference-architecture-nginx-twelve-factor-app/ ↩
"Beyond the Twelve-Factor App - Exploring the DNA of Highly Scalable, Resilient Cloud Applications". O'Reilly. Retrieved 22 December 2017. http://www.oreilly.com/webops-perf/free/beyond-the-twelve-factor-app.csp ↩