What is the Twelve-Factor App?
Web application development is not an easy thing. If we don’t structure the system well enough Small changes will result in our sins to dig the old code and revise it. Some friends whose fate is already dead Test the app on our machine, it’s good enough. Deployed up Production.
The Twelve-Factor App is the 12 Principle that will provide a framework for creating a Software as a Service (Web Application) that Ruby on Rails users has known since their ages. Even if your friends are using Heroku, the more you have to know. Otherwise, it would be considered the betrayal of the platform!
What is the Twelve-Factor Application?
The Twelve-Factor App is ideal in principle to any application development. Especially applications that are available via the Internet (Software as a Service).
This article is mainly focusing on understanding the twelve facts using real-world examples and common ways of using them
1.Codebase
“One codebase tracked in revision control, many deploys”
That is, the system codebase must be version-managed in the Version Control System (VCS) where 1 codebase may refer to 1 system or service/process. At the heart of this is managing the version of the source code and being able to deploy it anytime in any environment.
2.Dependencies
“Explicitly declare and isolate dependencies”
The goal of this is to separate dependencies from the system to reduce dependency hell problems, making deployments more frequent and easier.
3.Config
“Store config in the environment”
First of all, let’s see that What configuration does it have?
- Database and service usage information
- The credentials for communicating with the external system.
- Requirements for deploying in each environment.
- Anything that needs to be changed in each environment such as dev, test, staging, production, etc.
More importantly, our work system must not be kept. various configurations in :
- Code
- Properties file
- Build process
- Application/Webserver
Therefore, it is recommended to store it in the Environment variable of the machine to be deployed, or in the cloud can be stored in the Cloud configuration (Centralize configuration).
4.Backing services
“Treat backing services as Attached resources”
Services must be easily accessible, for example by name, with URL, which is important to be able to easily convert, of course, they must also work with Factor 3: Config.
5.Design, Build, Release, Run
“Strictly separate stages”
Usually separated into stages as follows :
- Design / Develop This will be done by the developer. What tools and dependencies
- Build This section is responsible for the Continuous Integration Server to build / compile/package. The result is an EAR / WAR / JAR file which can be deployed further.
- The release is a process of releasing such as creating an image to be used in content creation.
- Run is a process of running or creating a container from the desired image which is very fast.
6.Processes
“Execute the app as one or more stateless processes”
You should not be introducing state into your services, applications should execute as a single, stateless process. The Twelve-factor processes are stateless and share-nothing. This factor lies at the core of microservices architecture.
7.Port binding Principle
“Export services via port bindings”
The twelve-factor app is completely self-contained. hence it doesn’t have to rely on other web-server containers. As an example, using Express.js in node js — It is a server in the code itself and not depends on an external server.
8.Concurrency
“Scale out via the process model”
By separating your app into smaller pieces you are able to scale the services. This reduces the workload as an individual VM can only grow so large (vertical scale), so it is important for the app to span across multiple processes on multiple physical machines.
9.Disposability
“Maximize robustness with fast startup and graceful shutdown”
Processes should be less time-consuming. Make sure you can run and stop fast. And that you can handle failure. Without this, automatic scaling and ease of deployment, development- are being diminished. You can achieve this with containers.
10.Dev/Prod parity
“Keep development, staging and production as similar as possible”
This eliminates many problems. Importantly, the Twelve-Factor App is designed for Continuous Deployment, so if different environments are not the same, it could lead to frequent deployments or even unpredictable problems.
11.Logs
“Treat logs as Event streams”
We must keep the log of each system according to the system that the log needs to be changed. configuration easily according to Factor 3
12.Admin processes
“Run admin/management processes as one-off processes”
There are processes for managing releases, there are a set of commands or commands that can be used in any environment such as :
- Database migration
- REPL shell (Read Eval Print Loop) for running code in the environment.
- Run ad-hoc commands such as fix bugs and fix information.
Conclusion
I still feel regretful as in the beginning. Why don’t you get to know each other earlier so that you can use the cloud much more efficiently, and if anyone wants to start trying it? But still do not want to do all of the 12 items, I suggest you try to do it from 1–6 first look. Whether it’s on the cloud or not