La modernización del Data Center no es un destino, es un cambio en el modelo operativo

Un rack de servidores zumbando en un centro de datos ubicado en un sótano. Consumo eléctrico las 24 horas del día. Una utilización que apenas ronda el 15%. Una factura anual de seis cifras solo para mantenerlo funcionando. Es un escenario que se repite en departamentos de TI de todo el mundo y, según un veterano arquitecto de Azure, también es la razón por la que tantas empresas se lanzan hacia una estrategia de nube que en realidad no les conviene.

«Después de casi 18 años diseñando migraciones a Azure —para desde gigantes de telecomunicaciones hasta empresas energéticas y clientes del sector público—, puedo decirles esto con total confianza: el discurso de ‘saquen todo y muévanse 100% a la nube’ que han escuchado cientos de veces suele ser un mal consejo», afirma Mahesh Kale, Azure Cloud Architect en Tata Consultancy Services. «La respuesta correcta casi siempre es más interesante, y más estratégica, que eso.»

El mito de la migración de todo o nada

Kale rastrea el origen del problema en cómo, con el paso de los años, la «transformación digital» se redujo a una única instrucción. «En algún momento, la ‘transformación digital’ se simplificó hasta convertirse en ‘mueve todo a la nube, de inmediato'», señala. Y ha visto las consecuencias una y otra vez: «He visto organizaciones perseguir ese discurso, solo para terminar con costos de egreso de datos descontrolados, problemas de latencia en cargas de trabajo intensivas en datos, y un equipo de finanzas haciendo preguntas incómodas sobre la factura de la nube tres meses después.»

La distinción que él plantea es sutil, pero considera que es esencial. «La modernización no es un destino, es un cambio de modelo operativo», explica. «El objetivo no es ‘la nube por la nube misma’, sino ubicar cada carga de trabajo donde rinda mejor, cueste menos y se mantenga en cumplimiento normativo. A veces eso es Azure. A veces es un esquema híbrido. A veces una carga de trabajo realmente pertenece en las instalaciones propias un poco más de tiempo, y eso está bien.»

Esa lógica, sostiene, explica por qué los esquemas híbridos dejaron de considerarse una solución de compromiso. «Por eso mismo, las arquitecturas híbridas se han convertido en la opción predeterminada y madura, en lugar de ser la opción de compromiso», apunta Kale. «Las empresas obtienen libertad para ubicar cargas de trabajo según costo, rendimiento y cumplimiento normativo, sin el bloqueo con un proveedor que implica apostarlo todo a un solo modelo.»

Paso uno: un inventario honesto

Antes de tocar cualquier herramienta de migración, Kale insiste en hacer un recuento real de lo que efectivamente está funcionando. «Antes de tocar una sola herramienta de migración, hagan una evaluación real de las cargas de trabajo», dice. «No una hoja de cálculo que alguien llenó hace tres años, sino un inventario real y actualizado de qué está corriendo, de qué depende y cuánto está costando en realidad.»

Saltarse ese paso, afirma, es la razón más común por la que los proyectos fracasan. «He perdido la cuenta de cuántos ‘proyectos de modernización’ fracasan no porque la tecnología estuviera mal elegida, sino porque nadie mapeó las dependencias correctamente desde el principio», explica Kale. «Migran una aplicación y descubren que en secreto se comunicaba con otros tres sistemas heredados que nadie había documentado. De repente, tu migración de seis semanas se convierte en un simulacro de incendio de seis meses.»

Paso dos: construir la landing zone antes que nada

La fase que la mayoría de los equipos se siente tentado a saltarse es, según Kale, también la que determina si todo el proyecto tendrá éxito. «Una landing zone de Azure adecuada —tu red, identidad, línea base de seguridad, políticas de gobernanza y monitoreo— necesita existir antes de que lleguen las cargas de trabajo. No después.»

Basándose en proyectos que van desde migraciones de SAP hasta transiciones de Citrix VDI a Azure Virtual Desktop, ha observado un patrón constante. «En todos los casos, los proyectos que avanzaron sin contratiempos fueron aquellos donde la capa fundamental —RBAC, MFA, segmentación de red, identidad híbrida— quedó asegurada desde el principio», señala. «Los que tuvieron dificultades intentaron añadir la seguridad después. Ajustar la gobernanza a posteriori siempre es más doloroso que diseñarla desde el primer día.»

Paso tres: migrar en oleadas, no de golpe

Kale es enfático en que la secuencia importa tanto como la estrategia. «Dividan su migración en oleadas lógicas basadas en riesgo y dependencia, no en orden alfabético», aconseja. «Las cargas de trabajo de bajo riesgo y baja dependencia van primero: así construyen confianza y perfeccionan su metodología. Las aplicaciones de alto riesgo y críticas para el negocio —su entorno de SAP, sus sistemas financieros centrales— van después, una vez que el equipo ya tiene experiencia acumulada gracias a las victorias más sencillas.»

