En 2011, cuando el despliegue en la nube todavía no era el punto de partida sino el destino, ingenieros de Heroku publicaron en 12factor.net un manifiesto breve y directo: doce principios para construir aplicaciones capaces de sobrevivir a entornos cambiantes, escalar sin fricción y moverse entre plataformas sin reescrituras.
No hablaban de frameworks ni de Kubernetes —que aún no existía—, sino de algo más fundamental: cómo debería comportarse una aplicación cuando deja de vivir en un servidor conocido y pasa a ejecutarse en infraestructuras impersonales, efímeras y automatizadas.
Con el tiempo, esos principios se convirtieron en el estándar de facto para lo que hoy llamamos cloud-native (aplicaciones diseñadas para la nube).
🚀 Quarkus y los 12 factores
Ocho años después, Quarkus aparece en un contexto muy distinto: contenedores, orquestadores, autoscaling y pipelines forman parte del día a día. Y aun así, en su README oficial, el equipo afirma sin rodeos:
«Adopta una arquitectura de 12 factores en entornos como Kubernetes»
Esta frase no funciona como un sello de calidad ni como una promesa de marketing. Funciona como una declaración de diseño. Vamos a recorrerlos uno por uno para entender por qué Quarkus se mueve con soltura allí donde otras aplicaciones Java empiezan a sentirse fuera de su elemento.
📦 Factor I — Base de código (Codebase)
«Una sola base de código con control de versiones, muchos despliegues.»
Durante años, en Java fue común tener una misma aplicación empaquetada de distintas formas, con configuraciones embebidas o incluso forks por entorno. El primer factor propone exactamente lo contrario: una relación clara entre código, versiones y despliegues.
Cada servicio suele vivir en su propio repositorio Git, con:
- Relación 1:1 entre base de código y evolución
- Relación 1:N con los entornos donde se despliega
Perfiles, pipelines de CI/CD y herramientas como Tekton o Argo CD permiten desplegar el mismo artefacto en múltiples entornos sin ambigüedad.
📦 Factor II — Dependencias (Dependencies)
«Declarar y aislar dependencias de forma explícita.»
En el mundo pre-cloud, no era raro depender de librerías instaladas en el sistema o de configuraciones implícitas del entorno. Quarkus elimina esa ambigüedad desde el inicio:
| Aspecto | Solución en Quarkus |
|---|---|
| Gestión de dependencias | Maven o Gradle |
| Modelo de extensiones | Declaración explícita en pom.xml |
| Resultado | Builds reproducibles, portables y autocontenidos |
Ya sea como JAR o como ejecutable nativo, el artefacto final incluye exactamente lo necesario para ejecutarse. Nada más, nada menos.
⚙️ Factor III — Configuración (Config)
«Almacenar la configuración en el entorno.»
Quarkus separa claramente código y configuración. Aunque utiliza application.properties o application.yaml, su integración con SmallRye Config y MicroProfile Config permite externalizar completamente los valores sensibles.
El artefacto es el mismo; el entorno define cómo se comporta
| Mecanismo | Uso |
|---|---|
Perfiles (%dev, %test, %prod) | Configuración por entorno |
| Variables de entorno | Valores externos al código |
| ConfigMaps y Secrets | Integración nativa con Kubernetes |
🔌 Factor IV — Servicios externos (Backing Services)
«Tratar los servicios externos como recursos adjuntos.»
Bases de datos, brokers, caches o servicios externos no deberían estar acoplados al código. Quarkus refuerza este principio a través de:
- Extensiones que abstraen la conexión sin fijar implementaciones concretas
- Dev Services que levantan servicios automáticamente en desarrollo usando contenedores
Esto reduce fricción, acelera el onboarding (incorporación de nuevos desarrolladores) y mantiene la portabilidad entre entornos.
🏗️ Factor V — Build, Release, Run
«Separar construcción, liberación y ejecución.»
Quarkus define con claridad estas tres etapas:
| Etapa | Descripción | En Quarkus |
|---|---|---|
| Build | Genera el artefacto | JAR o ejecutable nativo |
| Release | Combina artefacto + configuración | Perfiles, variables de entorno |
| Run | Ejecución en el entorno objetivo | Docker, Podman, Kubernetes, OpenShift |
Esta separación se alinea perfectamente con pipelines modernos y evita efectos colaterales entre etapas.
🔄 Factor VI — Procesos (Processes)
«Ejecutar la aplicación como uno o más procesos sin estado.»
Quarkus promueve servicios stateless (sin estado) por diseño:
- El estado vive en servicios externos (bases de datos, caches, etc.)
- Esto habilita escalado horizontal real
- Su base reactiva (Vert.x) y soporte para REST, mensajería y streaming lo hacen especialmente adecuado para arquitecturas distribuidas
🔌 Factor VII — Asignación de puertos (Port Binding)
«Exportar servicios mediante vinculación de puertos.»
Quarkus expone sus servicios a través de puertos configurables:
quarkus.http.port=8080No hay dependencias ocultas ni configuraciones rígidas. En Kubernetes, esto permite redireccionar tráfico sin modificar el artefacto.
📈 Factor VIII — Concurrencia (Concurrency)
«Escalar mediante el modelo de procesos.»
Gracias a su bajo consumo de memoria y rápido arranque, Quarkus está pensado para escalar horizontalmente.
| Característica | Beneficio para escalar |
|---|---|
| ~12 MB de RAM (nativo) | Más réplicas por nodo |
| Arranque en milisegundos | Respuesta inmediata al autoscaler |
| Procesos independientes | Sin estado compartido |
Funciona de forma natural con mecanismos como el Horizontal Pod Autoscaler de Kubernetes.
⚡ Factor IX — Desechabilidad (Disposability)
«Arranque rápido y apagado limpio.»
Aquí Quarkus brilla. Sus tiempos de arranque —especialmente en modo nativo con GraalVM o Mandrel— permiten:
- ✅ Ciclos de vida cortos
- ✅ Recuperación rápida ante fallos
- ✅ Escalado agresivo bajo demanda
- ✅ Funciones serverless que arrancan en milisegundos
🔀 Factor X — Paridad entre desarrollo y producción (Dev/Prod Parity)
«Mantener los entornos lo más similares posible.»
Dev Services permite que desarrollo, staging y producción compartan la misma base técnica:
- En desarrollo: contenedores automáticos con PostgreSQL, Kafka, Redis…
- En producción: los mismos servicios, solo cambia la conexión
Lo que corre en local se parece mucho a lo que corre en producción, reduciendo sorpresas.
📝 Factor XI — Logs
«Tratar los logs como flujos de eventos.»
Quarkus escribe logs en stdout, listos para ser recolectados por herramientas de observabilidad modernas:
- Formato configurable (JSON, texto plano)
- Nivel controlado por configuración externa
- Integración con Fluentd, Loki, ELK Stack, etc.
quarkus.log.console.format=%d{HH:mm:ss} %-5p [%c{2.}] %s%e%n
quarkus.log.console.json=true🛠️ Factor XII — Procesos administrativos (Admin Processes)
«Ejecutar tareas administrativas como procesos puntuales.»
Migraciones, tareas de mantenimiento o jobs se ejecutan como procesos independientes:
- Flyway o Liquibase para migraciones de base de datos
- Quarkus Scheduler para tareas programadas
- Jobs de Kubernetes para procesos puntuales
Quarkus no obliga a incrustarlos en el runtime principal, favoreciendo el desacoplamiento.
🎯 Conclusión
Los 12 factores no son una moda ni una certificación. Son una forma de pensar aplicaciones cuando el entorno deja de ser predecible: contenedores que nacen y mueren, configuraciones que cambian, escalado que ocurre sin pedir permiso.
Quarkus no adopta estos principios como un añadido tardío ni como una capa cosmética. Están presentes en sus decisiones fundamentales:
| Aspecto | Decisión de diseño |
|---|---|
| Cómo arranca | Rápido, predecible, sin estado |
| Cómo se configura | Externalizado, por perfiles y entorno |
| Cómo se despliega | Artefacto inmutable + configuración variable |
| Cómo interactúa | Servicios externos como recursos intercambiables |
Visto desde este ángulo, los 12 factores no explican qué hace Quarkus, sino por qué se siente tan natural en la nube.