Infraestructura como workflow: más allá del Terraform estático
SchemaBridge Team · 2026-01-18 · IaC, DevOps, Cloud Automation
Gestionar las operaciones cloud del Day 2: tratar la infraestructura como un proceso de negocio con estado y de larga duración.
El límite de la «infraestructura como código»: Day 1 vs. Day 2
Nos encanta Terraform (IaC). Resolvió el problema del aprovisionamiento del «Day 1». Describes el estado deseado (10 instancias EC2, 1 RDS, 1 VPC), ejecutas terraform apply y el proveedor cloud lo hace realidad. Es perfecto para recursos estáticos. Es declarativo, idempotente y está bajo control de versiones. Es la base del DevOps moderno.
Pero la realidad de las operaciones cloud es que la complejidad vive en el Day 2. El Day 1 es la boda; el Day 2 es el matrimonio. El Day 2 trata de procesos, no solo de recursos. Trata del ciclo de vida vivo del sistema a medida que cambia con el tiempo.
Piensa en el ciclo de vida de una actualización crítica de base de datos. No es un evento estático; es un workflow:
1. Preparación: Crear un snapshot de la BD principal en S3 por seguridad.
2. Espera: Hay que esperar a que el snapshot termine. En una base de datos grande de varios TB, puede tardar entre 30 y 45 minutos.
3. Aprovisionamiento: Levantar una nueva instancia de BD a partir del snapshot con la nueva versión del motor.
4. Espera: Esperar a que la nueva instancia esté «Available» y «Healthy».
5. Migración: Conectarse a la nueva instancia y ejecutar un script de migración de esquema (Flyway o Liquibase). Puede tardar 1 hora.
6. Verificación: Ejecutar una batería de smoke tests contra la nueva BD para asegurar la integridad de los datos.
7. Conmutación: Si todo va bien, actualizar el CNAME del DNS para que apunte a la nueva BD.
8. Rollback: Si falla cualquier paso, hay que revertir el DNS y destruir la instancia defectuosa.
Terraform encaja mal con esto. Es declarativo, no imperativo. Existen time_sleep y los provisioners local-exec como vías de escape para «esperar 30 minutos» o «ejecutar un script SQL y comprobar el código de salida», pero Terraform no tiene un modelo de proceso duradero, reanudable y con aprobaciones. Para cubrirlo, los equipos suelen envolver Terraform en pipelines de Jenkins, jobs de CircleCI o scripts de Python. Volvemos a la «Glue Code Crisis» de la que hablamos antes en esta serie, pero ahora para la infraestructura. Estos scripts son frágiles, no tienen estado y son imposibles de depurar cuando fallan a mitad de una operación de 4 horas.
Tratar las operaciones como workflows duraderos
En SchemaBridge creemos que las operaciones de infraestructura son workflows de negocio. Tienen los mismos requisitos que un flujo de procesamiento de pagos: fiabilidad, auditabilidad, gestión de estado y recuperación ante errores.
Al trasladar tus operaciones del Day 2 a SchemaBridge, obtienes la potencia de un orquestador duradero para tu nube:
- Esperas duraderas: ¿Necesitas esperar 4 horas a una exportación del data warehouse? El workflow duerme de forma duradera sin ocupar un executor de Jenkins ni un contenedor.
- Puertas de aprobación: ¿Necesitas que un SRE sénior o un responsable de cumplimiento apruebe el cambio de DNS? El workflow se detiene en un paso de Approval hasta que alguien con permisos de aprobación lo apruebe, en la página de Approvals o mediante la API. El estado se conserva tanto si tarda 5 minutos como 5 días (el timeout de aprobación por defecto es de 7 días), y un paso de Slack justo antes puede publicar un mensaje con un enlace a la aprobación pendiente.
- Rutas de rollback explícitas: SchemaBridge no ejecuta compensaciones ocultas por ti, y eso es una ventaja: el rollback es una ruta que tú dibujas. Modela los resultados que esperas como datos — una comprobación de estado que devuelve
failed, o un gateway configurado para convertir una llamada rechazada (4xx) en un resultadoinvalid_input— y enrútalos a una rama de limpieza que restaure la configuración anterior. Un fallo inesperado de un paso detiene la ejecución donde está, para que un operador pueda inspeccionarla y reintentarla desde el paso fallido, en lugar de que se dispare automáticamente un rollback a medio entender.
El patrón «plano de control»: integración con AWS, K8s y Terraform
SchemaBridge no sustituye a Terraform; lo orquesta. Usamos el patrón de plano de control para unificar los mundos estático y dinámico.
1. El disparador: Un desarrollador hace commit o lanza un workflow «Provision Dev Env» desde tu portal de desarrolladores llamando a la URL del webhook del workflow.
2. El aprovisionamiento: SchemaBridge llama a la API de Terraform Cloud (o al endpoint HTTP de tu propio runner) para iniciar la ejecución que crea los recursos físicos. SchemaBridge no invoca terraform por shell: los scripts de los workflows se ejecutan en un sandbox de GraalVM sin acceso a procesos ni al sistema de archivos, por diseño.
3. La espera: Un paso Delay duradero espera y después un paso Gateway comprueba el estado de la ejecución de Terraform. Los workflows son grafos acíclicos, así que en lugar de un bucle de sondeo infinito encadenas un número acotado de pasos de espera y comprobación, o haces que el workflow se vuelva a lanzar a sí mismo tras un Delay — la misma recursión que usa nuestro propio workflow de sistema de despliegue gradual.
4. El post-aprovisionamiento (la «capa de lógica»): Una vez que la infraestructura existe, SchemaBridge llama a los endpoints que ejecutan las migraciones de BD, cargan los datos de prueba y lanzan los tests de aceptación — la API de tu sistema de CI o un pequeño servicio de operaciones que controlas dentro del nuevo clúster.
Este patrón te permite mantener tus recursos definidos en HCL (HashiCorp Configuration Language) mientras tu lógica operativa se define en un grafo visual.
Entornos efímeros: el santo grial de la velocidad de desarrollo
Todo equipo de ingeniería moderno quiere entornos efímeros: una réplica completa de producción para cada Pull Request (PR). Esto permite un aislamiento real y evita bugs antes de que se fusionen en main.
Los enfoques tradicionales fracasan porque son difíciles de limpiar. Levantas recursos para el PR-123, pero el desarrollador olvida cerrar el PR o el script de limpieza falla. Tu factura cloud se dispara con «instancias RDS zombi» y «balanceadores de carga huérfanos».
Con SchemaBridge, un entorno es un workflow con un ciclo de vida definido.
1. Inicio: Levantar recursos (RDS, una caché, servicios ECS) a través de tu API de aprovisionamiento.
2. Espera: Un paso Delay duradero programa el desmontaje en el momento de la creación — por ejemplo, con un TTL de 24 horas. La espera no ocupa ningún worker ni contenedor; la hora de despertar se persiste.
3. Limpieza: Cuando expira el temporizador, el workflow se despierta y llama a tu API de aprovisionamiento para destruir el entorno. Para «desmontarlo en cuanto se fusione el PR», apunta el webhook de merge de tu proveedor Git a un workflow de desmontaje independiente y haz que el desmontaje sea idempotente para que no cause daño si se disparan ambos.
Como el temporizador de desmontaje se programa en la misma ejecución que creó el entorno, es difícil de olvidar. Incluso si todo el clúster de SchemaBridge se reinicia, el temporizador persistido se dispara igualmente y el entorno del PR-123 se destruye según lo previsto. Esto es «recolección de basura para la nube».
Escenario ilustrativo: despliegue blue/green sin intervención para un servicio sensible a la latencia
Imagina un equipo que opera un motor de matching sensible a la latencia y necesita actualizar su servicio principal sin un solo microsegundo de inactividad.
El reto
Una actualización rolling estándar de Kubernetes no sería lo bastante segura si necesitaran verificar la exactitud de la nueva versión con datos en vivo durante 10 minutos antes de cambiar el tráfico. Necesitarían un despliegue complejo en «Shadow Mode».
El enfoque con SchemaBridge
Podrían construir un «Blue/Green Deployment Workflow» en SchemaBridge:
1. Desplegar Green: Levantar la nueva versión del motor junto a la antigua (Green).
2. Tráfico en sombra: Configurar el API Gateway para enviar una copia genérica del tráfico en vivo a Green (fire-and-forget). Las respuestas de Green no se envían a los usuarios, sino que se capturan.
3. Verificar: Tras un Delay de 10 minutos, el workflow obtiene por HTTP una muestra de las respuestas capturadas de Green y de las respuestas correspondientes de Blue (en vivo), y usa JSONata para compararlas.
4. Punto de decisión: Las aristas condicionales enrutan según el resultado de la comparación:
- Si la exactitud es < 100 %, el workflow publica una alerta y llama a la API de despliegue para destruir
Green. - Si la exactitud es == 100 %, el workflow continúa.
5. Conmutar: El workflow actualiza el balanceador de carga para dirigir el tráfico real de usuarios a Green.
6. Limpiar: Espera otra hora (para facilitar el rollback) y después destruye Blue.
El resultado
Un workflow de este tipo podría reducir sustancialmente el riesgo de despliegue. Un equipo SRE podría lanzar un despliegue y desentenderse, sabiendo que el workflow ejecutaría la verificación y la ruta de limpieza explícita que diseñaron — convirtiendo releases arriesgadas e infrecuentes en otras más seguras y rutinarias.
Gestión de costes: el «workflow» de FinOps
La optimización de costes cloud (FinOps) suele ser un proceso manual de insistir a los desarrolladores para que apaguen cosas. SchemaBridge te permite automatizar esta gobernanza.
El patrón Night Watchman
Puedes desplegar un workflow «Night Watchman» que se ejecute cada tarde a las 20:00.
1. Escanear: Pide a tu API de operaciones (por ejemplo, una pequeña Lambda o un servicio interno que envuelva el SDK de tu nube) todos los recursos etiquetados como no productivos. SchemaBridge se comunica con ella por HTTP; no tiene un conector nativo de AWS.
2. Comprobar actividad: Haz que el mismo endpoint informe del uso de CPU de la última hora y quédate solo con los recursos por debajo del 5 %.
3. Apagar: Si están inactivos, llama al endpoint para detener la instancia (no terminarla).
4. Notificar: Envía un mensaje de Slack al propietario: «Hemos pausado tu máquina de desarrollo para ahorrar dinero».
5. Reanudar: Un workflow independiente «start my box», disparado desde tus herramientas de operaciones mediante su URL de webhook, vuelve a arrancar la instancia por la mañana.
Un workflow así de sencillo puede reducir de forma apreciable el gasto en entornos de desarrollo inactivos, recortando el coste continuo de recursos no productivos olvidados y siempre encendidos.
Comparativa: Jenkins/GitLab CI vs. operaciones con SchemaBridge
| Característica | Pipelines CI/CD (Jenkins) | Operaciones con SchemaBridge |
| :--- | :--- | :--- |
| Estado | Ligado a un executor; las esperas largas retienen recursos | Duradero (persistido en PostgreSQL; sobrevive a reinicios) |
| Duración | Minutos/horas | Horas/días (temporizadores duraderos) |
| Lógica | Scripts (Bash/Groovy) | Visual (grafo) |
| Aprobación | Paso de input en el pipeline | Paso de Approval (UI o API), con timeout |
| Recuperación | Reinicio desde una stage | Reintento desde el paso fallido |
| Paralelismo | Limitado por los executors | Fan-out (Spawner) con workers autoescalados |
Checklist experta para la automatización de operaciones
Para modernizar tu stack operativo, sigue estas heurísticas:
1. No programes esperas en scripts: Si estás escribiendo sleep 60 en bash para esperar a un ALB, lo estás haciendo mal. Usa un paso Delay duradero seguido de una comprobación de estado.
2. Automatiza primero la eliminación: Escribe la lógica de limpieza antes que la de creación. Asegúrate de que cada evento de creación tenga una ruta de destrucción correspondiente.
3. Usa puertas de aprobación: No temas incluir a una persona en el bucle para acciones de alto riesgo. Un «Pause for Approval» es una funcionalidad, no un bug.
4. Audita al operador: Registra quién lanzó el entorno y por qué. Haz que el disparador pase el ID del solicitante en el payload y estámpalo en cada recurso que crees.
5. Trata las operaciones como código: Versiona tus workflows operativos igual que el código de tu aplicación. Expórtalos como bundles, guárdalos en tu repositorio para revisión y despliégalos desde la página Deployments (planificar, revisar, aplicar) o con una importación de configuración.
Conclusión: la nube es una máquina de estados
Tu infraestructura no es un montón estático de servidores; es un componente vivo de tu negocio. Al tratarla como una máquina de estados, puedes automatizar las complejas coreografías operativas de varios pasos que hoy consumen la vida de tu equipo SRE. Puedes pasar de «operaciones basadas en tickets» a «operaciones self-service», con seguridad y durabilidad integradas.
Ver también: El mito del arranque en frío: optimizar la JVM para eventos — por qué los workers de larga duración superan a los arranques en frío por evento.