Cómo maximizar la agilidad en el despliegue de aplicaciones
La agilidad no termina cuando el equipo completa un Incremento. Una de las decisiones más importantes y complejas que enfrentan los líderes de TI es dónde y cómo desplegar las aplicaciones. Para maximizar el impacto en el negocio, la mayoría de las aplicaciones deben aprovechar recursos en todo el ecosistema de TI, incluidos centros de datos, nubes públicas, colocación y entornos edge.
El desafío del despliegue en entornos ágiles
Los equipos Agile se enfocan en entregar valor de forma iterativa, pero esa entrega se vuelve irrelevante si la aplicación no se despliega en el lugar adecuado. Un estudio de ESG (Enterprise Strategy Group) de 2024 encontró que el 81% de los líderes de TI enfrentan desafíos con la portabilidad de aplicaciones y datos entre ubicaciones como centro de datos, nube pública, colocación y edge. Esta fricción en el despliegue anula gran parte de la agilidad que los equipos logran en la fase de desarrollo.
Para los equipos Scrum, esto plantea preguntas importantes:
- ¿El Incremento del Sprint está optimizado para su entorno de despliegue?
- ¿Las decisiones de infraestructura están alineadas con los objetivos del Sprint?
- ¿El equipo tiene visibilidad sobre dónde y cómo se ejecutará el software?
- ¿El tiempo de despliegue está incluido en la capacidad del Sprint o se trata como un costo externo?
El problema es más profundo de lo que parece. Imagina un equipo que trabaja en una aplicación de análisis en tiempo real para una cadena de retail. Durante tres Sprints, desarrollan una funcionalidad de recomendación de productos basada en machine learning. Cuando llega el momento de desplegar, descubren que la inferencia del modelo requiere GPUs que su nube pública actual no ofrece a un costo razonable, y que mover los datos de entrenamiento desde el centro de datos corporativo tomaría semanas. La funcionalidad queda en un limbo técnico durante dos meses. Este escenario, más común de lo que parece, es el resultado directo de no considerar el despliegue durante la planificación del Sprint.
Factores que influyen en las decisiones de despliegue
Tipo de aplicación
No todas las aplicaciones son iguales. Una API ligera puede funcionar perfectamente en la nube pública, mientras que una aplicación con requisitos estrictos de latencia puede necesitar ejecutarse on-premises. Una aplicación de IoT industrial que procesa datos de sensores en milisegundos no puede permitirse el viaje de ida y vuelta a una nube pública; necesita capacidad de computación en el edge. Por otro lado, una aplicación web interna de gestión de recursos humanos probablemente funcionará sin problemas en cualquier nube pública, y migrarla no debería ser complejo.
Necesidades del negocio
Los equipos Agile deben considerar el impacto de las decisiones de despliegue en los usuarios finales. El 40% de las organizaciones miden la efectividad del despliegue por la satisfacción del usuario, lo que debería importar directamente a los equipos que trabajan con user stories. Si una funcionalidad se despliega en una región lejana al usuario, la latencia puede arruinar la experiencia aunque el código sea perfecto.
Prioridades organizacionales
| Factor | % de organizaciones que lo consideran crítico |
|---|---|
| Acceso y movilidad de datos | 54% |
| Llamadas API requeridas por la red | 49% |
| Ancho de banda disponible | 49% |
| Impacto en presupuesto/costos | 48% |
| Rendimiento/latencia | 43% |
| Disponibilidad/SLAs | 38% |
| Cumplimiento normativo | 35% |
| Portabilidad futura | 29% |
Un criterio que casi nadie considera: el costo del movimiento de datos
La mayoría de los equipos evalúa el costo de cómputo y almacenamiento, pero pocos consideran el costo de mover datos entre entornos. Las tarifas de egress en nubes públicas pueden representar entre el 20% y el 50% de la factura total en aplicaciones con uso intensivo de datos. Para una aplicación de videoanálisis que procesa terabytes diarios, desplegarla en una nube pública sin considerar el costo de salida de datos puede duplicar el costo operativo mensual.
El modelo cloud-first y sus excepciones
El 47% de los tomadores de decisiones prefieren un modelo cloud-first para nuevas aplicaciones. Sin embargo, incluso las organizaciones cloud-first hacen excepciones basadas en:
- Preferencia del propietario de la aplicación — el equipo que construye la aplicación conoce mejor sus necesidades de infraestructura
- Gobernanza de datos — regulaciones sectoriales (banca, salud, gobierno) que exigen datos en ubicaciones geográficas específicas
- Costo total de propiedad (TCO) — a largo plazo, la nube no siempre es más barata, especialmente con cargas de trabajo predecibles y estables
- Datos existentes on-premises — migrar grandes volúmenes de datos existentes puede ser prohibitivo en tiempo y costo
Al menos un 25% de las aplicaciones se consideran no adecuadas para despliegue en nube pública por razones de rendimiento, seguridad, complejidad o cumplimiento normativo, según datos de ESG.
Marco de decisión para elegir entorno de despliegue
Propongo un árbol de decisión simple para que los equipos Agile evalúen sus opciones durante el Sprint Planning:
- ¿La aplicación maneja datos sensibles regulados? → Sí: evaluar on-premises o nube privada primero. No: continuar.
- ¿Requiere latencia menor a 10ms? → Sí: evaluar edge u on-premises. No: continuar.
- ¿La carga de trabajo es predecible? → Sí: el TCO puede favorecer on-premises o reservas de capacidad en nube. No: nube pública con auto-scaling.
- ¿El equipo tiene experiencia operativa en el entorno candidato? → No: considerar que la curva de aprendizaje puede retrasar la entrega inicial.
- ¿Los datos de entrada ya están en un entorno específico? → Sí: desplegar cerca de los datos para minimizar costos de transferencia.
Este marco permite a los equipos tomar decisiones informadas durante el Sprint, no como una reflexión tardía cuando el código ya está listo.
Multicloud by design: el enfoque ágil para la infraestructura
Así como Scrum promueve la inspección y adaptación, el enfoque multicloud by design propone tener una estrategia deliberada para distribuir aplicaciones donde mejor funcionen, en lugar de terminar en múltiples nubes por defecto sin un plan coherente.
Los principios del multicloud by design se alinean naturalmente con los valores ágiles:
- Individuos e interacciones — los equipos deben poder elegir el entorno que mejor se adapte a su trabajo
- Software funcionando — la medida real del progreso es el software desplegado y funcionando correctamente
- Colaboración con el cliente — las decisiones de infraestructura deben discutirse con stakeholders de negocio
- Respuesta ante el cambio — poder mover aplicaciones entre entornos cuando las condiciones del negocio cambien
Un buen ejemplo de multicloud by design en acción: un equipo que desarrolla una plataforma de e-commerce utiliza AWS para la capa de presentación y API pública, Azure para los servicios de IA y machine learning (aprovechando Cognitive Services), y un centro de datos on-premises para el procesamiento de pagos (por cumplimiento PCI-DSS). La aplicación está diseñada desde el principio para ser portable, utilizando contenedores y Kubernetes como capa de abstracción.
Estrategias de despliegue: cómo y cuándo usarlas
| Estrategia | Descripción | Cuándo usarla | Riesgo |
|---|---|---|---|
| Rolling update | Reemplaza instancias gradualmente sin tiempo de inactividad | Despliegues rutinarios, actualizaciones menores | Bajo |
| Blue-green | Dos entornos idénticos; se cambia el tráfico al nuevo | Releases grandes que requieren validación previa | Medio |
| Canary | Nuevo código se despliega a un pequeño % de usuarios primero | Funcionalidades de alto riesgo, pruebas A/B | Medio-Alto |
| Feature flags | Funcionalidades se activan/desactivan sin nuevo despliegue | Lanzamientos controlados, experimentación | Bajo |
La estrategia de feature flags merece atención especial para equipos Agile. Permite desplegar código incompleto a producción sin afectar a los usuarios, activando funcionalidades cuando están listas. Esto separa el despliegue técnico del lanzamiento de funcionalidades, una distinción crucial para la agilidad real. Un equipo puede hacer deploy varias veces al día mientras lanza una funcionalidad grande de forma gradual durante varias semanas.
Cómo los equipos Agile pueden mejorar el despliegue
1. Incluir criterios de despliegue en la Definition of Done
La DoD debería incluir no solo que el código funciona, sino que está desplegado correctamente en el entorno objetivo y cumple con los requisitos de rendimiento y seguridad. Una DoD madura podría incluir: "El Incremento está desplegado en un entorno similar a producción con tests de integración pasando" o "Las configuraciones de infraestructura están versionadas en el repositorio de IaC".
2. Involucrar a infraestructura en las Sprint Reviews
Los equipos de operaciones e infraestructura deberían participar en las Sprint Reviews para entender cómo las nuevas funcionalidades afectan los requisitos de despliegue. Esto evita sorpresas de última hora y permite que las decisiones de infraestructura se tomen durante el Sprint, no al final.
3. Automatizar el despliegue como parte del Sprint
Cada Sprint debería producir no solo un Incremento de software, sino también las configuraciones de infraestructura necesarias para desplegarlo (Infrastructure as Code). Herramientas como Terraform, Pulumi o AWS CDK permiten que los equipos definan su infraestructura como código, versionándola junto con la aplicación.
4. Medir el tiempo de despliegue como métrica ágil
El lead time desde el commit hasta producción es una de las métricas más importantes para un equipo Agile. Según el State of DevOps Report 2023 de Google Cloud, los equipos de alto rendimiento tienen un lead time de menos de una hora, mientras que los equipos de bajo rendimiento miden su lead time en semanas o meses. Si el despliegue es lento, la agilidad se ve comprometida sin importar lo bien que funcione el Scrum dentro del equipo.
5. Invertir en plataformas de internal developer platform (IDP)
Una tendencia creciente es que los equipos construyan o adopten plataformas internas de desarrollo que abstraigan la complejidad del despliegue. Herramientas como Backstage, Port o Humanitec permiten a los desarrolladores autogestionar sus despliegues sin necesidad de tickets a operaciones, reduciendo el tiempo de despliegue de días a minutos. Para un equipo Scrum, esto significa que cada Sprint puede terminar con despliegues reales, no solo con código "terminado" esperando en un repositorio.
6. Realizar un "despliegue de prueba" al inicio del Sprint
Una práctica que recomiendo personalmente: al comenzar un Sprint, el equipo dedica las primeras horas a desplegar el Incremento del Sprint anterior en un entorno lo más parecido posible a producción. Esto revela problemas de configuración, dependencias faltantes o requisitos de infraestructura antes de que el equipo invierta un Sprint completo construyendo sobre una base incorrecta. Es el equivalente Agile a "fallar rápido".
Lo que nadie te dice sobre la agilidad en el despliegue
El mayor obstáculo para la agilidad en el despliegue no es técnico, sino organizativo. Los equipos de operaciones e infraestructura suelen estar separados de los equipos de desarrollo, con procesos de aprobación, ventanas de cambio y comités de revisión que añaden días o semanas al ciclo de despliegue. La solución no es mejorar la tecnología, sino romper los silos organizativos. Los equipos DevOps de alto rendimiento no tienen mejores herramientas; tienen menos barreras organizativas.
Además, el 38% de las organizaciones citan la falta de habilidades como una barrera importante para optimizar el despliegue, según un estudio de IDC. No basta con comprar herramientas de automatización; hay que invertir en la formación del equipo en conceptos de infraestructura, redes y seguridad.
Conclusión
La agilidad real requiere que las decisiones de despliegue sean tan ágiles como el desarrollo mismo. Un equipo que entrega código rápido pero tarda semanas en desplegarlo no es verdaderamente ágil. Al integrar las consideraciones de infraestructura y despliegue en los eventos y artefactos de Scrum —desde la Definition of Done hasta las Sprint Reviews— los equipos pueden maximizar la velocidad, la simplicidad y el control de costos en cada entrega. En un mundo donde la frecuencia de despliegue es el indicador más claro de madurez tecnológica, no puedes permitirte que el despliegue sea tu cuello de botella.