UNIVERSIDAD NACIONAL DEL ALTIPLANO – PUNO

Facultad de Ingeniería Mecánica Eléctrica, Electrónica y Sistemas Escuela Profesional de

Ingeniería de Sistemas

THE TWELVE-FACTOR APP

The twelve-factor app es una metodología para construir aplicaciones software as a service (SaaS)
que:

 Usan formatos declarativos para la automatización de la configuración.

 Tienen un contrato claro con el sistema operativo sobre el que trabajan.
 Son apropiadas para desplegarse en modernas plataformas en la nube.
 Minimizan las diferencias entre los entornos de desarrollo y producción.
 Pueden escalar sin cambios significativos para las herramientas.

CONTEXTO

La motivación es mejorar la concienciación sobre algunos problemas sistémicos que han

observado en el desarrollo de las aplicaciones modernas, aportar un vocabulario común que
sirva para discutir sobre estos problemas y ofrecer un conjunto de soluciones.

Este documento sintetiza toda nuestra experiencia y observaciones en una amplia variedad de
aplicaciones SaaS.

¿QUIEN DEBERIA LEER ESTE DOCUMENTO?

Cualquier desarrollador que construya aplicaciones y las ejecute como un servicio.

TWELVE FACTORS

1. Código base (Codebase)

Un código base sobre el que hacer el control de versiones y múltiples despliegues

Es cualquier repositorio (en un sistema de control de versiones centralizado como Subversión),

o cualquier conjunto de repositorios que comparten un commit raíz (en un sistema de control
de versiones descentralizado como Git), siempre hay una relación uno a uno entre el código
base y la aplicación:

 Si hay múltiples códigos base, no es una aplicación pero si es un sistema distribuido.

 Compartir código en varias aplicaciones se considera una violación de la metodología
“twelve factor”.

Una aplicación “twelve-factor” se gestiona siempre con un sistema de control de versiones,

como Git, Mercurial, o Subversión.

2. Dependencias

Declarar y aislar explícitamente las dependencias

Declara todas sus dependencias, completamente y explícitamente, mediante un manifiesto

de declaración de dependencias. Además, usa herramientas de aislamiento de
dependencias durante la ejecución para asegurar que las dependencias, implícitamente, no
afectan al resto del sistema.

Una aplicación “twelve-factor” no depende nunca de la existencia explícita de paquetes

instalados en el sistema.

WALKER ALEXANDER HERRERA VILLANUEVA

1
 UNIVERSIDAD NACIONAL DEL ALTIPLANO – PUNO
Facultad de Ingeniería Mecánica Eléctrica, Electrónica y Sistemas Escuela Profesional de
Ingeniería de Sistemas

3. Configuraciones

Guardar la configuración en el entorno

Es todo lo que puede variar entre despliegues (entornos de preproducción, producción,

desarrollo, etc.), lo cual incluye:

 Recursos que manejan la base de datos, Memcached, y otros “backing services” .

 Credenciales para servicios externos tales como Amazon S3 o Twitter.
 Valores de despliegue como por ejemplo el nombre canónico del equipo para el
despliegue.

Las aplicaciones “twelve-factor” almacenan la configuración en variables de entorno (abreviadas

normalmente como env vars o env).

4. Backing services

Tratar a los “backing services” como recursos conectables

Es cualquier recurso que la aplicación puede consumir a través de la red como parte de su
funcionamiento habitual (como las bases de datos) han sido gestionadas por los mismos
administradores de sistemas que despliegan la aplicación en producción.

El código de una aplicación “twelve-factor” no hace distinciones entre servicios locales y de

terceros.

5. Construir, desplegar, ejecutar

Separar completamente la etapa de construcción de la etapa de ejecución

Se transforma en un despliegue (que no es de desarrollo) al completar las siguientes tres etapas:

 La etapa de construcción es una transformación que convierte un repositorio de código

en un paquete ejecutable llamado construcción (una “build”).
 En la fase de distribución se usa la construcción creada en la fase de construcción y se
combina con la configuración del despliegue actual.
 La fase de ejecución (también conocida como “runtime”) ejecuta la aplicación en el
entorno de ejecución, lanzando un conjunto de procesos de una distribución concreta
de la aplicación.

Las aplicaciones “twelve-factor” hacen una separación completa de las fases de construcción,
de distribución y de ejecución.

6. Procesos

Ejecutar la aplicación como uno o más procesos sin estado

