The Twelve-Factor App: Concurrency
Lucas Fernandes
Posted on January 2, 2024
Scale out via the process model
Web applications have various process execution forms. PHP, for example, processes function as child processes of Apache, starting based on request volume, while Java processes operate within a massive JVM uberprocess, managing concurrency internally through threads. These running processes are minimally visible to app developers. In the context of the twelve-factor app, processes are crucial and they are a first-class citizen, drawing inspiration from the unix process model for service daemons. This model allows developers to allocate different workloads to specific process types, such as handling HTTP requests through web processes and long running tasks through worker processes.
Moreover, while individual processes can handle internal multiplexing via threads or asynchronous/event-driven models, vertical scaling of an individual VM has limitations. The process model excels in scaling out, as the share-nothing, horizontally partitionable nature of twelve-factor app processes facilitates simple and reliable addition of concurrency.
Furthermore, the text emphasizes that twelve-factor app processes should refrain from daemonizing or writing PID files. Instead, reliance on the operating system’s process manager (like systemd
or cloud platform-based distributed process managers) or tools such as Foreman
during development is encouraged. These tools effectively manage output streams, handle crashed processes and address user-initiated restarts and shutdowns.
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 (https://12factor.net/) for more detailed explanations. That's all folks!
Posted on January 2, 2024
Join Our Newsletter. No Spam, Only the good stuff.
Sign up to receive the latest update from our blog.