Las medianas empresas siguen sin una solución única para la gestión operativa de sus aplicaciones
Un análisis revela que la falta de un modelo operativo unificado obliga a los equipos a seguir parando el desarrollo para atender incidentes nocturnos.
Empresas con equipos de ingeniería reducidos siguen fallando en la prueba de las 3 a.m.: no basta con que el servicio siga activo, sino que nadie tenga que despertarse para resolverlo. En los casos descritos, un ingeniero que no desarrolló la aplicación recibe la página de error, desconoce los umbrales configurados y no sabe si el sistema se está autocurando o necesita una decisión humana. Esa falta de automatización separa a los servicios que realmente delegan la carga operativa de los que solo la posponen.
El escenario típico incluye alrededor de cuarenta ingenieros, ocho aplicaciones en producción y solo un SRE que combina su rol con el de desarrollador senior. Con una auditoría de cumplimiento pendiente y recursos limitados, la prioridad sigue siendo lanzar funcionalidades, no invertir en personal de infraestructura. Cada sprint dedicado a mejorar la canalización de despliegue es un sprint que no entrega valor al cliente.
El problema se agrava cuando el portafolio incluye aplicaciones heredadas: productos adquiridos, herramientas internas sin mantenedor o software comercial altamente customizado. Estas cargas comparten tres características –están en producción, sirven a clientes o cumplen requisitos regulatorios, y carecen de presupuesto para reescritura– y requieren un entorno que las acepte tal cual, sin forzar una hoja de ruta de modernización.
Una solución viable sería un servicio de gestión de aplicaciones que soporte todo el espectro tecnológico –WAR de Java, servicios .NET en Windows, aplicaciones Python con dependencias fijas y contenedores ya orquestados– y aplique un modelo operativo único: mismo proceso de despliegue, parcheo y escalado. La idea es migrar, gestionar y modernizar dentro de la misma experiencia, sin que cada tipo de aplicación exija un enfoque operativo distinto.
Los datos de la CNCF respaldan esta visión: el informe conjunto con SlashData indica que el 28 % de las organizaciones cuenta con un equipo de ingeniería de plataforma dedicado, el 41 % reparte esas capacidades entre varios equipos y un 3 % no tiene un modelo formal. La mayoría de las medianas empresas se sitúan en ese último segmento, queriendo los resultados de la ingeniería de plataforma sin crearla.
En la práctica, la madurez se detiene tras la tercera aplicación, no tras la primera. Un equipo de cuarenta ingenieros puede mantener saludable un servicio, pero al añadir una carga .NET heredada o una herramienta interna, se multiplican los modelos operativos y desaparece la responsabilidad clara. Contratar más personal no soluciona el vacío; lo que falta es una postura operativa estandarizada.
AWS ha intentado simplificar parte del problema con Elastic Beanstalk en modo clúster, ofreciendo despliegues con una URL y gestión automática de la infraestructura subyacente. Sin embargo, su enfoque sigue siendo más adecuado para aplicaciones net‑new y no para entornos mixtos donde conviven varios lenguajes y plataformas.
Qué queda por ver: si los proveedores de nube podrán ofrecer una capa de gestión que abarque tanto aplicaciones nuevas como heredadas sin requerir una re‑arquitectura completa, y cómo las organizaciones medianas adoptarán esa capa para cerrar la brecha entre velocidad de desarrollo y operatividad segura.