Sobre la modernización de aplicaciones en sí, ve un argumento claro a favor de los estándares abiertos. «Los contenedores y Kubernetes merecen una consideración seria aquí, no como una tendencia que perseguir, sino porque realmente reducen la dependencia de un proveedor y les dan movilidad de cargas de trabajo si alguna vez necesitan cambiar de proveedor o repatriar algo», afirma. «He visto organizaciones pasar meses desenredando dependencias propietarias de servicios en la nube durante una repatriación parcial; haber usado estándares abiertos desde el inicio les habría ahorrado ese dolor por completo.»

Paso cuatro: la recuperación ante desastres no es opcional

Quizás la advertencia más contundente en el relato de Kale tiene que ver con lo que ocurre mucho después de que una migración se declara exitosa. «He visto migraciones ejecutadas de manera impecable desmoronarse dieciocho meses después porque nadie construyó una estrategia real de recuperación ante desastres para el nuevo entorno», dice. Herramientas como Azure Site Recovery y las estrategias de respaldo hacia Azure Storage, subraya, «no son extras opcionales: son la diferencia entre un mal día y un evento que puede acabar con el negocio.»

Y probar el plan, dice, tiene que significar realmente probarlo. «Prueben su failover. Pruébenlo de verdad, no solo documenten que ‘planean hacerlo'», señala Kale. «He realizado más simulacros de recuperación ante desastres de los que puedo contar, y cada uno de ellos nos enseñó algo que la fase de diseño había pasado por alto.»

Paso cinco: demostrar el retorno de inversión, constantemente

El respaldo ejecutivo, según la experiencia de Kale, se desvanece cuando nadie está midiendo los resultados. «Los proyectos de modernización pierden el respaldo ejecutivo cuando nadie está midiendo el valor para el negocio», afirma. «Definan sus indicadores clave desde el principio —costo por carga de trabajo, velocidad de despliegue, reducción de incidentes, lo que sea relevante para su negocio— y repórtenlos de manera constante.» Y añade un dato para respaldar lo que está en juego: las organizaciones que operan con infraestructura moderna, dice, «despliegan nuevas capacidades entre un 40% y un 60% más rápido que aquellas que siguen atadas a sistemas heredados, y ese es el tipo de cifra que mantiene vivo tu presupuesto en el próximo año fiscal.»

La brecha de talento que nadie quiere abordar

Pese a todo el énfasis puesto en la arquitectura y las herramientas, Kale vuelve a una conclusión menos cómoda. «El éxito de la modernización depende más de las habilidades de tu equipo que del proveedor que elijas», afirma. «Puedes comprar las mejores herramientas del mundo, pero si tu equipo no entiende la nube híbrida, la automatización y las operaciones multicloud, la ejecución se desmorona.» Con la mayoría de las organizaciones operando hoy en múltiples nubes, agrega, «esa complejidad exige conjuntos de habilidades que muchos equipos de TI simplemente no han desarrollado todavía.»

Su recomendación es directa: «Antes de sentarse a ver otra demostración de un proveedor, inviertan en su gente. Certifiquen a su equipo en AZ-900, AZ-104 o AZ-305. Construyan la capacidad interna. Se paga solo con que la primera oleada de migración salga bien en lugar de salir mal.»

La conclusión

Kale se cuida de presentar la modernización como una disciplina continua y no como una meta final. «La modernización de centros de datos no se trata de perseguir una palabra de moda ni de alcanzar algún objetivo arbitrario de ‘100% nube’ para fin de año», afirma. «Se trata de construir un modelo operativo donde puedas ubicar las cargas de trabajo de manera inteligente, recuperarte de un desastre sin entrar en pánico, y demostrar valor a quienes firman los cheques.»

Habiendo liderado este tipo de transición en clientes de telecomunicaciones, finanzas, energía y sector público —desde renovaciones de Citrix VDI hasta reconstrucciones completas de continuidad de negocio y recuperación ante desastres—, no pretende que el trabajo sea glamoroso. «Rara vez es un trabajo glamoroso», admite. «Pero bien hecho, es la diferencia entre un departamento de TI que está constantemente apagando incendios y uno que realmente está impulsando el negocio hacia adelante.»

Su mensaje final está dirigido directamente a los líderes que aún esperan que aparezca la hoja de ruta perfecta. «No esperen a que aparezca la estrategia de nube ‘perfecta’ ya completamente formada», concluye Kale. «Empiecen con la evaluación de cargas de trabajo. Construyan la landing zone correctamente. Muévanse en oleadas. Prueben su plan de recuperación ante desastres como si realmente lo dijeran en serio. Las organizaciones que están ganando en esto no son las que tienen la tecnología más sofisticada: son las que hicieron primero el trabajo de base, poco glamoroso pero necesario.»

Seguiremos brindándote más información sobre este tema en las siguientes presentaciones físicas y digitales de Channel News Perú

Mantente conectado a nuestra plataforma de negocios y revista, haciendo clic aquí y suscribiéndote a nuestro newsletter para contenido de valor diario