Las 7 R de la migración a la nube: cómo elegir el método adecuado

¿Por qué 7R?

El modelo de las R no es nuevo, pero ha evolucionado significativamente a lo largo de los años. Su génesis suele atribuirse a Gartner, que ideó el modelo de las 5R en 2010. Las cinco R originales eran reubicar, refactorizar, revisar, reconstruir y reemplazar.

A medida que la nube siguió evolucionando y se migraron a ella cargas de trabajo más diversas, AWS agregó una sexta R (retirar) y, finalmente, una séptima (retener). Esta séptima R es, en efecto, un reconocimiento de que no todas las cargas de trabajo son aptas para alojarse en la nube.

Esto es lo que significa cada una de las 7R en la práctica.

1. Realojar (rehost)

El realojar se conoce a menudo como "lift and shift", y consiste en trasladar una aplicación tal como está a la nube. El realojamiento se puede realizar de varias maneras, pero a menudo implica crear máquinas virtuales basadas en la nube que imiten la infraestructura en la que se ejecuta actualmente una aplicación. Debido a que la infraestructura en la nube es similar a la infraestructura local, trasladar la aplicación a un nuevo hogar en la nube se convierte en una tarea relativamente sencilla. Por ejemplo, algunas organizaciones realojan una aplicación construyendo su infraestructura virtual en la nube y luego restaurando una copia de seguridad en la nueva infraestructura basada en la nube. Por lo general, hay algunas tareas menores posteriores a la migración, como actualizar los registros DNS para que se pueda acceder a la aplicación en su nueva ubicación.

2. Reubicar (relocate)

La segunda R, reubicar, es similar al realojar. Ambos métodos implican mover una aplicación que se ejecuta en las instalaciones a una instancia de máquina virtual que se ejecuta en la nube, pero hay una diferencia clave. Para realojar una aplicación, es necesario crear una instancia de máquina virtual en la nube y luego mover la aplicación a esa instancia. Por otro lado, la reubicación implica mover una máquina virtual existente de un entorno local a la nube sin realizar cambios significativos en ella.

Supongamos que su organización utiliza un software de virtualización VMware y necesita migrar una de sus máquinas virtuales a la nube. En lugar de realizar un tedioso proceso de migración manual, puede buscar un proveedor que ofrezca VMware en la nube y migrar la máquina virtual a la nube del proveedor.

La mayor ventaja de este tipo de migración es su simplicidad. Otra ventaja es que, como se utiliza una versión en la nube de la plataforma de virtualización que se utilizaba en las instalaciones, prácticamente no hay curva de aprendizaje para el personal de TI.

3. Reestructurar (replatform)

Si bien a la reubicación a veces se la denomina "lift and shift", la reestructuración de plataformas es más bien un "lift and reshape". Originalmente revisar en el modelo de las cinco R de Gartner, a veces se la denomina "lift, tinker and shift".

La idea detrás de la reestructuración es que, si se está migrando una aplicación heredada, los proveedores de la nube probablemente ofrezcan muchas funciones y capacidades que no existían cuando se creó la aplicación. Puede tener sentido mejorar la aplicación como parte del proceso de migración para que pueda aprovechar al máximo lo que la nube tiene para ofrecer, como la escalabilidad y la flexibilidad.

Cambiar la plataforma de una aplicación suele ser costoso y llevar mucho tiempo, pero en algunos casos el esfuerzo está justificado. Esto es especialmente cierto si está actualizando una aplicación de una línea de negocio principal de un modo que aumente los ingresos o le permita seguir utilizando la aplicación durante años.

Una cosa que hay que tener en cuenta es que no todas las aplicaciones pueden cambiar de plataforma. Cambiar de plataforma es principalmente una opción para aplicaciones de código abierto o desarrolladas internamente. Los proveedores de software comercial no suelen proporcionar su código fuente, lo cual es un requisito absoluto para cambiar de plataforma.

4. Refactorizar (refactor)

La cuarta R, refactorizar, es como la reestructuración en el sentido que implica modificar una aplicación para aprovechar todo lo que la nube tiene para ofrecer, pero existen diferencias importantes. En particular, cuando se reestructura una aplicación, se conserva su arquitectura y sigue funcionando de la misma manera. En comparación, la refactorización implica realizar cambios arquitectónicos fundamentales en la aplicación. Por ejemplo, se puede dividir una aplicación en una colección de microservicios.

Se podría decir que la refactorización es el tipo de migración más difícil, pero a veces vale la pena como forma de proteger una aplicación para el futuro. Al igual que con la reestructuración, es necesario tener acceso al código fuente de la aplicación para refactorizarla.

5. Recomprar (rebuy)

La quinta R, recomprar, tiene varios significados. Por un lado, puede significar reemplazar una aplicación local por una aplicación nativa de la nube que haga lo mismo. También puede significar reemplazar una aplicación local por una versión SaaS de la aplicación.

Por último, la recompra puede referirse a la eliminación gradual de componentes arquitectónicos heredados en favor de sistemas administrados sin servidor. Por ejemplo, una organización puede reemplazar su base de datos SQL Server con un servicio administrado, en el que el proveedor de la nube ejecuta SQL Server en la nube. La ventaja de este enfoque –en comparación con simplemente ejecutar SQL Server en una máquina virtual basada en la nube– es que cuando una base de datos se ofrece como un servicio administrado, el proveedor de la nube maneja todo el mantenimiento asociado. El proveedor mantiene el servicio en funcionamiento, proporciona la redundancia necesaria y maneja cualquier administración de parches requerida.

6. Retirar (retire)

No siempre tiene sentido trasladar todas las cargas de trabajo a la nube. Tal vez sea mejor retirar algunas aplicaciones antiguas.

Una carga de trabajo puede ser adecuada para retirarse si el proveedor ya no la respalda activamente. En tales casos, es importante asegurarse de tener una solución alternativa antes de retirar una aplicación que la organización aún utiliza. Eso puede significar adoptar una aplicación de la competencia que ofrezca una funcionalidad similar o desarrollar una internamente.

En ocasiones, es posible que deba realizar cambios importantes en los procesos comerciales de la organización antes de poder retirar una aplicación obsoleta. Por ejemplo, si una aplicación ya no recibe soporte y los reemplazos adecuados resultan prohibitivos en términos de costos, es posible que sea mejor cambiar los procesos comerciales.

7. Retener (retain)

La séptima R, retener, significa esencialmente dejar una aplicación en paz por el momento.

Supongamos que su organización depende de una aplicación en particular que actualmente se ejecuta en las instalaciones. Si bien puede haber presión para migrarla a la nube, el proveedor ha anunciado una versión SaaS para más adelante en el año. Probablemente no tenga sentido soportar el costo y las molestias de una migración a la nube cuando puede esperar a que esté disponible la versión en la nube.

La estrategia de retención también puede entrar en juego cuando se debe considerar las dependencias de las aplicaciones. Supongamos, por ejemplo, que su organización tiene una aplicación particular que desea trasladar a la nube. Durante la etapa de planificación, descubre que otra aplicación que se ejecuta en las instalaciones depende de la aplicación que la organización desea migrar y podría dejar de funcionar. En esta situación, la aplicación debe mantenerse en su estado actual hasta que se hayan migrado o retirado las aplicaciones dependientes.

Brien Posey fue MVP de Microsoft en 22 ocasiones y candidato a astronauta comercial. En sus más de 30 años en TI, se desempeñó como ingeniero de red principal para el Departamento de Defensa de los EE. UU. y administrador de red para algunas de las compañías de seguros más importantes de Estados Unidos.