Domando el monolito: Primeros días de DevOps en un sistema legado
Un nuevo ingeniero de DevOps se une a un equipo donde una aplicación monolítica —el corazón de la arquitectura— coexiste con tensiones con microservicios. El estado compartido entre componentes genera cuellos de botella en los despliegues. El pipeline maneja compilaciones, pruebas, entornos de staging y aprobaciones manuales antes de producción. Los problemas surgen en el momento del acceso: "permiso denegado" paraliza el ritual de lanzamiento.
El equipo realiza standups diarios: los desarrolladores comparten avances, bloqueos y planes. El DBA alerta sobre riesgos de migración, el líder de equipo recuerda las reglas no escritas. Sin automatización, las aprobaciones de acceso se convierten en un calvario de varios pasos: solicitud, capacitación, doble aprobación.
Estructura del pipeline y fallos comunes
El despliegue arranca con la luz verde del pipeline:
- Compilación de artefactos.
- Pruebas unitarias e integración.
- Despliegue en staging.
- Aprobación manual (el cuello de botella).
- Despliegue en producción.
Los guardianes de seguridad intervienen en la etapa manual: sin firma, rechazo. Los rollback son rutina. El runbook permanece en borrador, mientras el mago del legado (arquitecto) advierte contra despertar al monolito dormido.
El monolito controla el estado compartido, los microservicios dependen de él, lo que genera conflictos de recursos. La observabilidad —métricas, alertas, logs— se configura para despliegue en vivo durante el lanzamiento.
Estructura del equipo y rituales
El escuadrón de estabilidad incluye:
- Gerente de producto (orquesta los lanzamientos).
- Líder de equipo (gestiona riesgos).
- DBA (guardián de la base de datos, contrario a índices espontáneos).
- Desarrolladores (arreglen esos FIXME en el código).
- Inquisidor de seguridad (firmas y accesos).
Los standups son brutalmente honestos: logros de ayer, plan de hoy, bloqueos. Agile oculta plazos, pero la realidad (permiso denegado) prevalece. El pager vibra con alertas oportunas.
Desafíos de la arquitectura legado
El diagrama del sistema parece una mazmorra: monolito en el núcleo, microservicios en los bordes. El estado compartido provoca:
- Guerras por recursos.
- Dependencias de despliegue.
- Intervenciones manuales.
La adopción de IaC (infraestructura como código) tropieza con obstáculos humanos y de procesos. Los permisos existen, pero son caóticos —ideales para refactorizar roles y políticas.
Lecciones clave:
- Los monolitos con microservicios necesitan un runbook unificado para despliegues.
- Las aprobaciones manuales son un antipatrón; automatiza RBAC.
- Los standups detectan bloqueos tempranos, pero las puertas de seguridad permanecen firmes.
- El estado compartido genera incidentes; planifica la migración.
- La observabilidad (métricas, alertas, logs) es esencial para lanzamientos en producción.
Hoja de ruta de optimización
Desde el día uno: estandariza el pipeline, elimina pasos manuales, configura observabilidad. No toques el legado sin plan —pruebas primero, luego lanzamiento. El equipo está listo para el cambio si canalizamos el caos vía Kanban.
— Editorial Team
Aún no hay comentarios.