Patrones de migración a la nube: las seis Rs de AWS

En el post anterior comentábamos tres caminos (y medio) para la migración a la nube basándonos en las propuestas de Tom Laszewski, Kamal Arora, Erik Farr y Piyum Zonooz, en su libro 'Cloud Native Architectures',
Se incluía el realojamiento (lift-and-shift), del replataformado (lift-tinker-and-shift), de la reingeniería y del desarrollo nativo. Se trata de una visión algo resumida de las estrategias de migración posibles.
Los mismos autores, de hecho, nos hablan un poco más adelante de las llamadas 6 Rs (seis erres), de seis patrones o estrategias de migración a la nube que extienden un poco más la idea. Estos seis patrones parten de una propuesta inicial realizada por Gartner en 2011 en donde hablaba de 5 formas de migrar a la nube, a saber: rehost, refactor, rearchitect, rebuild, replace.
Apoyándose de forma explicita en esa ideas de Gartner (y hasta en las Rs iniciales), el equipo de AWS identifica seis estrategias para migrar aplicaciones a la nube:

Las 6 Rs de AWS para la migración a la nube

• 
  (R)ehosting: Se trata de la estrategia de lift-and-shift ya comentada, es decir, se trasladan las aplicaciones a la nube sin rediseño de ningún tipo casi (e incluso a veces literalmente) como una copia bit a bit. Hacerlo así a corto plazo no proporciona grandes beneficios pero permite una migración relativamente rápida (existen automatizaciones al respecto) y se espera que un posible rediseño posterior sea más sencillo una vez las aplicaciones se encuentran ya en la nube.


• (R)eplatforming: Se corresponde con el escenario lift-tinker-and-shift, es decir, el medio del artículo anterior, donde no se cambia de forma fundamental la arquitectura de la aplicación pero se introduce alguna pequeña mejora.


• (R)epurchasing: Se trata de una estrategia completamente diferente. En lugar de intentar migrar la aplicación existente, se adopta una nueva aplicación que ya está en la nube. Por ejemplo, podríamos abandonar nuestro CRM legado y migrar hacia Salesforce. Aunque no existe una migración de aplicación propiamente dicha, sí que resultan necesarias acciones como migrar datos, rediseñar interfaces, etc.


• (R)efactoring / (R)e-architecting: Se trata de hacer un rediseño profundo de la aplicación para que ya sea realmente cloud nativa. Creo que abarca tanto lo que en el anterior artículo denominábamos reingeniería (cambios profundos en la aplicación) como el desarrollo cloud nativo que es la construcción desde cero.


• (R)etire: En realidad no se trata de una migración sino de aprovechar el esfuerzo de análisis de la realidad de sistemas disponibles para prescindir de alguno que realmente no aporta valor o cuya funcionalidad puede ser absorbida por otro. Es una excelente oportunidad para simplificar el mapa de sistemas, lo que, aparte de ahorros de costes, aporta agilidad y mayor facilidad de gestión.


• (R)etain: En realidad es una no migración, es decir, decidimos conscientemente no migrar una aplicación a la nube.

Estas 6 Rs, creo que ofrecen un panorama más completo de las opciones para la migración a la nube y diría que también más directivo en el sentido de contemplar decisiones no específicamente técnicas en la migración, sino también otras opciones como la de no migrar, apagar sistemas o adoptar un nuevo producto.
El mapa de opciones queda así bastante más claro...lo cual no significa que adoptar esas decisiones sea sencillo, y ejecutarlas tampoco.