Infraestructura como Workflow: más allá del Terraform estático
SchemaBridge Team · 2026-01-18 · IaC, DevOps, Cloud Automation
Gestionando las operaciones cloud del Día 2. Tratando la infraestructura como un proceso de negocio duradero y de larga duración.
El límite de la "Infraestructura como Código": Día 1 frente a Día 2
Amamos Terraform (IaC). Resolvió el problema del aprovisionamiento del "Día 1". Describes tu estado deseado (10 instancias EC2, 1 RDS, 1 VPC), ejecutas terraform apply, y el proveedor cloud lo hace realidad. Esto es perfecto para recursos estáticos. Es declarativo, idempotente y controlado por versiones. Es la piedra angular del DevOps moderno.
Pero la realidad de las operaciones cloud es que la complejidad vive en el Día 2. El Día 1 es la boda; el Día 2 es el matrimonio. El Día 2 trata de Procesos, no solo de Recursos. Se trata del ciclo de vida vivo y respirante del sistema a medida que cambia con el tiempo.
Considera 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: Instantánea (snapshot) de la BD principal a S3 por seguridad.
2. Espera: Debes esperar a que la instantánea se complete. Para una base de datos multi-TB grande, esto podría llevar de 30 a 45 minutos.
3. Aprovisionamiento: Levantar una nueva instancia de BD desde la instantánea usando la nueva versión del motor.
4. Espera: Esperar a que la nueva instancia esté "Disponible" y "Saludable".
5. Migración: Conectarse a la nueva instancia y ejecutar un script de migración de esquema (Flyway o Liquibase). Esto podría tardar 1 hora.
6. Verificación: Ejecutar un conjunto de smoke tests contra la nueva BD para garantizar la integridad de los datos.
7. Conmutación: Si tiene éxito, actualizar el CNAME de DNS para que apunte a la nueva BD.
8. Rollback: Si algún paso falla, debes revertir el DNS y destruir la instancia rota.
Terraform no puede expresar esto. Es declarativo, no imperativo. No sabe cómo "esperar 30 minutos" o "ejecutar un script SQL y comprobar el código de salida". Para manejar esto, los equipos suelen recurrir a envolver Terraform en pipelines de Jenkins, jobs de CircleCI o scripts de Python. Volvemos a la "crisis del Glue Code" (Parte 1), pero ahora para infraestructura. Estos scripts son frágiles, sin estado, e imposibles de depurar cuando fallan a mitad de una operación de 4 horas.
Tratando 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 de errores.
Al trasladar tus operaciones de Día 2 a SchemaBridge, obtienes el poder de un Orquestador Duradero para tu nube:
- Espera duradera: ¿Necesitas esperar 4 horas a que se exporte un data warehouse? El workflow duerme de forma duradera (Parte 7) sin consumir un ejecutor de Jenkins ni un contenedor.
- Puertas de aprobación visuales: ¿Necesitas que un SRE senior o un responsable de cumplimiento apruebe el cambio de DNS? El workflow se pausa y envía una notificación de Slack con un botón de "Aprobar". El estado se preserva hasta que hagan clic, ya sea en 5 minutos o en 5 días.
- Rollbacks tipo saga: Si la migración falla a mitad de camino, el workflow dispara automática y fiablemente la restauración de la configuración anterior de la base de datos.
El patrón "Control Plane": integrando con AWS, K8s y Terraform
SchemaBridge no reemplaza a Terraform; lo orquesta. Usamos el Patrón Control Plane para unificar el mundo estático y el dinámico.
1. El disparador: Un desarrollador hace commit de código o dispara manualmente un workflow de "Aprovisionar Entorno de Desarrollo" desde el portal interno de desarrolladores (Backstage).
2. El aprovisionamiento: SchemaBridge llama a la API de Terraform Cloud (o ejecuta un terraform apply en un Worker Seguro) para crear los recursos físicos.
3. La espera: El workflow consulta (poll) la API de Terraform hasta que la ejecución esté de forma segura "Aplicada". Maneja la naturaleza asíncrona de la nube.
4. La post-provisión (la "capa de lógica"): Una vez que la infraestructura existe, SchemaBridge se conecta al nuevo clúster de Kubernetes y ejecuta las migraciones de BD, siembra los datos de prueba y ejecuta las pruebas de aceptación.
Este patrón te permite mantener tus recursos definidos en HCL (HashiCorp Configuration Language) mientras mantienes tu lógica operativa definida en un Grafo Visual.
Entornos efímeros: el Santo Grial de la velocidad del desarrollador
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 verdadero aislamiento y previene bugs antes de que se fusionen a main.
Los enfoques tradicionales fallan 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 de la nube explota con "Instancias RDS Zombis" y "Balanceadores de Carga Huérfanos".
Con SchemaBridge, un Entorno es un workflow con un ciclo de vida definido.
1. Inicio: Levantar recursos (RDS, Redis, servicios ECS).
2. Espera: El workflow entra en un Estado de Espera. Espera a que el PR se fusione O a que transcurra un TTL predefinido (p. ej., 24 horas).
3. Limpieza: Cuando llega la señal o expira el temporizador, el workflow se despierta automáticamente y ejecuta terraform destroy.
Porque la lógica de limpieza es parte de la misma instancia de workflow duradero que la lógica de creación, es imposible olvidarla. Incluso si todo el clúster de SchemaBridge se reinicia, recordará que necesita destruir el entorno del PR-123 a las 5:00 PM. Esto es "recolección de basura para la nube".
Caso de estudio: despliegue Blue/Green sin intervención humana para trading de alta frecuencia
Trabajamos con una firma de trading de alta frecuencia que necesitaba actualizar su motor de emparejamiento (matching engine) principal sin un microsegundo de inactividad.
El desafío
Una actualización rolling estándar de Kubernetes no era lo suficientemente segura porque necesitaban verificar la exactitud financiera de la nueva versión con datos en vivo durante 10 minutos antes de conmutar el tráfico. Necesitaban un complejo despliegue en "Modo Sombra".
La solución de SchemaBridge
Construyeron un "Workflow de Despliegue Blue/Green" en SchemaBridge:
1. Desplegar Green: Levantar la nueva versión del motor junto a la antigua (Green).
2. Tráfico sombra: Configurar el API Gateway (Parte 9) 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, pero se capturan.
3. Verificar: El workflow observó los logs de Green durante 10 minutos. Usó JSONata para comparar las salidas financieras de Green frente a Blue (la versión en vivo).
4. Punto de decisión:
- Si la exactitud < 100%, el workflow dispara una alerta y destruye
Green. - Si la exactitud == 100%, el workflow continúa.
5. Conmutación: El workflow actualiza el balanceador de carga para conmutar el tráfico real de usuarios a Green.
6. Limpieza: Esperó una hora más (para facilitar un rollback) y luego destruyó Blue.
El resultado
Redujeron su riesgo de despliegue a casi cero. El equipo de SRE podía disparar un despliegue e irse a comer, sabiendo que el workflow gestionaría automáticamente la compleja verificación, monitorización y lógica de rollback. Pasaron de 1 despliegue por semana a 10 despliegues por día.
Gestión de costes: el "workflow" de FinOps
La optimización de costes de la nube (FinOps) suele ser un proceso manual de insistirle a los desarrolladores para que apaguen las cosas. SchemaBridge te permite automatizar esta gobernanza.
El patrón del "vigilante nocturno"
Puedes desplegar un workflow "Vigilante Nocturno" que se ejecuta cada noche a las 8:00 PM.
1. Escanear: Aislar todos los recursos etiquetados como no productivos.
2. Comprobar actividad: Comprobar las métricas de CloudWatch para un uso de CPU < 5% durante la última hora.
3. Apagado: Si está inactivo, detener la instancia (no terminarla).
4. Notificar: Enviar un mensaje de Slack al propietario: "Pausamos tu máquina de desarrollo para ahorrar dinero. Haz clic aquí para reanudar."
5. Reanudar: Cuando el desarrollador hace clic en el botón por la mañana, una señal (Parte 7) despierta al workflow para volver a arrancar la instancia.
Este sencillo workflow le ahorró a uno de nuestros clientes empresariales 40.000 $ al mes en costes de AWS EC2.
Comparación: Jenkins/GitLab CI frente a operaciones de SchemaBridge
| Función | Pipelines de CI/CD (Jenkins) | Operaciones SchemaBridge |
| :--- | :--- | :--- |
| Estado | Efímero (se pierde al reiniciar) | Duradero (sobrevive años) |
| Duración | Minutos/horas | Días/semanas/meses |
| Lógica | Scripted (Bash/Groovy) | Visual (Grafo) |
| Aprobación | Básica (botón en la UI) | Rica (Slack/Email/Webhooks/Móvil) |
| Recuperación | Reintentar desde el principio | Reanudar desde el punto de fallo |
| Paralelismo | Limitado por ejecutores | Escalado serverless (Parte 3) |
Checklist de experto para la automatización de operaciones
Para modernizar tu stack operativo, sigue estas heurísticas:
1. No scriptees las esperas: Si estás escribiendo sleep 60 en bash para esperar a un ALB, lo estás haciendo mal. Usa un bucle de sondeo en un workflow duradero.
2. Automatiza primero el borrado: Escribe la lógica de limpieza antes que la lógica 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 poner a un humano en el bucle para acciones de alto riesgo. Una "pausa para aprobación" es una funcionalidad, no un error.
4. Audita al operador: Registra quién disparó el entorno y por qué. Usa el contexto del workflow para etiquetar recursos con el User_ID del solicitante.
5. Trata las operaciones como código: Controla por versiones tus workflows operativos igual que tu código de aplicación. Usa la integración con git de SchemaBridge para revisar cambios en tu lógica de despliegue.
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 y respirante de tu negocio. Al tratarla como una máquina de estados, puedes automatizar las complejas danzas operativas de múltiples pasos que actualmente consumen la vida de tu equipo de SRE. Puedes pasar de "operaciones basadas en tickets" a "operaciones de autoservicio" con seguridad y durabilidad integradas.
En la Parte 12, veremos el "mito del arranque en frío" y cómo lograr una latencia de submilisegundos en una arquitectura de eventos serverless sin mantener servidores calientes.