Cómo prepararse para una migración de nube a nube

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Pues sí. Está ocurriendo. Plantéate integrarlo en tu estrategia global para la nube para que el proceso resulte menos complicado.

¿Qué tienen en común los siguientes elementos? Los salmones, los gansos canadienses, las mariposas monarca y las aplicaciones.

Si has adivinado que todas estas cosas migran de un lugar a otro, puedes felicitarte.

Ahora bien, cuando hablamos de migración a la nube, normalmente nos referimos a pasar de una infraestructura local a otra externa. Y con razón. Hay muchos datos (incluidos los nuestros) que indican un aumento en la adopción de la nube pública. De lo que casi nunca hablamos es de la migración que se produce en sentido inverso. Ya puedo oír los gritos de «¡Herejía!», pero seamos realistas: ocurre, y con más frecuencia de lo que se podría pensar.

Por ejemplo:

El 42 % de los encuestados que adoptaron una IaaS pública en producción indicaron que «tienen intención de migrar desde su estrategia actual, ya sea en los próximos cuatro años o como un proceso continuo». El 70 % de ellos «preveían migrar a una nube híbrida en lugar de pasarse exclusivamente a una solución de nube privada».

¿El motivo? El factor más habitual fue la reducción de costes (67 %), seguido de la seguridad y la estabilidad. Así lo demuestran casos como este, sobre la migración de Pubmatic de la nube pública a la privada. Los costes fueron un factor decisivo.

Pero otros están migrando en la dirección opuesta, como todos hemos oído decir. Y mucho. El 57 % de quienes utilizan una plataforma IaaS privada «tiene intención de migrar a una nube pública o híbrida, y el 77 % de esos encuestados indica que tiene previsto adoptar un enfoque híbrido.»

¿Sus motivos? La escalabilidad (71 %), seguida de cerca por la flexibilidad. Los costes quedaron en tercer lugar, mencionados por el 50 % de los encuestados.

La escalabilidad lleva a las empresas a la nube pública, mientras que los costes a largo plazo parecen hacer que vuelvan a una nube privada.

La realidad es que la mayoría de las organizaciones no trabajan exclusivamente con la «nube pública» ni únicamente con la «nube privada». Utilizan varias nubes, incluso después de trasladar aplicaciones de un entorno a otro. Esto puede comprobarse analizando las tendencias de desarrollo, como las recogidas por Cap Gemini en su informe «Cloud Native Comes of Age» en el que se señalaba que «Una sexta parte (15 %) de las nuevas aplicaciones de las empresas encuestadas se desarrolla actualmente en un entorno nativo de la nube».

Ahora bien, si el 15 % son nativas de la nube, eso implica que el 85 % restante no lo son. Probablemente, entre estas últimas se incluyan las aplicaciones para sistemas mainframe. Y las aplicaciones cliente-servidor. Y las aplicaciones web de tres capas. Ah, y también los microservicios en entornos de contenedores.

La empresa moderna no solo opera en múltiples nubes, sino que también cuenta con arquitecturas de aplicaciones de distintas generaciones.

Esto significa que es bastante probable que migre algún tipo de aplicación de un entorno local (privado) a uno externo (público), o viceversa, porque hay más aplicaciones de este tipo que aplicaciones nativas de la nube. Por tanto, es importante incorporar esta premisa a su estrategia de nube. En otras palabras, debe saber qué puede hacer de antemano para que el proceso (quizá inevitable) resulte menos complicado.

Preparación para la migración entre nubes

Una de las primeras cosas que debes tener en cuenta es la vida útil prevista de la aplicación que vas a trasladar. Si va a utilizarse a largo plazo, será candidata a una futura migración de nube a nube. Si no es así —porque se trata de una aplicación promocional, de marketing o vinculada a un evento—, puedes saltar directamente al final de esta lista y desplegarla.

Ahora que has determinado que la aplicación tendrá una vida útil más larga, debes pensar en cómo vas a escalarla y protegerla.

La respuesta rápida (y sencilla), si la aplicación es nativa de la nube, es: «Usaremos los servicios del proveedor de la nube». Es una opción válida, al igual que «usaremos lo de siempre» también lo es si la aplicación va a alojarse en una nube privada local. Sin embargo, ambas opciones conllevan el riesgo potencial de que, más adelante, no pueda migrar fácilmente los servicios o las políticas de una nube a otra. Es hora de analizar detenidamente qué utiliza actualmente para garantizar la escalabilidad y la seguridad, y determinar si esos servicios de aplicaciones pueden migrar junto con su aplicación en ambas direcciones.

Dado que las empresas utilizan una media de 16 servicios de aplicaciones para ofrecer y proteger sus aplicaciones, este es un ámbito que puede dificultar considerablemente su capacidad para dar soporte a aplicaciones que podrían migrar, por no hablar de hacerlo en un entorno multinube. Tenga en cuenta que algunos de esos 16 servicios deberán ser nativos de la nube. Básicamente, si considera que su ruta de datos está compuesta por servicios de aplicaciones corporativos y compartidos, así como por servicios específicos de cada aplicación, podrá empezar a ver que la división arquitectónica coincide en gran medida con la línea que trazan los proveedores de nube pública en la capa de infraestructura. No es una división perfecta, pero sí proporciona una separación lógica que sirve de guía para determinar qué servicios deben ser «multinube» y para cuáles puede recurrir a servicios nativos de la nube o a servicios tradicionales de centros de datos.

Cuanto mayor sea la coherencia entre los servicios de aplicaciones que utiliza en las distintas nubes, más fácil será migrar de una a otra (o entre tres, cuatro o más), ya que habrá menos elementos que le condicionen. Este enfoque ofrece además la ventaja de ampliar las iniciativas de automatización a la nube pública y liberar a la empresa, al menos, de los costes operativos asociados al mantenimiento de equipos y procedimientos operativos independientes.

La nube era inevitable. La multinube también lo es. Esto significa que, en última instancia, habrá migraciones entre ellas. Prestar atención a las dependencias y utilizar servicios de aplicaciones entre nubes antes de tomar la decisión inicial sobre dónde implementar la aplicación puede hacer que el proceso resulte menos complicado.

Incluya, al menos, la posibilidad de migrar de una nube a otra en su estrategia general de nube. Estar preparado puede evitarle una migración complicada (y costosa) más adelante.

Sobre el autor

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.

Más artículos de Lori Mac Vittie