Cuando la capacidad on-premises se agota, la nube pública suele ser la primera opción a la que recurren los equipos de infraestructura. Es rápida de aprovisionar, elimina el problema de la adquisición de hardware y esquiva la pregunta de qué hacer con una infraestructura envejecida.
Lo que no resuelve es si las cargas de trabajo migradas rendirán como el negocio requiere una vez que estén en producción, ni si el diseño de recuperación ha evolucionado al ritmo del lugar donde ahora residen los servicios.
Dos presiones están haciendo más difícil postergar esa pregunta. Los costos de memoria han subido de forma pronunciada, complicando la renovación de hardware para organizaciones que aún operan infraestructura on-premises significativa. Y las empresas que trasladaron cargas a la nube pública descubren cada vez más que el rendimiento en producción no coincide con lo que sugerían las pruebas.
Por qué la renovación on-premises ya no es sencilla
Para los equipos de infraestructura que intentan añadir margen a sus entornos existentes, el mercado de memoria ha creado una restricción real. Gartner prevé que los precios de DRAM aumentarán un 125% a lo largo de 2026, sin una corrección significativa esperada antes de finales de 2027. The Register informó en enero que Samsung ya ha elevado los precios de la memoria para servidores hasta en un 60% y que, combinado con los incrementos de 2025, los costos podrían casi duplicarse hacia mediados de año. La infraestructura de IA está consumiendo una porción desproporcionada del suministro de memoria disponible, dejando la renovación de hardware empresarial compitiendo por componentes a precios elevados y con plazos de entrega extendidos.
Quedarse sin margen on-premises es un problema operativo legítimo. Migrar a la nube para escapar de él es una respuesta razonable a corto plazo. La dificultad es que la urgencia tiende a comprimir la evaluación de si la nube pública es realmente el hogar adecuado a largo plazo para cada carga de trabajo que se traslada.
La producción revela lo que las pruebas no muestran
Los problemas de rendimiento tras la migración suelen aparecer bajo condiciones reales, más que en pruebas controladas. Los volúmenes de producción, los datos en vivo y toda la red de dependencias de servicios se comportan de forma distinta a escala. Para las cargas sensibles a la latencia en particular, la distancia entre donde se ejecuta un servicio y donde están sus usuarios tiene un efecto directo en los tiempos de respuesta que los benchmarks previos a la migración rara vez capturan.
Las cargas de entrenamiento pueden permanecer en entornos grandes y centralizados, pero la inferencia exige proximidad a los usuarios y a los datos. Dave McCarthy, vicepresidente de investigación de IDC, observó en diciembre que el edge computing será necesario para abordar la latencia y la privacidad a medida que la IA pasa del entrenamiento a la inferencia. El panorama tecnológico 2026 de Deloitte estima que la inferencia representará aproximadamente dos tercios de todo el cómputo de IA para fin de año, frente a un tercio en 2023.
Una carga de trabajo puede estar bien aprovisionada y completamente gestionada en un entorno hiperescalar y aun así estar demasiado lejos de los usuarios y los datos a los que sirve.
La planificación de recuperación queda con el cliente, no con la plataforma
La infraestructura resiliente y un plan de recuperación probado no son lo mismo. La guía de responsabilidad compartida de Microsoft para la fiabilidad de Azure establece claramente que, si bien la plataforma proporciona disponibilidad de infraestructura, la configuración y prueba de una estrategia de recuperación ante desastres acorde a objetivos de negocio específicos sigue siendo responsabilidad del cliente.
Los fallos de recuperación rara vez provienen de una caída completa de la plataforma. Con mayor frecuencia se originan en procesos de failover que nunca se han probado a la escala adecuada; entornos de recuperación geográficamente alejados de las operaciones; o servicios restaurados que ya no reflejan el estado de producción del que depende el negocio. Migrar una carga de trabajo sin revisar el diseño de recuperación arrastra esos riesgos hacia adelante.
Conversamos regularmente con empresas que asumieron que el modelo de resiliencia de su proveedor de nube cubría sus necesidades de recuperación. Lo que descubren cuando lo prueban, o cuando necesitan invocar un plan, es que el entorno de recuperación está en una región diferente, la latencia es más alta de lo esperado y el servicio restaurado no rinde como el negocio requiere. La planificación de continuidad tiene que partir de lo que el negocio realmente necesita, y desde ahí trabajar hacia atrás para determinar dónde deben residir las cargas de trabajo.
Ubicar las cargas según lo que requieren
La infraestructura híbrida ha vuelto al foco porque la mayoría de las instalaciones contienen cargas de trabajo con requerimientos genuinamente distintos. Un servicio de front-end con picos de tráfico impredecibles se adapta a la elasticidad de la nube pública. Una aplicación sensible a la latencia o una carga de inferencia de IA puede necesitar estar más cerca de los usuarios, porque enrutar solicitudes a una región de nube distante añade una demora que el procesamiento en tiempo real no puede absorber. Un entorno de recuperación necesita separación geográfica de la producción sin dejar de ser operativamente alcanzable. Los datos regulados pueden requerir alojamiento en una jurisdicción que pueda evidenciarse claramente ante auditores. Tratar todo como equivalente, y ubicarlo por defecto en el mismo entorno, es donde se acumulan los problemas de rendimiento y las brechas de recuperación.
Un modelo de infraestructura distribuido requiere conectividad privada, de alto ancho de banda y baja latencia entre sitios y nubes para mantenerse operativamente coherente. Para las organizaciones con requisitos de residencia de datos, un modelo de colocation local hace más fácil demostrar la jurisdicción que una infraestructura repartida entre regiones hiperescalares.
La nube pública tiene un papel legítimo en la mayoría de las estrategias de infraestructura empresarial. La pregunta más útil es cuáles cargas de trabajo pertenecen allí, y cuáles necesitan un entorno privado con controles más estrictos sobre la ubicación de los datos, el rendimiento y la recuperación.
Por Steve Spittal, Director de Tecnología, Pulsant
📬 Newsletter gratuito
