The Twelve Factor App Methodology
Tags: kubernetes, devops, cloud, saas
Published: 2022-01-03 06:38:59

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/et2y2xkgwqlqjmmfejhh.png)
 

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

## **Introduction**
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.

## **What is Saas**
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.

## **Benefits of the 12-factor app methodology**

- **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


## **The Twelve Factors**
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1hsmgpgrpe1wz78f5ok7.png)
 

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

## **Conclusion**

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.

Lets connect...[twitter](https://twitter.com/Emma_Donery), [linkendin](https://www.linkedin.com/in/emma-donery-0831a7188/)