14. Aplicación práctica y cierre

Checklist consolidado

#	Factor	Pregunta clave de auditoría
I	Código base	¿Un único repo, múltiples despliegues identificables?
II	Dependencias	¿Manifiesto declarado + aislamiento, sin asumir nada del sistema?
III	Configuración	¿Pasa el test del open source? ¿Todo en variables de entorno?
IV	Backing services	¿Se accede vía URL/credencial, intercambiable sin tocar código?
V	Build, release, run	¿Releases inmutables, con ID único, y rollback posible?
VI	Procesos	¿Stateless y share-nothing? ¿Sin sticky sessions?
VII	Asignación de puertos	¿La app expone HTTP por sí misma, sin servidor externo asumido?
VIII	Concurrencia	¿Tipos de proceso independientes, escalables por separado?
IX	Desechabilidad	¿Arranque en segundos y SIGTERM manejado con gracia?
X	Paridad dev/prod	¿Mismos backing services, mismo tipo y versión, en todos los entornos?
XI	Logs	¿Todo a stdout, sin gestión propia de archivos de log?
XII	Administración	¿Tareas puntuales en el mismo entorno y release que el resto?

Cómo auditar una aplicación existente

Un ejercicio simple para aplicar este curso hoy mismo: recorrer la tabla de arriba factor por factor sobre un proyecto real, marcando cumple / no cumple / parcial en cada fila. Las violaciones más comunes que suelen aparecer primero:

• Credenciales en el código o en archivos versionados (Factor III).
• Sticky sessions configuradas “porque siempre funcionó así” (Factor VI).
• Scripts de migración corridos manualmente en un entorno distinto al de la app (Factor XII).
• Backing services distintos entre dev y producción “para simplificar” (Factor X).

No hace falta resolver los 12 a la vez: priorizar por impacto y riesgo (config y stateless primero) da resultados rápidos.

Vigencia en el ecosistema cloud-native (2026)

Los 12 factores se escribieron antes de que Docker y Kubernetes existieran, pero son la base implícita de ambos:

• Contenedores: una imagen Docker es, por definición, una build (Factor V) que empaqueta dependencias aisladas (Factor II).
• Kubernetes: ConfigMap y Secret son variables de entorno estructuradas (Factor III); un Deployment con RollingUpdate implementa releases inmutables con rollback (Factor V); readinessProbe/livenessProbe + preStop hooks son la forma moderna de desechabilidad (Factor IX).
• PaaS y serverless: exigen procesos stateless (Factor VI) y port binding (Factor VII) como requisito de entrada, no como opción.
• Observabilidad moderna (ver también el tutorial de OpenTelemetry en este sitio): el patrón “todo a stdout, que la infraestructura enrute” (Factor XI) es el mismo principio detrás de los collectors de logs actuales.

Cierre

Los 12 Factores no son una lista de tecnologías específicas — son una forma de pensar el ciclo de vida completo de una aplicación: de dónde viene el código, qué cambia entre entornos, cómo se convierte en proceso, cómo se comporta corriendo y cómo se opera. Dominarlos da un vocabulario común para conversar con cualquier equipo de plataforma, sin importar si esa plataforma es Heroku, Kubernetes o un PaaS interno.

Recursos

• Manifiesto original en español: 12factor.net/es
• Tutoriales relacionados en este sitio: Kubernetes ligero con K3s, Dokploy, OpenTelemetry, Observabilidad