Introduction
The twelve-factor application is a methodology for Softwares or web applications deployed in the cloud. These best practices are designed to enable applications to be built with portability and resilience when deployed to the web.
The purpose is the following : once you develop and set your application, it has to smoothly operate from the Cloud without having to deal with other aspects such as Operating systems, configurations, backing services; etc.
The 12 factor app methodology covers each of these aspects at the right timing so that the applications run as they must.
The Twelve Factors
1 – Codebase
There should be exactly one codebase for a deployed service with the codebase being used for many deployments.
For example you can use GIT to store your code as a central version control system.
2 – Dependencies
All dependencies should be declared, with no implicit reliance on system tools or libraries.
For example, when working with PHP, you can rely on Composer to install dependencies for us. All we have to do is declare them in the composer.json manifest.
3 – Configuration
Configuration that varies between deployments should be stored in the environment.
For example, you do not want sensitive information like database credentials or API keys to be committed into the repository to prevent security leaks.
4 – Backing Services
All backing services are treated as attached resources and attached and detached by the execution environment.
For example, your development environment talks to a MySQL server on your local machine. On production, your database runs on another server. The only difference will be the URL to connect to in the configuration.
5 – Build, release, run
The delivery pipeline should strictly consist of build, release, run.
For example, it’s now impossible to make changes to the runtime. Instead, you make changes to the code in the build stage where you have total control. This reduces risk and ensures your team that everything is running well.
6 – Processes
Applications should be deployed as one or more stateless processes with persisted data stored on a backing service.
For example, if a part of your application stack fails, the app itself does not become a failure.
7 – Port Binding
Self-contained services should make themselves available to other services by specified ports.
For example, Spring boot by default comes with embedded tomcat, jetty, or undertow.
8 – Concurrency
Concurrency is advocated by scaling individual processes.
For example, each process should be able to scale, restart, or clone itself when needed
9 – Disposability
Fast startup and shutdown are advocated for a more robust and resilient system.
For example, with a retail website, in the case of failure of a process of order-service, the user should still be able to access the website and eventually within no time should be able to order immediately.
10 – Dev/prod parity
All environments should be as similar as possible.
This reduces the number of bugs and downtime and allows your organisation to have a much more rapid development cycle.
11 – Logs
Applications should produce logs as event streams and leave the execution environment to aggregate.
You can then perform analysis of logs using tools like ELK stack.
12 – Admin Processes
Any needed admin tasks should be kept in source control and packaged with the application.
For example, administrative or maintenance tasks such as background one-off jobs or database migrations should be run as isolated processes.
Sources
wikipedia.org
aws.amazon.com
