Hey there 👋!For any developer building or going to build applications that run as a service,and to Ops engineers who are deploy and manage such applications this article is going to cover the 12-factor app in details. Happy Learning
The twelve-factor app methodology is a framework for building software-as-a-service apps that is based on twelve strict rule that act as building blocks for developing and deploying SaaS applications.
Software as a service (SaaS) is a method of delivering software as a service through the Internet. Instead of installing and maintaining software, you simply use the Internet to access it, eliminating the need for complicated software and device maintenance.
- Elasticity: Applications based on the 12 factors can grow and shrink as per the need
- Modularity: Allows for flexibility
- Information Security: it ensures security and also enforces segregation of duties by instructing that your credentials or any other confidential information should not be in code repo but in the application’s environment
I.Factor 1: Codebase
One codebase tracked in revision control, many deploys - The principle maintains that your code base should have a logical version control system that’s easy to understand. every application should have just a single codebase. However, multiple deployments are possible.
II. Factor 2: Dependencies
Explicitly declare and isolate dependencies - This principle implies that your app might depend on external packages or libraries. The application should be isolated sufficiently to avoid interactions with conflicting libraries that are installed on the host machine. Hence, you should never rely on the implicit existence of system-wide packages
III. Factor 3: Config
Store config in the environment - Your configurations should have a separate file and shouldn’t be hosted within the code repository. Storing configurations in environment variables (env vars or env) makes it is easy to change between the deploys without having to change the code
IV. Factor 4: Backing services
Treat backing services as attached resources - any services that don’t support the core app must be accessed as a service
V. Factor 5: Build, release, run
Strictly separate build and run stages - there should be a strict separation between these stages to avoid code break or any other risk.
VI. Factor 6: Processes
Execute the app as one or more stateless processes - The rule suggests storing of any data that is required to persist in a stateful backing service, such as databases. The idea is that the process is stateless and shares absolutely nothing.
VII. Factor 7: Port binding
Export services via port binding - 12-factor apps must always be independent from additional applications. Every function should be its own process—in full isolation.
VIII. Factor 8: Concurrency
Scale out via the process model - A 12-factor app is designed for scaling. Build your applications so that scaling in the cloud is seamless.Basically, it supports horizontal scaling of an app instead of vertical scaling.
IX. Factor 9: Disposability
Maximize robustness with fast startup and graceful shutdown - The concept of disposable processes means that an application can die at any time, but it won’t affect the user—the app can be replaced by other apps, or it can start right up again. It focuses on maximizing an application’s robustness with fast startup and graceful shutdown.
X. Factor 10: Dev/prod parity
Keep development, staging, and production as similar as possible - This principle suggests that the development, staging, and production of an app should be as similar as possible to ensure that anyone can understand and release it.
XI. Factor 12: Logs
Treat logs as event streams -this principle maintains that you should stream logs to a chosen location—not simply dump them into a log file.
XII. Factor 13: Admin processes
Run admin/management tasks as one-off processes - This principle proposes separating administrative tasks from the rest of your application
In today's world, the 12 factors are extremely essential in building microservices-based and cloud-native applications. These factors help design and maintain a robust and modern app architecture for cloud applications ensuring the timely release of new features and fixes.