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
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)
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.
The ultimate goal is to keep developments, staging and production as similar as possible.
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)
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.