Cloud-Repatriation: Lo que realmente queda pendiente en la relocalización

Ocho de cada diez empresas quieren repatriar al menos una carga de trabajo desde la nube. Quien interprete esto como el gran fin de la cloud, cae en una ilusión estadística: lo que regresa es lo que resulta rentable. Arquitectos y responsables de TI deben ahora clasificar qué tipo de carga de trabajo realmente se beneficia y cuál se queda exactamente donde está.

Lo más importante en resumen

• Selectivo, no generalizado: Las cifras de IDC varían entre el 71 y el 86 % según la definición. La repatriación es una decisión puntual, no un giro estratégico.
• Tres impulsores, no uno: La carga constante de inferencia con GPU, la presión regulatoria y la gravedad de los datos determinan qué regresa. Quien mezcle los tres pierde precisión.
• Vale la pena: Inferencia de IA con uso constante, bases de datos reguladas críticamente, pipelines intensivas en datos. No vale la pena: frontends web fluctuantes, servicios pequeños sin requisitos regulatorios.
• Costes ocultos: Observabilidad, bloqueos de licencias por servicios gestionados y la brecha de habilidades entre operaciones cloud-native y on-prem suelen quedar fuera del cálculo.

Relacionado:FinOps: reducir costes en la nube un 30 % es realista  /  AWS y Azure bajo supervisión de la UE: el lock-in se tambalea

Por qué el 86 % no significa lo que parece

Los titulares son claros: el 86 % de los CIO planean repatriar cargas de trabajo desde la nube pública. Suena a éxodo. Pero quien lea los estudios con atención notará que esa cifra es un rango, no un dato fijo. Dependiendo de qué se considere «repatriación» -reubicación completa de cargas, ajustes puntuales o reorientación híbrida-, el valor oscila entre el 71 y el 86 %.

Un artículo de la revista hermana de EVM, Digital Chiefs, califica estos titulares de ilusión estadística. La idea central: en lugar de un movimiento masivo de vuelta al hardware propio, se trata de una decisión selectiva para tipos concretos de cargas de trabajo. La mayoría de las empresas mantienen un modelo híbrido: trasladan solo lo que puede operarse de forma más económica o segura en su propio centro de datos, y dejan en la nube lo que allí funciona mejor.

Para arquitectos y responsables de TI en pymes, la pregunta es, pues: ¿qué carga de trabajo va a dónde? Y para responder, hay que distinguir entre impulsores, no guiarse por el estado de ánimo.

Tres impulsores bien diferenciados -y dónde aplica cada uno

El debate sobre la repatriación suele mezclar tres motivos completamente distintos. Quien no los separe mentalmente, tomará decisiones erróneas para su infraestructura.

Primer impulsor: GPU e inferencia de IA. La FinOps Foundation estima que entre el 80 y el 90 % del gasto en cloud para IA corresponde a la fase de inferencia, no al entrenamiento. En operación continua, la utilización de GPU ronda solo el 15-30 %, según las mismas fuentes. Quien infiere 24/7 paga una prima en la nube por capacidad infrautilizada. Aquí, un clúster propio de GPU se vuelve económicamente atractivo.

Segundo impulsor: cumplimiento normativo y soberanía de datos. Según el Bitkom Cloud Report, el 64 % de los usuarios de cloud se sienten presionados por las políticas del gobierno estadounidense para cambiar de estrategia, y el 85 % considera que Alemania depende demasiado de EE. UU. Gartner acuña el término *geopatriación*: la migración a entornos soberanos o locales. El impulsor es político-regulatorio, no puramente económico.

Tercer impulsor: gravedad de los datos y latencia. Cuando grandes volúmenes de datos generan una atracción física, el *egress* en la nube se encarece más que operar en el lugar donde residen los datos. Pipelines que mueven terabytes regresan al origen de los datos.

Qué tipos de cargas de trabajo valen la pena – y cuáles no

Basándose en estos tres factores, se puede establecer una matriz clara. La regla general: lo que funciona de forma constante, es crítico desde el punto de vista regulatorio o maneja grandes volúmenes de datos en movimiento, es candidato para el regreso. Lo que fluctúa, es pequeño y está libre de regulaciones, es mejor que se quede en la nube.

Vale la pena en general: Inferencia de IA en ejecución constante (la utilización de GPU en el propio rack es económicamente relevante a partir de un 60 % de carga continua), bases de datos críticas para el cumplimiento con requisitos de procesamiento en la región DACH y pasos de pipelines intensivos en datos, donde los costes de salida de la nube superan los de operación on-premise.

No vale la pena: Frontends web fluctuantes, donde se mantiene la ventaja de escalabilidad de la nube. Servicios pequeños sin regulación, en los que los costes de migración superan el ahorro en tiempo de ejecución. Servicios fuertemente nativos de la nube vinculados a servicios gestionados propietarios como AWS Lambda o Kinesis – aquí, el reingeniería se come el supuesto ahorro.

Qué se queda atascado técnicamente al revertir la migración

La decisión es solo la mitad del trabajo. Lo que los arquitectos suelen subestimar son los costes técnicos que a menudo faltan en el caso de negocio.

Servicios nativos de la nube como Lambda, Kinesis o BigQuery son decisiones arquitectónicas, no productos intercambiables. Quien los trae de vuelta debe reconstruirlos con equivalentes de código abierto como OpenWhisk, Kafka o Trino. Esto consume tiempo de ingeniería. El nuevo sistema rara vez es funcionalmente idéntico al 100 %. Los bloqueos por licencias de los servicios gestionados son la razón más común por la que las cuentas se disparan una vez que se desvanece la euforia inicial.

Además, están la observabilidad, la latencia de red y almacenamiento, y la brecha de habilidades entre las operaciones nativas de la nube y las on-premise. Un equipo que ha gestionado Infrastructure-as-Code en la nube durante tres años no tiene por qué ser capaz de trasladar módulos de Terraform a bare metal. Esto no es un argumento en contra de la repatriación, sino un factor que debe incluirse en el cálculo de rentabilidad.

Cómo deciden ahora los arquitectos – sin reflejos de moda

El marco de decisión claro se basa en tres preguntas por carga de trabajo: ¿Qué tan constante es la carga? ¿Qué tan fuerte es la relación con los datos locales? ¿Cuán alta es la presión regulatoria? Quien responda «alta» a las tres, tiene un candidato para la repatriación. Con dos «no», la nube sigue siendo la opción correcta.

El cálculo: una instancia reservada de GPU on-premise resulta más rentable que una bajo demanda en la nube para inferencia 24/7 a partir de un 60 % de utilización en un horizonte de TCO de 18 a 36 meses. Por debajo de ese umbral, la nube sigue siendo lo suficientemente elástica para absorber picos de carga sin sobrecapacidad. La decisión, por tanto, se toma matemáticamente, no de forma ideológica – y eso es precisamente lo que la hace operable.

Quien ahora revierta una carga de trabajo debería considerarla como un piloto, no como un modelo para todo. Una repatriación exitosa de un pipeline de inferencia demuestra rentabilidad, pero no se traslada automáticamente al frontend web. Ser selectivo es disciplina, no indecisión.

Preguntas frecuentes

Más del MBF Media Netzwerk