“Primero, no hacer daño” - Hipócrates
Los equipos de TI de hoy tienen mucho que hacer. Aunque los datos no estructurados crecen un 35% por año, los equipos de TI responsables de esos datos están viendo una reducción de personal, presupuestos y centros de datos (es posible que esos centros de datos en realidad no se estén reduciendo, pero definitivamente no están creciendo). Esta es la cuarta de una serie de publicaciones que han sopesado los desafíos y oportunidades, así como los beneficios y desventajas, que los estrategas, gerentes y administradores empresariales deben afrontar cuando se trata de trasladar cargas de trabajo a la nube.
En publicaciones anteriores, analizamos algunos de los factores comunes que las empresas deben considerar al decidir si integrar los servicios en la nube y cómo hacerlo. También cubrimos los pros y los contras de diferentes estrategias y cómo compararlas entre sí para determinar el mejor camino a seguir para su empresa.
En las próximas publicaciones de la serie, analizaremos algunas estrategias comunes para migrar datos a la nube, en el contexto de cómo gestionar (y minimizar) el riesgo.
Antes de comenzar, es importante tener en cuenta que algunas empresas son inherentemente más tolerantes al riesgo que otras, y es necesario determinar qué riesgo su empresa considera aceptable o inaceptable.
Esto está influenciado por la naturaleza de su negocio y los factores asociados, por ejemplo, si tiene o no plazos regulatorios o información personal protegida (PPI) que debe salvaguardarse. En algunos casos, las consecuencias de no cumplir los plazos reglamentarios o de filtrar el IPP son enormes.
Imagine una compañía de seguros que inadvertidamente viola 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 empresas fuertemente reguladas tendrán una tolerancia mucho menor al riesgo cuando se trata de cambios de sistemas, software y arquitectura a la par de una migración a la nube.
La perspectiva de la computación y el almacenamiento en la nube presenta un enigma interesante para muchos administradores de sistemas empresariales: las presiones competitivas de respaldar la necesidad empresarial 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.
Una estrategia exitosa de adopción de la nube requiere un equilibrio cuidadoso: asumir riesgos calculados para adoptar nuevas plataformas y tecnologías que generen crecimiento e innovación, al mismo tiempo que mantengan las luces encendidas y el negocio en funcionamiento.
Estrategias poco realistas
Antes de ver qué hacer, hablemos de qué no hacer. El primero de ellos: no corra riesgos innecesarios cuando se trata de las aplicaciones que mantienen su negocio en funcionamiento.
Refactorización de aplicaciones grandes
Muchas organizaciones al menos considerarán 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 algunos beneficios 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 hay algunas desventajas importantes a tener en cuenta. también.
El costo inicial de esta estrategia es alto. Dependiendo de su tamaño y complejidad, es posible que tenga que afrontar un coste de conversión de 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 supone que tenga éxito.
Lo que nos lleva a la otra cara de la moneda: no sólo el riesgo de una falla a gran escala es muy alto, sino que, en el peor de los casos, puede detener todo su negocio mientras se diagnostica y corrige el problema. Y ese es solo un fracaso: ¿cuántos de ellos puede tolerar su organización durante los más de 2 años que podría tardar en completarse el proyecto?
Reconocer el riesgo en contexto
Hay situaciones legítimas en las que el escenario anterior podría considerarse un riesgo aceptable. Considera lo siguiente:
Imagine que una de sus aplicaciones dependientes de archivos, críticas para su negocio, ha sido comprada por un nuevo proveedor que ha anunciado que se eliminará gradualmente y dejará de ser compatible a partir de una fecha determinada. De repente, estás en una posición en la que tienes que hacer algo, cualquiera de los cuales podría terminar en fracaso y interrupción del negocio.
Quizás su organización dependa de una aplicación de terceros cuyo proveedor haya anunciado que la próxima versión será nativa de la nube”. Independientemente de lo que usted y su organización sientan acerca de ese anuncio, el riesgo existe independientemente y depende de usted minimizarlo y mitigarlo en lugar de tratar de evitarlo.
Algunas transformaciones empresariales más importantes también pueden compensar el riesgo de pasar a la nube. Si está realizando un gran cambio de marca o cambiando modelos de negocio, entonces a) ya corre un alto riesgo de sufrir otras fallas, pero b) tal vez pueda recuperar algunos de los datos anteriores que históricamente se mantenían en las instalaciones migrando a la nube.
En estos casos, existen suficientes factores externos que pesan más que si la migración a la nube se considera un riesgo aceptable o no.
Aquellos de ustedes que tienen edad suficiente para recordar el virus Y2K tienen un ejemplo perfecto de factores externos que cambian la ecuación del “riesgo aceptable”: uno en el que el riesgo de no hacer nada era mayor que tomar medidas para rediseñar, migrar o reemplazar incluso la misión. -aplicaciones heredadas críticas.
Sin embargo, es cierto que los escenarios anteriores no se aplican a la mayoría de ustedes. Cuando se trata de refactorizar aplicaciones críticas para el negocio, muchas organizaciones comparan la baja probabilidad de éxito con el alto costo 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. arriba.
Exagerando
Otra estrategia poco realista en cualquier viaje hacia la nube es intentar avanzar demasiado rápido. No solo romperá la aplicación, sino que estará muerto en el agua hasta que pueda volver a su implementación local o arreglarla en la nube.
Si no reduce la velocidad y se toma el tiempo necesario para evaluar y probar sus aplicaciones a fondo, corre el riesgo de sufrir problemas de latencia posteriores a la migración, errores de datos y deficiencias en el rendimiento. Por encima de cierto umbral, esto podría equivaler a 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 desde el entorno local a la nube.
Entonces, ¿cuáles son las estrategias realistas para trasladar cargas de trabajo a la nube? Estén atentos a nuestra próxima entrega para ver qué enfoques recomendamos.
James Walkenhorst es el ingeniero técnico de marketing sénior del equipo de productos de Qumulo. Ha estado trabajando en y alrededor de plataformas NAS y entornos de demostración práctica durante 15 años, y pasó los 10 años anteriores en operaciones de TI como ingeniero y gerente.
