DEV Community

loading...
Cover image for The 12 factor app best practices for microservices

The 12 factor app best practices for microservices

Ankit Anand ✨
Your friendly content curator on DevOps, open-source projects, application performance monitoring & cloud native technologies 👨🏽‍💻
Updated on ・3 min read

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

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 - an open-source APM & observability tool 💙

GitHub logo SigNoz / signoz

SigNoz helps developers monitor their applications & troubleshoot problems, an open-source alternative to DataDog, NewRelic, etc. 🔥 🖥

SigNoz-logo

Monitor your applications and troubleshoot problems in your deployed applications, an open-source alternative to DataDog, New Relic, etc.

License Downloads GitHub issues tweet

SigNoz helps developers monitor applications and troubleshoot problems in their deployed applications. SigNoz uses distributed tracing to gain visibility into your software stack.

👉 You can see metrics like p99 latency, error rates for your services, external API calls and individual end points.

👉 You can find the root cause of the problem by going to the exact traces which are causing the problem and see detailed flamegraphs of individual request traces.

SigNoz Feature

👇 Features:

  • Application overview metrics like RPS, 50th/90th/99th Percentile latencies, and Error Rate
  • Slowest endpoints in your application
  • See exact request trace to figure out issues in downstream services, slow DB queries, call to 3rd party services like payment gateways, etc
  • Filter traces by service name, operation, latency, error, tags/annotations.
  • Aggregate metrics on filtered traces. Eg, you can get error…




Discussion (0)