The 12 factor app best practices for microservices
Tags: todayilearned, devops, microservices, kubernetes
Published: 2021-06-17 13:28:00

Today, I want to talk about the powerful 12 factor app methodology, which is an essential framework for both developers and ops engineers!

The 12 factor app methodology was first published in 2011 by Heroku engineers, who witnessed hundreds of apps being developed and deployed and came out with a method for building web applications at scale.

This methodology, when followed, enables companies to:

🔸 develop software quickly 
🔸 maintain maximum software portability
🔸 deploy software on modern cloud platforms
🔸 sync development & production, and
🔸 scale up their software without significant changes

Now, let's take a look at the 12 factors in brief:

## 1. Codebase
> One codebase tracked in revision control, many deploys

There is only one codebase for a 12 factor app that is shared across development, production, staging, and QA. One codebase does not mean you can't have different deployments; the difference between deployments is taken care of by a version control system like Git.

## 2. Dependencies
> Explicitly declare and isolate dependencies

A 12 factor app always declares all dependencies, completely via a *dependency declaration* manifest. This reduces dependencies on the existence of system tools and also simplifies setup for new developers.


## 3. Config
> Store config in the environment

Apps should never store config as constants in the code. A 12 factor app stores config as environment variables factored out of the codebase. Environment variables make it easy to change configuration settings between different deployments.

## 4. Backing Services
> Treat backing services as attached resources

The backing services principle states that for a 12 factor app, all external components should be treated as attached resources. External components can be anything from databases to caching systems. It doesn't matter whether it's local or managed by a 3rd party service. The backing services can be attached to or detached from deploys at will, thereby increasing the flexibility of the app.

## 5. Build, Release, Run
> Strictly separate build and run stages

The deployment process must be broken down into three replicable stages:
- Build stage - transform the code into an executable bundle/ build package.
- Release stage - takes the build package and combines it with config settings for the current deployment.
- Run stage - runs the app in the execution environment.

## 6. Processes
> Execute the app as one or more stateless processes

Apps developed using the 12 factor methodology must have all their processes stateless and must share nothing. This type of stateless architecture makes scaling easier. Any data that needs to persist is a good candidate for a datastore.

## 7. Port Binding
> Export services via port binding

Port binding principle is based on the idea that the best way to expose any process to the network is by using uniform port numbers. The 12 factor web app exports HTTP as a service by binding to a port and listening to requests coming in on that port.

## 8. Concurrency
> Scale out via the process model

In the 12 factor app, processes are first-class citizen. Through the principle of concurrency, similar processes are grouped together which be scaled up and down.

## 9. Disposability
> Maximize robustness with fast startup and graceful shutdown

The principle of disposability states that processes can be started or stopped at a moment's notice. Processes should be up and ready to receive requests in seconds from the launch time, and they should shut down gracefully when they receive a SIGTERM signal.

## 10. Dev/Prod Parity
> Keep development, staging, and production as similar as possible

The 12 factor app is designed for continuous deployment by keeping the gap between development and production small. 

## 11. Logs
> Treat logs as event streams

Logs provide visibility into the behavior of a running application. A 12 factor app should not attempt to write to or manage logfiles. The logs should be routed to one or more final destinations for viewing and long-term archival.

## 12. Admin Processes
> Run admin/management tasks as one-off processes

Developers often need to perform some one-off administrative or maintenance tasks for the app, such as running database migrations, running a console etc. These admin processes should be treated as a first-class citizen and should be given an identical environment as the regular processes of the app.

___

I hope you enjoyed this brief synopsis of the 12 factor app methodology. This framework enables developers to develop web applications at scale.

Link to the full article👇
[The 12 Factor App](https://12factor.net/)

I will be coming up with more such notes on topics around DevOps, distributed systems, and performance monitoring. So, stay tuned! 🙂

Have a great day, folks!
👋 Ankit, your friendly DevOps content curator 👨🏽‍💻
___
Currently building [SigNoz](https://github.com/SigNoz/signoz) - an open-source APM & observability tool 💙

{% github signoz/signoz %}