GitHub
VIII. Concorrenza
Scalare attraverso il process model
Ogni software, una volta avviato, è rappresentato da uno o più processi. Le web application in particolare hanno assunto nel tempo una gran varietà di forme e di tipologie di esecuzione, in tal senso. Per esempio, i processi PHP vengono eseguiti come sotto-processi figli di Apache, avviati su richiesta quando necessari in base al volume di richieste. Java invece gestisce le cose nella maniera opposta, tramite un superprocesso unico che usa una grande quantità di risorse sul server (CPU e memoria) dall’avvio, con una concorrenza gestita “internamente” tramite i threads. In entrambi i casi, comunque, i processi non sono esplicitamente visibili allo sviluppatore.
In un’applicazione twelve-factor, i processi sono “first class citizen”. La visione del concetto di processo prende spunto dal concetto, in unix, dedicato all’esecuzione di demoni di servizi. Attraverso l’uso di questo modello, lo sviluppatore può realizzare la propria applicazione in modo tale da farle gestire senza problemi diversi livelli di carico di lavoro, assegnando ogni tipo di lavoro a un tipo di processo ben definito. Per esempio, le richieste HTTP possono essere gestite da un web process, mentre dei compiti più lunghi (in background) possono essere gestiti da un altro processo separato.
Questo non esclude che un certo processo, individualmente, possa gestire in modo autonomo e interno il multiplexing, tramite threading, all’interno della VM in esecuzione, o magari un modello asincrono o basato su eventi come quello di EventMachine, Twisted, o Node.js. Tuttavia, tutto questo può non bastare: l’applicazione deve essere anche adatta all’esecuzione su più macchine fisiche.
Il modello di processo così come presentato rende il massimo quando arriva il momento di scalare. La natura orizzontalmente partizionabile (e non soggetta a condivisioni) di un “processo twelve-factor” permette di gestire la concorrenza in modo semplice e affidabile. L’array dei tipi di processo e il numero di processi presenti per ogni tipo è conosciuto come process formation (formazione di processi).
I processi di un’app twelve-factor non dovrebbero essere soggetti a daemonizing, o scrivere file PID. Al contrario, facendo affidamento sul process manager del sistema operativo (come systemd, un process manager distribuito su piattaforma cloud, o tool come Foreman durante lo sviluppo) per gestire gli stream in output, rispondere adeguatamente a crash di processi e gestire riavvii e shutdown.