The Twelve-Factor App Methodology

This article will discuss the Twelve-Factor App Methodology and the importance of applying these in software projects.

But let’s start from the beginning. What does methodology, which we use most of the time, actually mean in software?

A software/system development methodology in software engineering is
a systematic approach that is used to define the system model and structure, plan, control the system’s development process.

What is theTwelve-Factor App Methodology and Why is It Important?

• The 12 Factor App is a set of principles that can scale quickly, be maintained consistently, and supply discipline and standards in software projects. It aims to build software-as-a-service applications.
• When developing software, it is necessary to consider coding, system administration, database management, performance, etc. The 12 Factor App offers robust techniques to manage all these requirements.
• By following these 12 approaches, you can have long-term, robust, high-quality, and maintainable software. Also, these twelve-factors increase the reliability of the software. So it provides clarity on whether the software is production-ready or not.

1. Codebase

The codebase is any single repo or set of repos in a version control system that lets you manage and keep track of your source code history.

There is only one codebase per app, but there will be many deploys of the app.
Deploy is a running instance of the app that can be found in environments such as production, QA and development.

If there is more than one codebase, it is a distributed system, not an app. Therefore, each component should implement twelve factors by itself.

2. Dependencies

“A twelve-factor app never relies on implicit existence of system-wide packages.”

Dependencies must be explicitly specified and isolated. According to the twelve-factor, dependency declaration and isolation must always be used together. Therefore, using a dependency isolation tool is just as important as using a dependency declaration tool because this ensures that no implicit dependencies are leaked from the system.

Another utility of this factor is that it simplifies setup for developers new to the app.

3. Config

“The config should be strictly separated from the code. Config varies substantially across deploys; code does not.”

The twelve-factor app specifies that config must be stored in environment variables.

The most important goal here is to be able to easily change between deploys without changing any code and keep them to a language and OS-independent standard.

4. Backing Services

A backing service is any service the app consumes over the network as part of its ordinary operation so as data stores, messaging/queueing systems, SMTP services, and caching systems.

According to twelve-factor, a local server must be changed with a third-party service without changing the code. This should only be managed by changing the config file.

5. Build, Release, Run

“The twelve-factor app uses strict separation between the build, release and run stages.”

These life cycle steps should be implemented separately so that software deployment can be quick, continuous, and does not need any manual intervention.

6. Processes

“Twelve-factor processes are stateless and share-nothing.”

Any data that will be needed again should be stored in a stateful backup service, like a database. The twelve-factor app never assumes any cached data will use it in the future.

A stateless process makes scaling easier.

7. Port Binding

“Export services via port binding.”

Opening a service or an app to the network by port number is more reliable and easier to manage. For example, the web application exports HTTP as a service by connecting to a port and listening for requests from that port.

According to this factor, the application should run independently and not be connected to a web server. In this way, the application running from the port can easily be used as support services for other applications.

8. Concurrency

Instead of making the app larger, create multiple processes and divide the workload between processes.

It is not appropriate to move forward by making a single process larger.

When processes are distributed according to their purpose, it is easier to manage when needed. Applications continue to grow, do not just stay as they were developed for the first time. Therefore, distributing the newly created workloads according to the concurrency principle is very important for the app’s scalability.

9. Disposability

“Maximise robustness with fast startup and graceful shutdown.”

A fast startup means that all connections (e.g. database), access to network resources, and configuration are operational while starting the app.

Likewise, a graceful shutdown means ensuring all connections and network resources are properly terminated, and the shutdown events are logged.

Fast and robust management of these processes is critical because the application can be started or stopped at a moment’s notice.

10. Dev/Prod Parity

“Keep development, staging, and production as similar as possible.”

There shouldn’t be too many gaps between development and production. These gaps can be summarised as:

• The code that is written should go into production in a reasonable time. According to the twelve-factor, it is not correct that writing code would take too long to get into production.
• Not only ops engineers but also developers are closely involved in code distribution to watch the code’s behaviour in production.
• Tools used by developers and tools used in production should be kept as similar as possible.

This factor supports continuous deployment.

11. Logs

Logs provide visibility into the behaviour of a running app by holding specific events in the past.

The twelve-factor app doesn’t be concerned with the management of logs.

The app should only deal with the log to be written to stdout. It doesn’t deal with the writing of the logs file. Also, the other processes like the storage, capture, and archiving of these logs manage by the execution environment.

12. Admin Processes

“Run admin/management tasks as one-off processes.”

One-off admin processes (e.g. database migrations) should be run in the same environment as the regular long-running processes of the app. They run against a release, using the same codebase and config as any process run against that release.

Thank you for taking the time to read this article!

Reference: 12factor.net