09. VIII. Concurrencia

Escala mediante el modelo de procesos.

Procesos como ciudadanos de primera clase

Inspirándose en el modelo Unix de demonios, una aplicación twelve-factor trata a sus procesos como la unidad fundamental de escalado. Esto contrasta con modelos donde la concurrencia se resuelve internamente:

• PHP + Apache: procesos pesados creados bajo demanda por cada solicitud.
• Java + JVM: una única máquina virtual reserva recursos por adelantado y gestiona la concurrencia internamente con threads.

En ambos casos, escalar significa ajustar parámetros dentro de un runtime monolítico. El enfoque twelve-factor es distinto: divide el trabajo en tipos de procesos independientes, cada uno escalable por separado.

Tipos de procesos

Una misma aplicación puede declarar distintos tipos de procesos, cada uno con una responsabilidad concreta:

• web: atiende solicitudes HTTP entrantes.
• worker: procesa tareas en background (colas, jobs pesados).
• clock: dispara tareas programadas.

flowchart TD
    subgraph Web["Tipo: web x3"]
        W1["proceso"]
        W2["proceso"]
        W3["proceso"]
    end
    subgraph Worker["Tipo: worker x5"]
        K1["proceso"]
        K2["proceso"]
    end
    Queue[("Cola de tareas")]
    Web --> Queue
    Queue --> Worker

Al conjunto de tipos de proceso y sus cantidades se lo llama juego de procesos (process formation), por ejemplo: web=3, worker=5, clock=1.

Threads internos están bien, pero no alcanzan solos

Los procesos pueden seguir usando threads o loops de eventos internamente (Node.js, EventMachine, Twisted) para atender múltiples solicitudes concurrentes dentro de un mismo proceso. Pero como cada máquina virtual/proceso tiene un techo de capacidad, la app también debe poder dividirse en múltiples procesos distribuidos en máquinas físicas distintas.

Escalado horizontal gracias a share-nothing

El factor VI (procesos sin estado, share-nothing) es lo que hace segura y simple esta escalabilidad horizontal: como ningún proceso guarda estado local imprescindible, agregar o quitar instancias de un tipo de proceso no rompe nada.

Nunca demonios ni ficheros PID

El manifiesto es explícito: los procesos de una app twelve-factor nunca deberían convertirse en demonios ni escribir archivos PID por su cuenta. Esa responsabilidad se delega al gestor de procesos del sistema operativo (systemd), de la plataforma cloud, o de una herramienta como Foreman — quienes se encargan de logs, reinicios y apagados de forma centralizada.

Checklist del factor VIII

• La aplicación está dividida en tipos de procesos con responsabilidades claras (web, worker, clock, …).
• Cada tipo de proceso puede escalarse (más o menos instancias) de forma independiente.
• Ningún proceso se demoniza a sí mismo ni escribe archivos PID manualmente.
• Un gestor de procesos externo (systemd, la plataforma cloud, un orquestador) es responsable del ciclo de vida de los procesos.

Escalar procesos implica poder crearlos y destruirlos con frecuencia. El siguiente factor cubre justamente eso: la desechabilidad.