12 Factor App

A methodology for developing Cloud-native Apps

What

The 12-factor application principles are the set of best practices that one can use to develop a modern-day application. Heroku originally drafted this for applications deployed as services on their cloud platform, back in 2011. Over time, this has proved to be generic enough for any software-as-a-service (SaaS) development.

Below are the 12 Principles

1. Codebase

Goal: One codebase tracked in revision control, many deploys.

Should deploy the application in various environments through a single codebase including local development also.

Tools:- GIT, Teamcity, Subversion

2. Dependencies

Goal:- Explicitly declare and isolate dependencies.

Its legacy monolithic application dependencies are usually managed by the Application Servers like Jboss or Weblogic. This can create a version issue while multiple applications running. So here dependencies should be application specific and isolated from the code.

Tools:- Java: Maven, Gradle.

Python: pip

3. Config

Goal:- Store config in the environment.

Config is the values needed by the application but specific to the environment. e.g. DB Config, Redis Config. The best way to manage the configurations is to externalize from the application and inject it at the runtime. Configuration can be managed by grouping required values as per environment like Dev, Stg, or Prod.

4. Backing services

Goal:- Treat backing services as attached resources.

Any service that consumes over the network can be termed a Backing service. such as Database services like mysql or postgres, messaging services like RabbitMQ, email services, or caching services. These services are attached resources accessed via URL. We can replace the service with another service at the same time without affecting the application.

5. Build, Release, Run

Goal:- Strictly separate build and run stages.

This is also known as CI/CD (Continuous Integration/ Continuous Deployment). In this, we have to isolate the build stage from the run. Here we have to tag each build with a unique non-mutable id.

Build: Transform the code repo into executable bundles plus fetches the vendor dependencies and complies binaries and assets known as build.

Release: Combines the build with the current deployment config and generates the release artifacts.

Run:- Runs the application in the execution environment.

6. Processes

Goal:- Execute the app as one or more stateless processes.

Each application is strictly run under one isolated process. A process is stateless and shares nothing. At any time application wants to persist data then it can use any backing service like a database or cache.

7. Port binding

Goal:- Export services via port binding.

The app should be completely self-contained and does not reply to any runtime injection of a webserver into the execution environment. the port-binding approach means that one app can become the backing service for another app, by providing the URL to the backing app as a resource handle in the config for the consuming app.

8. Concurrency

Goal:- Scale out via the process model.

This helps when the load on the application is increases, then we can spawn a new instance of the application. This is also called ag Horizontal Scaling. Docker container and Kubernetes can be used to scale out or scale in seamlessly.

9. Disposability

Goal:- Maximize robustness with fast startup and graceful shutdown.

The main goal is to start or stop the application at a given moment. In a cloud-native environment where we implemented the CI/CD then starting and stopping the app should be as quickly as possible. This will help us avoid downtime as we have to spawn the new instances in case of any load on the system.

10. Dev/prod parity

Goal:- Keep development, staging, and production as similar as possible.

It is advisable to keep the minimum gap between the development and production environment. There are 3 types of gaps.

1. Time Gap:- The gap between code written in the local environment against the code in production.
2. personnel Gap:- Two different people managing the same code.
3. Tools Gap:- Tools use for development are not in sync with production. Ex. In-memory DB in local against full RDBMS in prod

11. Logs

Goal:- Treat logs as event streams.

Logs are one of the important artifacts in cloud-native development. Logs should be aggerated to another system. The format of logs must be the same for all applications. Generally, ELK , and Splunk are used to manage the logs.

12. Admin Process

Goal:- Run admin/management tasks as one-off processes.

Run the admin process as a backing service. These processes should be isolated from the application. These processes can be killed after the job is done. Admin processes typically include migration of DB, Running any script against the application.