Cuando hablamos de modernizar una aplicación aparecen algunas confusiones producto de la tendencia asociada a “subir” aplicaciones a la nube.
Cuando tenemos que modificar una app para poder ser llevada a la #nube, o porque simplemente necesitamos actualizarla, recordemos que debemos modificar cuestiones relacionadas a su arquitectura aplicativa y su arquitectura de infraestructura; y que por lo general son tareas que merecen un análisis para entender que estrategia utilizar, ponderando cuestiones tecnológicas y de costos.
Estrategias asociadas
Existe un concepto ampliamente extendido por los proveedores de nube que consiste en las 5R.
Estas 5R son: Rehost, Refactor, Rearchitect, Rebuild, y Replace. Algunos agregan 2R a esta lista, pero en líneas generales, son los conceptos más extendidos.
Enumeremos cada una de ellas con una breve explicación:
- #Rehost: es el concepto más simple de migración a la nube. Consiste en la técnica de “lift & shift” es decir, levantar toda la plataforma tal cual está y montarla en otro destino sin mayores cambios.
- #Refactor: el refactor tiene la ventaja de realizar algunos cambios mínimos sobre las aplicaciones, utilizando por ejemplo servicios PaaS. En este caso una técnica habitual es migrar a la nube y -ej- usar bases de datos administradas por sobre motores instalados en VM.
- #Rearchitect: tiene en consideración el hecho de hacer cambios en las aplicaciones, ya sea porque utiliza componentes obsoletos, porque no fue pensada para nube o por cualquier situación que provoca que ese deba repensar la solución para que se adapte a un nuevo entorno cloud.
- #Rebuild: en este punto estamos hablando de reconstruir enteramente una aplicación. La actual muere de inanición y se crea en paralelo una plataforma que reemplace las funcionalidades de la app actual, pero con un nacimiento 100% cloud native.
- #Replace: por último en este caso, al igual que el rebuild, deja de lado la plataforma / software actual, y en su lugar se reemplaza en su totalidad, ya sea por un software o plataforma de un 3ro o por un nuevo desarrollo in-house.
¿Que estrategia debo elegir?
La respuesta es DEPENDE. Y como decía la canción de Jarabe de Palo, ¿de qué depende? Depende de las necesidades que se deban cumplir.
Yendo desde un Rehost > Refactor > Rearchitect > Rebuild > Replace podemos indicar que iniciando con un Rehost los costos operativos de efectuar la migración son menores, pero los costos de los servicios de nube serán mayores. A medida que nos vamos hacia el Rearchitect o Rebuild, el esfuerzo por modernizar una aplicación es mayor pero al ir hacia un modelo mas cercano al #CloudNative hace que los costos de nube disminuyan.
La decisión va a pasar entonces por definir si se requiere cumplir con tiempos cortos, el Rehost o Refactor sean convenientes, asumiendo costos de servicios cloud más altos.
Si se requiere cumplir con una aplicación más performante, con menores costos de nube y donde el tiempo no importe tanto, el Rearchitect, Rebuild / Replace, serían las estrategias a elegir.
[popup_anything id=”2076″]