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 💙
SigNoz
/
signoz
SigNoz is an open-source observability platform native to OpenTelemetry with logs, traces and metrics in a single application. An open-source alternative to DataDog, NewRelic, etc. 🔥 🖥. 👉 Open source Application Performance Monitoring (APM) & Observability tool
Monitor your applications and troubleshoot problems in your deployed applications, an open-source alternative to DataDog, New Relic, etc.
Documentation • ReadMe in Chinese • ReadMe in German • ReadMe in Portuguese • Slack Community • Twitter
SigNoz helps developers monitor applications and troubleshoot problems in their deployed applications. With SigNoz, you can:
👉 Visualise Metrics, Traces and Logs in a single pane of glass
👉 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.
👉 Run aggregates on trace data to get business relevant metrics
👉 Filter and query logs, build dashboards and alerts based on attributes in logs
👉 Record exceptions automatically in Python, Java, Ruby, and Javascript
👉 Easy…
Top comments (0)