Se ejecuta como uno o más procesos en el entorno de ejecución, el caso más sencillo que
podemos plantear es que el código es un script independiente, el entorno de ejecución es un
portátil de un desarrollador, el compilador o interprete correspondiente del lenguaje está
instalado, y el proceso se lanza mediante la línea de mandatos (por ejemplo, python
my_script.py).

WALKER ALEXANDER HERRERA VILLANUEVA

2
 UNIVERSIDAD NACIONAL DEL ALTIPLANO – PUNO
Facultad de Ingeniería Mecánica Eléctrica, Electrónica y Sistemas Escuela Profesional de
Ingeniería de Sistemas

Los procesos “twelve-factor” no tienen estado y son “share-nothing”.

7. Asignación de puertos

Publicar servicios mediante asignación de puertos

Las aplicaciones web se ejecutan a menudo mediante contenedores web. Por ejemplo, las
aplicaciones de PHP se suelen ejecutar como módulos del HTTPD de Apache, y las aplicaciones
Java en Tomcat.

Las aplicaciones “twelve factor” son completamente auto-contenidas y no dependen de un

servidor web en ejecución para crear un servicio web público.

8. Concurrencia

Escalar mediante el modelo de procesos

Las aplicaciones web se pueden ejecutar de diferentes formas desde el punto de vista del
modelo de procesos que usan. Por ejemplo, los procesos PHP se ejecutan como procesos
pesados (o simplemente procesos).

En las aplicaciones “twelve-factor”, los procesos son ciudadanos de primera clase.

9. Desechabilidad

Hacer el sistema más robusto intentando conseguir inicios rápidos y finalizaciones seguras

Los procesos deberían intentar conseguir minimizar el tiempo de arranque. En el mejor de los
casos, un proceso necesita unos pocos segundos desde que se ejecuta el mandato hasta que
arranca y está preparado para recibir peticiones o trabajos.

Los procesos de las aplicaciones “twelve-factor” son desechables, lo que significa que pueden
iniciarse o finalizarse en el momento que sea necesario.

10. Paridad en desarrollo y producción

Mantener desarrollo, preproducción y producción tan parecidos como sea posible

Donde un desarrollador puede editar en vivo en un despliegue local de la aplicación y un

despliegue en el que la aplicación está en ejecución disponible para que lo usen los usuarios, se
pueden clasificar en tres tipos:

 Diferencias de tiempo.
 Diferencias de personal.
 Diferencias de herramientas.

Las aplicaciones “twelve-factor” están diseñadas para hacer despliegues continuos que reducen
las diferencias entre los entornos de desarrollo y producción.

 Reducir las diferencias de tiempo.

 Reducir las diferencias de personal.
 Reducir las diferencias de herramientas.

WALKER ALEXANDER HERRERA VILLANUEVA

3
 UNIVERSIDAD NACIONAL DEL ALTIPLANO – PUNO
Facultad de Ingeniería Mecánica Eléctrica, Electrónica y Sistemas Escuela Profesional de
Ingeniería de Sistemas

11. Historiales

Tratar los historiales como una transmisión de eventos

Permiten observar el comportamiento de la aplicación durante su ejecución. En entornos

basados en servidores es muy común escribir un fichero en disco (un “fichero de histórico”) pero
este, es tan solo un posible formato de salida y son la transmisión de un conjunto de eventos
ordenados y capturados de la salida de todos los procesos en ejecución y de los “backing
services”.

Una aplicación “twelve-factor” nunca se preocupa del direccionamiento o el almacenamiento

de sus transmisiones de salida.

12. Administración de procesos

Ejecutar las tareas de gestión/administración como procesos que solo se ejecutan una vez

Es el conjunto de procesos que se usa para hacer las tareas habituales de la aplicación (como
procesar las peticiones web), como por ejemplo:

 Ejecutar migraciones de las bases de datos (e.g. manage.py migrate de Django, rake
db:migrate de Rails).
 Ejecutar una consola (también conocidas como REPL) para ejecutar código arbitrario o
inspeccionar los modelos de la aplicación en una base de datos con datos reales.
 Ejecutar scripts incluidos en el repositorio de la aplicación (e.g. php
scripts/fix_bad_records.php).

“Twelve-factor” recomienda encarecidamente lenguajes que proporcionan una consola del tipo
REPL, ya que facilitan las tareas relacionadas con la ejecución de scripts que solo han de usarse
una vez.

WALKER ALEXANDER HERRERA VILLANUEVA

4