Los equipos informáticos actuales tienen mucho trabajo. Aunque los datos no estructurados crecen un 35% al año, los equipos de TI responsables de esos datos ven cómo se reducen las plantillas, los presupuestos y los centros de datos (puede que esos centros de datos no se reduzcan, pero desde luego no son más grandes). Este es el cuarto de una serie de artículos en los que se han sopesado los retos y las oportunidades, así como las ventajas y los inconvenientes, que los estrategas, gestores y administradores de las empresas deben tener en cuenta a la hora de trasladar las cargas de trabajo a la nube.
En entradas anteriores, hemos repasado algunos de los factores comunes que las empresas deben tener en cuenta a la hora de decidir si integrar servicios en la nube y cómo hacerlo. También hemos analizado los pros y los contras de las distintas estrategias y cómo sopesarlos para determinar el mejor camino a seguir para su empresa.
En las próximas entradas de la serie, analizaremos algunas estrategias habituales para migrar datos a la nube, en el contexto de cómo gestionar (y minimizar) los riesgos.
Antes de empezar, es importante tener en cuenta que algunas empresas son intrínsecamente más tolerantes al riesgo que otras, y que usted debe determinar lo que su empresa considera un riesgo aceptable frente a un riesgo inaceptable.
En ello influye la naturaleza de su empresa y los factores asociados, por ejemplo, si tiene o no plazos reglamentarios o información personal protegida (IPP) que deba salvaguardarse. En algunos casos, las consecuencias de no cumplir los plazos reglamentarios o de filtrar información personal protegida son enormes.
Imagínese una compañía de seguros que viola inadvertidamente las leyes HIPAA: el efecto posterior puede implicar sanciones financieras, sanciones civiles, publicidad negativa y posiblemente incluso sanciones penales. Las empresas financieras, sanitarias, de seguros y otras muy reguladas tendrán una tolerancia al riesgo mucho menor cuando se trate de cambios en los sistemas, el software y la arquitectura, a la par que una migración a la nube.
La perspectiva de la computación y el almacenamiento en la nube presenta un interesante dilema para muchos administradores de sistemas empresariales: las presiones contrapuestas de apoyar la necesidad de la empresa de innovar para el futuro, y la necesidad de garantizar que los servicios y flujos de trabajo existentes permanezcan en línea para sostener el negocio hoy.
El éxito de una estrategia de adopción de la nube requiere un cuidadoso equilibrio: asumir riesgos calculados para adoptar nuevas plataformas y tecnologías que aporten crecimiento e innovación, al tiempo que se mantienen las luces encendidas y la empresa en funcionamiento.
Estrategias poco realistas
Antes de ver lo que hay que hacer, hablemos de lo que no que hacer. La primera de ellas: no corras riesgos innecesarios con las aplicaciones que hacen funcionar tu empresa.
Refactorización de grandes aplicaciones
Muchas organizaciones considerarán al menos la posibilidad de refactorizar sus cargas de trabajo críticas basadas en archivos a una arquitectura nativa de la nube. Esto implica reescribir la aplicación para aprovechar el almacenamiento de objetos en lugar de los datos de archivos. Es cierto que este enfoque tiene algunas ventajas a largo plazo, como una mayor flexibilidad en las operaciones en la nube y una integración más estrecha con algunos de los servicios nativos de la nube específicos del proveedor disponibles en AWS y Azure, pero también hay que tener en cuenta algunos inconvenientes importantes.
El coste inicial de esta estrategia es elevado. Dependiendo de su tamaño y complejidad, el coste de conversión puede oscilar entre 3 y 30 millones de dólares para reescribir una sola aplicación.
Así es: más de 30 millones de dólares por una aplicación. Y eso suponiendo que tenga éxito.
Lo que nos lleva a la otra cara de la moneda: el riesgo de un fallo a gran escala no sólo es muy alto, sino que, en el peor de los casos, puede paralizar toda la empresa mientras se diagnostica y corrige el problema. Y eso es sólo un fallo: ¿cuántos de esos fallos puede tolerar su organización a lo largo de los más de dos años que puede tardar el proyecto en completarse?
Reconocer el riesgo en su contexto
Hay situaciones legítimas en las que la situación anterior podría considerarse un riesgo aceptable. Pensemos en lo siguiente:
Imagina que una de tus aplicaciones críticas para el negocio, dependiente de archivos, ha sido adquirida por un nuevo proveedor que ha anunciado que se retirará progresivamente y dejará de recibir soporte a partir de una fecha determinada. De repente, te encuentras en una situación en la que tienes que hacer lo siguiente algo cualquiera de las cuales podría acabar en fracaso y perturbación de la actividad empresarial.
Tal vez su organización depende de una aplicación de terceros cuyo proveedor ha anunciado que la próxima versión será nativa en la nube". Independientemente de lo que usted y su organización piensen sobre ese anuncio, el riesgo está ahí de todos modos, y depende de usted minimizarlo y mitigarlo en lugar de tratar de evitarlo.
Algunas grandes transformaciones empresariales también pueden compensar el riesgo de pasar a la nube. Si se está llevando a cabo un cambio de marca importante o un pivotaje de los modelos de negocio, entonces a) ya se corre un alto riesgo de sufrir otros fallos, pero b) tal vez se puedan salvar algunos de los datos anteriores que históricamente se conservaban on-prem pasándose a la nube.
En estos casos, hay suficientes factores externos que pesan más que si la migración a la nube se considera un riesgo aceptable de asumir.
Los que tengan edad suficiente para recordar el efecto 2000 tienen un ejemplo perfecto de factores externos que cambian la ecuación del "riesgo aceptable": el riesgo de no hacer nada era mayor que el de tomar medidas para rediseñar, migrar o sustituir incluso las aplicaciones heredadas de misión crítica.
Sin embargo, hay que reconocer que la mayoría de ustedes no se encuentran en esta situación. Cuando se trata de refactorizar aplicaciones críticas para el negocio, muchas organizaciones sopesan la baja probabilidad de éxito frente al alto coste del fracaso, y concluyen con razón que tiene más sentido dejar la aplicación donde está y esperar a que la nube se ponga al día.
Exagerar
Otra estrategia poco realista en cualquier viaje a la nube es intentar avanzar demasiado rápido. No solo se estropeará la aplicación, sino que se quedará en agua de borrajas hasta que pueda volver a la implementación local o arreglarla en la nube.
Si no va más despacio y se toma el tiempo necesario para evaluar y probar a fondo sus aplicaciones, se arriesga a sufrir problemas de latencia tras la migración, errores de datos y deficiencias de rendimiento. A partir de un determinado umbral, estos problemas pueden convertirse en un fracaso total de la migración. El riesgo de que se produzcan estos errores disminuye significativamente cuando se dedica el tiempo y el esfuerzo necesarios para una transición sin problemas de on-prem a la nube.
Entonces, ¿cuáles son las estrategias realistas para trasladar cargas de trabajo a la nube? Esté atento a nuestra próxima entrega para ver qué enfoques recomendamos.