Según pública el portal ciospain.es
Las atractivas ventajas de utilizar servicios propietarios nativos de la nube tienen un precio: la dependencia del proveedor. Aquí algunas formas en que los CIO pueden planificar eficazmente sin quedarse atascados.
Una vez que las empresas se comprometen a ejecutar aplicaciones críticas para el negocio en la nube, rara vez cambian de proveedor. Una razón de peso: a menudo están atrapadas en el ecosistema del proveedor elegido. El coste de la migración es sencillamente demasiado alto, afirma Sid Nag, Vicepresidente de servicios y tecnología en la nube de Gartner. «Pero si se planifica correctamente, no debería ser necesario trasladar las aplicaciones», afirma.
Pablo Del Giudice, socio del estudio de Cloudops y Ciberseguridad de la firma de servicios profesionales Globant, añade que la migración es posible si se posiciona correctamente la organización. Y él y su equipo lo han hecho con éxito. «La clave está en adoptar estratégicamente plataformas y marcos abiertos, relegando al proveedor de la nube al papel de capa de infraestructura«, afirma. Aunque este enfoque tiene una curva de aprendizaje más pronunciada, produce resultados más favorables a medio y largo plazo, añade. «La clave es incorporar a un arquitecto de software neutro en cuanto a la plataforma que pueda delimitar las fronteras del negocio y crear soluciones que estén menos entrelazadas con un proveedor específico».
Jamie Holcombe, CIO de la Oficina de Patentes y Marcas de Estados Unidos, tiene una opinión algo más matizada: quiere mantener abiertas sus opciones para mover aplicaciones entre proveedores de servicios en la nube, y realiza estudios de mercado con todos los principales. Pero para ello es necesario planificar desde el principio, antes de trasladar una aplicación a la nube por primera vez.
Vea también: 7 pasos para adoptar una estrategia minorista omnicanal para tu negocio
Minimizar los riesgos de bloqueo
Hay que sopesar cuidadosamente las ventajas y desventajas a la hora de aprovechar los servicios nativos de la nube de cada proveedor. «Si decide no utilizar los servicios nativos de un proveedor de la nube para seguir siendo agnóstico, perderá muchas de las métricas del caso de negocio que son ‘mejores, más baratas, más rápidas‘», dice Holcombe. «Ser agnóstico tiene un coste, al igual que la dependencia de un proveedor».
Del Giudice divide el bloqueo del proveedor de la nube en tres formas. El bloqueo de plataforma se produce cuando se tiene una configuración completa de la base de la nube (agrupación de recursos, políticas, RBAC, conectividad híbrida, supervisión, cumplimiento, etc.) que dificulta la migración a otra plataforma debido a la complejidad de recrear todo eso en una nueva plataforma.
El bloqueo arquitectónico se produce cuando la aplicación depende de varios servicios gestionados del proveedor de la nube. En este caso, hay que rediseñar la aplicación antes de poder migrarla.
Y luego está el bloqueo legal, cuando uno se ha comprometido a un acuerdo de servicio empresarial durante un periodo de tiempo predeterminado. «Estos compromisos son difíciles de rescindir y dificultan la migración», afirma.
A veces, la dependencia de un proveedor se produce a pesar de los esfuerzos del CIO por evitarla. La actividad de fusiones y adquisiciones a menudo deja a las organizaciones con arquitecturas multicloud, dice Nag, y aunque los CIO suelen querer consolidar, el coste es a menudo demasiado alto para justificarlo. La mayoría de las veces, esos CIO deciden mantener el modelo multicloud porque están bloqueados. «Están atrapados, a lo grande», dice Nag.
Pero las organizaciones pueden tener buenas razones para migrar entre proveedores de IaaS, a pesar de los obstáculos, dice Del Giudice. Las más comunes son obtener una mejor relación de costes entre valor y OPEX para aprovechar un descuento agresivo de un proveedor de servicios en nube de la competencia, y aprovechar una arquitectura multicloud cuando la organización quiere mejorar la fiabilidad.
Planificar con antelación posibles migraciones futuras
Sin embargo, el deseo de trasladar aplicaciones clave entre proveedores de nube, lo que Gartner denomina «repatriación a la nube«, suele ser el resultado de una mala planificación, afirma Nag. Observa este fenómeno en los despliegues en la nube, pero también cuando las organizaciones deciden utilizar middleware y herramientas de desarrollo nativas de la nube a precios asequibles con la intención de volver a trasladar la aplicación a una nube privada local una vez terminada.
Recomienda contratar los servicios de un MSP o integrador de sistemas para realizar la planificación y asegurarse de que se eligen las aplicaciones adecuadas para trasladar a la nube. «Eso es importante, porque una vez que lo has trasladado, estás aceptando quedar atrapado en la plataforma».
La empresa de servicios financieros USAA eligió cuidadosamente cuál de sus cuatro proveedores de servicios en la nube alojaría cada una de sus cargas de trabajo y aplicaciones empresariales habituales. «Alineamos a los proveedores de nube con los servicios empresariales o técnicos en los que son más competentes», afirma Jeff Calusinski, vicepresidente senior y CTO.
La estrategia multicloud de la institución se basa en lo que él denomina sus principios «abiertos por diseño». «Utilizamos estándares abiertos, cuando existen, reduciendo así el potencial de dependencia de un proveedor», afirma, pero admite que algunos servicios nativos ofrecen una propuesta de valor convincente que debe sopesarse frente al potencial de dependencia.
Además, los principios de diseño abierto tienen un límite en lo que respecta a la dependencia de un proveedor, afirma Nag, porque incluso cuando se utilizan servicios modernos, la implementación en cada plataforma difiere. Por ejemplo, el sustrato EC2 de Amazon hace lo mismo que GCP de Google, pero una aplicación que se ejecuta en EC2 no funcionará en GCP sin un costoso reajuste. Y aunque Kubernetes es un estándar del sector, sus implementaciones, como Azure Communication Services y Google Kubernetes Engine, no funcionan de forma idéntica.
«Sin embargo, han surgido algunas capas de abstracción entre los proveedores de la nube y las aplicaciones«, dice Del Giudice, y esas pueden simplificar las migraciones incluso si se utilizan servicios nativos del proveedor de la nube. «Estos servicios, como pub/sub, invocación de servicios, gestión de secretos, gestión de estados, etc., abstraen los componentes de la aplicación independientemente del proveedor de la nube». Así que al final, dice: «tus opciones permanecen abiertas, pero todavía será necesario llevar a cabo algunas actividades para pasar de un proveedor de nube a otro».
Los requisitos de datos es otra área que necesita una planificación cuidadosa. «Trasladar una aplicación entre nubes es caro porque también hay que trasladar los datos asociados, y la salida de datos es un ejercicio muy costoso», afirma Nag.
Así que planifíquelo de antemano, añade Holcombe. «No firme con un proveedor a menos que tenga un acuerdo para saber cómo sacar sus datos y cómo replicar esos servicios de software en otro lugar», dice.
Pero incluso si disponer de una estrategia ETL adecuada puede garantizarle que puede mover datos entre proveedores de forma estructurada y en un formato utilizable, dice Del Giudice, esos planes a menudo son inexistentes. «Aunque los proveedores de servicios en la nube hacen hincapié en el uso de plataformas abiertas y protocolos de acceso a los datos, que en teoría son fáciles de usar, a menudo se pasan por alto las limitaciones de la red y la seguridad para acceder a estos servicios«, afirma.
A la hora de decidir qué servicios nativos de la nube utilizar, a veces las organizaciones no tienen elección. La seguridad es un buen ejemplo. «Si sus necesidades de seguridad son altas, la ciberseguridad genérica puede no ser suficiente», dice Holcombe. Cuanto más específicas sean sus necesidades, más rígido será el servicio en términos de dependencia del proveedor. Y las empresas con operaciones intensivas en datos se enfrentan a problemas tanto de almacenamiento como de ancho de banda, afirma, añadiendo que los proveedores de PaaS e IaaS utilizan ambos como diferenciadores competitivos. «Si se trata de aprovechar el alto rendimiento con ambos, es complicado», afirma.
Holcombe sigue lo que él llama el enfoque del «abeto negro» para las personalizaciones que aprovechan los servicios nativos. Al igual que el abeto negro mantiene sus ramas cerca del tronco, la USPTO mantiene sus personalizaciones lo más «delgadas» posible, afirma. Esto no sólo reduce la dependencia, sino que garantiza que la organización no tenga que cargar con lo que él denomina una ruta de versiones sobrecargada y costosa.
Calusinski adopta un enfoque similar. «La mayoría de las opciones PaaS tienen una capacidad básica y un conjunto de capacidades auxiliares», afirma. Nosotros limitamos el número de capacidades auxiliares y nos centramos en el núcleo».
Lo mismo ocurre con las aplicaciones basadas en SaaS, añade Holcombe, una máxima que su equipo siguió tras pasar de Remedy a ServiceNow y Salesforce. «No personalices mucho y sé capaz de cambiar cuando lo necesites», afirma. «No estamos en deuda con ellos y ha sido una buena plataforma estructural. Pero si está sobrecargada de optimizaciones, estás atascado».
Esta vez, sin embargo, Calusinski enfoca las cosas de otra manera. «Con las plataformas SaaS, adoptamos tanto de la plataforma como sea posible porque como negocio no vemos suficiente diferenciación [en] las capacidades del proveedor, y la probabilidad de cambio es baja».
Vea también: Principales tendencias que definirán la evolución de la nube en 2024
Prevenir posibles problemas de migración
Está claro que la migración entre proveedores de nube presenta innumerables retos. Entre ellos se encuentran los problemas de compatibilidad, los problemas de seguridad, la necesidad de una amplia reconfiguración de las aplicaciones y la gestión de imágenes basadas en sistemas operativos antiguos y pilas tecnológicas obsoletas que no se integrarán a la perfección en un nuevo entorno. La transferencia de grandes cantidades de datos también puede provocar tiempos de inactividad y posibles pérdidas de datos, por lo que es crucial garantizar un rendimiento y una escalabilidad constantes durante la transición. «Gestionar estos retos requiere una planificación meticulosa, pruebas exhaustivas y una estrategia de reversión bien definida», afirma Del Giudice.
Además, entre los principales puntos de fracaso de las migraciones a PaaS se encuentran el no cumplir las expectativas de costes o de negocio, la falta de recursos cualificados, la falta de estandarización y de fundamentos de seguridad, el no aprovechar las funciones nativas de la nube, los problemas de seguridad y cumplimiento de normativas y la no adopción de un modelo operativo en la nube.
Del Giudice recomienda un planteamiento en seis pasos para cualquier organización que esté considerando migrar entre proveedores de nube. En primer lugar, evalúe el modelo de suscripción para asegurarse de que se alinea con sus objetivos de ROI. Adopte un enfoque de nube híbrida. Utilice soluciones agnósticas a la nube siempre que sea posible para mantener abiertas sus opciones de migración en el futuro. Cuando utilice servicios nativos en la nube, diseñe sus aplicaciones con capas de abstracción. Invierta en estrategias de planificación, pruebas y copias de seguridad de la migración de datos para mitigar los riesgos. Y revise y ajuste los acuerdos de licencia según sea necesario.
Sopesar cuidadosamente las opciones
Siempre hay que tener en cuenta los costes de transición y la propiedad de los datos a la hora de considerar cualquier transición de proveedor de nube, dice Calusinski.
Y cuando se trata de encontrar un equilibrio entre el uso de servicios en la nube nativos que aumentan la dependencia y la agnóstica, no hay una respuesta correcta, dice Holcombe, sólo una óptima para su organización y su misión. La cuestión, dice, es si la aplicación basada en la nube se alinea con la misión de su organización y ofrece el mejor valor para lograrlo con el tiempo. «Si tienes una infraestructura de costes excesivamente compleja, no puedes cambiar cuando cambia el modelo de negocio», dice, y añade que mantengas tus opciones abiertas como lo ha hecho la USPTO con una arquitectura multicloud por diseño. «Mi razón principal era que hubiera competencia entre los proveedores de servicios», afirma.
A la hora de planificar una migración a la nube, es importante tener en cuenta los modelos de precios, dice Del Giudice. «Explore posibles planes de ahorro y tenga en cuenta los costes de transferencia de datos», afirma. «Este enfoque es vital para evitar picos inesperados en los gastos operativos de la nube y garantizar la alineación con sus limitaciones presupuestarias». Al ejecutar una estrategia de migración, considere otros dos factores, añade. En primer lugar, ¿qué servicios, como microservicios o serverless, están disponibles en los proveedores de servicios en la nube para facilitar la migración? Tendrá que decidir entre utilizar soluciones personalizadas o servicios gestionados del proveedor de la nube, que generan riesgos de dependencia del proveedor. En segundo lugar, el proveedor de la nube puede ofrecer programas de incentivos para migrar aplicaciones, con descuentos que pueden ser sustanciales para grandes migraciones.
Por su naturaleza, las migraciones a la nube pueden ser arriesgadas. Pero los CIO que planifican con antelación y son lo suficientemente persistentes como para pasar por este proceso pueden ver servicios en la nube y modelos de precios más rentables, una mejor escalabilidad y asignación de recursos, y un mayor rendimiento y capacidad de respuesta. «La reducción de la dependencia de un proveedor fomenta una mayor agilidad e innovación», afirma Del Giudice. «En última instancia, la migración a la nube puede impulsar una mayor competitividad, innovación y eficiencia».
