November 30, 2022

The 12 Factor App Part 3: (Disposability, Dev/prod parity, Logs, Admin processes)

AuthorMattia de Filippo

Automated configuration, optimal comptability with the operating system, on-demand cloud usage and flexible scalability are important criteria in web app development.

The Twelve-Factor App Method takes these factors into account to implement development objectively and efficiently. But what exactly is "The Twelve-Factor App" method? We have explained this in the Libelle IT Glossary.

In our blog series on the Twelve-Factor App Method: "The Twelve-Factor App Part 1: Codebase, Dependencies, Config Backing Services" and "The Twelve-Factor App Part 2: Build, Release, Run, Processes, Connection Binding, Concurrency", we took a closer look at the first eight factors.

In part three, we now highlight the next four factors. In summary, their principles are as follows:

IX. Disposability: Robust with quick start and easy stop
X. Dev/prod parity: keep development, staging and production as similar as possible
XI. Logs: Threat logs as a stream of events
XII. Admin Processes: Treat admin/management tasks as one-time processes

Factor 9: Disposability

Cloud-native application processes are disposable, meaning they can be started and stopped at any given time. By doing so, processes seek to reduce startup time, which leads to greater agility in releasing and scaling processes. This is also the case with the processes of a twelve-factor app. Very long startup times can potentially prevent the application from launching at all in the cloud.

On the other hand, it can be difficult to restart an application after a failure if it is not shut down properly and in a timely manner. Long-running operations need to be run independently or outsourced as a backing service to take advantage of the cloud-native architecture. The goal is to ensure a, Robust fast startup and smooth stop. (Source)

Factor 10: Dev/prod parity

This factor is about ensuring that the development, staging and production segments of the application, or rather all environments, are as similar as possible. By keeping the gap between development and production as small as possible, the 12-factor application is meant for continuous application delivery. There are three key aspects to consider here: Time Gap, Staffing Gap, and Tooling Gap.

    1. release intervals of, lets say, once a month are too long for some applications. Companies should try to shorten the time between check-in and production (minutes, hours) to improve the situation, as developers may forget what they did before and what went into a new release. This could also help developers work more efficiently, knowing that their code will be deployed almost immediately.
    1. deployers and developers should be the same people, which points to the need to synchronize the production deployment process with the development process. However, if a good build pipeline is in place, an application should be automatically deployed to all relevant environments.
    1. there should be no compromise in the use of certain backing services, i.e., the same resource types should be used in all environments. The organization cannot predict how code changes will behave in production if the development, test, and production environments are different. (Source)

The ultimate goal is to keep developments, staging and production as similar as possible.

Factor 11: Logs

In Order to  make the behavior of a running app visible, logs are being used. Usually, in server-based environments, they are written to a file on disk, but this is just an output format (log file).

Logs are the stream of aggregated events sorted by time and summarized from the output streams of all running processes and supporting services. Typically, logs are stored in text format, with each line reflecting a single event. Logs are a time-ordered sequence of events generated by an application. They should be treated like event streams. The event stream can be passed to a system for log indexing and analysis, stored in a file, or displayed in real time via the output of a terminal.

Cloud-native applications write all of their logs to stdout and stderr because they typically know very little about the file system  which they run on. An application's entire codebase becomes simpler when it is separated from knowledge about log storage. If changes need to be made to the logs, the application itself does not need to be adjusted.

A 12-factor application should never attempted in order to write to or to maintain log files, and it should not care about forwarding or storing its output stream. That means they never care about routing or storing their output stream. (Source)

Factor 12: Admin Processes

The last factor indicates that all administrative as well as  management operations should run as one-off processes within the same environment as the application's typical long-running processes. To avoid synchronization issues, the management code must be sent along with the application code.

To run one-off management processes on  a local deployment, developers use a direct shell command. However, in a production deployment, developers could use a remote command execution method, such as Secure Shell (ssh.).

In addition, cloud-native applications should integrate more efficient solutions for executing one-off processes. AWS Lambda functions, for example, are envoked on demand and do not require enterprises to keep provisioned servers running. (Source)

Do you work in IT or are you interested in IT-related topics? Then feel free to visit our blog for more topics and follow us on LinkedIn.

Recommended articles
December 22, 2022 Libelle IT Glossary Part 22: What is DevOps?
November 23, 2022 The 12-Factor App Part 2: Build, release, run, Processes, Port binding, Concurrency

All blog articles