Twelve-Factor App methodology
{{Short description|Software methodology}}
{{Software development process}}
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.{{cite book|title=Microservices Best Practices for Java|pages=2–3|publisher=IBM Redbooks|date=13 March 2017|isbn=9780738442273|url=https://books.google.com/books?id=KdSrDQAAQBAJ|first1=Michael|last1=Hofmann|first2=Erin|last2=Schnabel|first3=Katherine|last3=Stanley}}
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
| class="wikitable" style=text-align:left
|+ The Twelve Factors{{cite web|last=Wiggins|first=Adam|title=The Twelve-Factor App|url=https://12factor.net/12factor.epub|access-date=21 December 2017|archive-url=https://web.archive.org/web/20170613060854/https://12factor.net/12factor.epub|archive-date=13 June 2017}} ! # !! 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.{{cite web|url=https://www.nginx.com/blog/microservices-reference-architecture-nginx-twelve-factor-app/|title=MRA, Part 5: Adapting the Twelve‑Factor App for Microservices|website=NGINX|last=Horowitz|first=Ben|date=28 July 2016|access-date=22 December 2017|archive-url=https://web.archive.org/web/20171222082423/https://www.nginx.com/blog/microservices-reference-architecture-nginx-twelve-factor-app/|url-status=live|archive-date=22 December 2017}} The twelve factors are however cited as a baseline from which to adapt or extend.{{cite web|url=http://www.oreilly.com/webops-perf/free/beyond-the-twelve-factor-app.csp|title=Beyond the Twelve-Factor App - Exploring the DNA of Highly Scalable, Resilient Cloud Applications|access-date=22 December 2017|website=O'Reilly}}
References
{{Reflist}}
External links
- [https://12factor.net/ 12factor Website]
- [https://12factor.net/12factor.epub The Twelve-Factor App epub book by Adam Wiggins]
Category:Architectural pattern (computer science)