— Dev, Architecture pattern, The Twelve-Factor App, English — 1 min read
The Twelve-Factor app's processes are designed to be disposable, allowing them to be started or stopped at any moment. This flexibility accelerates elastic scaling, rapid deployment of code or configuration changes, and ensures the resilience of production deployments.
Efforts should be made to minimize the startup time of processes. Swift startups provide greater agility for the release process and scaling up, contributing to robustness as the process manager can easily transfer processes to new physical machines when needed.
Processes shut down gracefully when they receive a SIGTERM signal from the
process manager. In the case of a web process, this entails ceasing to listen on
the service port (rejecting new requests), allowing ongoing requests to be completed,
and then exiting. For instance, in the case of a worker process, graceful shutdown
involves returning the current job to the work queue. In RabbitMQ, a worker
can send a NACK to accomplish this.
Processes should also be resilient against abrupt termination, which could result from hardware failures. Although less common than graceful shutdowns with SIGTERM, such incidents can occur. An advisable strategy involves utilizing a robust queueing backend like Beanstalkd, which returns jobs to the queue upon client disconnection or timeouts. In any scenario, a twelve-factor app is structured to handle unexpected, non graceful terminations. The crash-only design embodies this principle to its logical conclusion.
This Twelve-Factor App post series is a means for me to consolidate the knowledge I've gained while studying these rules. Please feel free to visit the site for more detailed explanations. That's all folks!