La gran farsa del Lift & Shift y otras mentiras sobre las migraciones Cloud.

Todo aquel que se haya planteado migrar sus aplicaciones a la nube seguro que está familiarizado con las 6 R’s. Este es un modelo inicialmente propuesto por Gartner en 2010 y que recogía las que para ellos eran las cinco principales alternativas a la hora de llevar una aplicación a Cloud.

Con el paso del tiempo este modelo fue abrazado por la industria, sobre todo por AWS, modificándolo ligeramente y dejando como posibles estrategias las siguientes:

• Retirar.
• Retener.
• Refactorizar.
• Recomprar.
• Replataformar.
• Realojar.

Pero veamos brevemente en qué consiste cada una y, teniendo en cuenta las motivaciones que nos llevan a migrar nuestras aplicaciones, si todas tienen igual sentido hoy en día.

Las 6 R’s

1 Realojar

Consiste, simplemente, en mover la aplicación a la nube tal cual está on-premise. Se llevará con la misma arquitectura, el mismo dimensionamiento y la misma configuración. Esta estrategia se denomina Lift & Shift cuando se hace una copia de la aplicación utilizando herramientas automáticas.

Y se habla de Reinstall o Greenfield cuando se hace una instalación desde cero desplegándose en la nube de la misma manera que estaba on-premise.

Esta estrategia se suele usar generalmente motivada por la urgencia dentro del contexto de una gran migración en la que hay que mover una alto número de aplicaciones.

2 Replataformar

Este tipo de migración implica modificar la infraestructura subyacente, haciendo optimizaciones para lograr beneficios tangibles en la nube, sin cambiar la arquitectura central de la aplicación.

Por ejemplo, se puede aumentar la automatización y reducir el tiempo de administración de un entorno con unas pequeñas modificaciones como subir los estáticos a S3 o utilizar una base de datos gestionada. O se puede ir un poquito más allá utilizando Kubernetes o una PaaS.

Es la migración que deberíamos plantearnos, como mínimo, si queremos llevar una aplicación a la nube. Es algo sencillo siempre que se cuente con los conocimientos adecuados y permite obtener algunas ventajas Cloud de forma inmediata.

3 Readquirir

En este caso, se replantea la migración de la aplicación actual a la nube y se decide sustituirla por otro producto diferente. Ejemplos comunes de recompras suelen ocurrir al dar el salto a plataformas SaaS, como pueden ser mover tu correo a Gmail o tu CRM a Salesforce.

Las motivaciones pueden ser múltiples: porque sea más barato, más rápido o porque no sea una aplicación crítica ni que forme parte del core de nuestro negocio.

4 Refactorizar/Rediseñar

Cuando existe una fuerte necesidad de obtener un mayor rendimiento, mejorar la escalabilidad o la disponibilidad de la aplicación siempre se suele escoger esta estrategia.

Frente a un entorno on-premise, alcanzar esos objetivos reconstruyendo la aplicación para dotarla de características propias de un modelo Cloud resulta mucho más sencillo. En ocasiones, suele requerir cambios profundos en la arquitectura pudiendo ser necesario rehacerla por completo.

5 Retirar

A veces, durante la fase de descubrimiento, se encuentran algunos recursos TI que se ve claramente que no es necesario mover a la nube porque estén obsoletos o ya no son útiles. Por tanto, se toma la decisión de desactivarlos, lo que puede traducirse en ahorros significativos.

6 Retener

En algunas ocasiones, se puede dar el caso de que queramos conservar on-premise algunas aplicaciones que, por cuestiones normativas, por coste, porque hagan uso de tecnologías legacy no soportadas en Cloud, por cercanía o por latencia sea más conveniente tener en local.

Drivers para la migración a Cloud

Los drivers para emprender una migración masiva de aplicaciones a la nube pueden ser muy variados. En ocasiones, esto puede producirse porque una empresa compra o vende otra o porque traslada su sede a otra localización y en el cambio de instalaciones decida dar ese paso.

También, hay empresas que han crecido con múltiples sedes de forma dispersa y deciden agrupar sus datacenters y consolidarlos en un solo sitio (y qué mejor sitio que la nube). O llega el momento en que un contrato de collocation u outsourcing termina y, ante la renovación, alguien piensa en Cloud. A menudo, también lo hacen para reducir costes.

Dejando a un lado estas cuestiones más logísticas, puede haber otras motivaciones con un carácter más estratégico: se desea fomentar la agilidad y la productividad de los desarrollos.

Se piensa en acelerar la innovación y la transformación digital de la compañía. O surge la necesidad de ejecutar a gran escala trabajos que requieren un uso intensivo de recursos.

Esfuerzo/beneficio de cada estrategia

Cada una de las R’s tiene sus pros y sus contras, cada una requiere un esfuerzo distinto y nos va a brindar unas ventajas diferentes:

Ante todas estas alternativas, ¿cuál escogemos?

Podemos quitar de la ecuación Retiro y Retención ya que, estrictamente, no son migraciones a Cloud. Ocurre algo parecido con la Readquisición donde tampoco estamos migrando la aplicación actual, sino yéndonos a un producto diferente en la nube.

Una de las estrategias más utilizadas es el Realojamiento porque se asume erróneamente que el Lift & Shift es una estrategia para ir a Cloud de forma más rápida y más barata. Esto, de entrada, puede tener su lógica, pero en la práctica no es así y cualquiera que haya pasado por ello lo sabe:

No es más barato

Generalmente las cargas de trabajo on-premise suelen estar sobredimensionadas, se les han asignado muchísimos más recursos de computación y memoria de los que necesitan y necesitarán para funcionar.

Si se llevan tal cual a la nube, ese exceso de capacidad incrementará sus costes (sobre todo a largo plazo). De esta forma no se harán más eficientes, sino que se transferirán sus ineficiencias a una nueva localización. Y por esto, los costes de operación también serán mayores.

Puede que, de inicio, la inversión en la migración sea menor pero a la larga siempre acabará costando más de lo esperado.

No es más rápido

Una arquitectura Cloud no es igual que una arquitectura diseñada para desplegarse on-premise. Las arquitecturas monolíticas y stateful no se adaptan bien a Cloud.

Por lo general, encajar aplicaciones on-premise en la nube suele requerir adaptaciones que no son triviales: desplegar configuraciones legacy sobre nuevo hardware, corregir deuda técnica que no se puede soportar, datos de sesión con balanceo de carga, ajustes por direccionamiento IP dinámico, problemas por almacenamiento efímero, etc.

En definitiva, optar por el Lift & Shift pondrá el peligro el éxito del Cloud en tu empresa. Al llevarte a la nube muchos de los problemas de tu anterior modelo IT gastarás una importante cantidad de tiempo, dinero y esfuerzo aplicando medidas de contingencia para compensar sus ineficiencias inherentes.

Tus aplicaciones replataformadas serán menos ágiles, menos escalables, menos flexibles y menos rentables económicamente.

Por tanto, nos quedan Replataformar y Refactorizar. La primera, si queremos obtener Quick Wins; y la segunda, si deseamos aprovechar al máximo la nube.

Estas son las dos únicas estrategias verdaderamente válidas si queremos migrar nuestras aplicaciones a Cloud, sin cargos ocultos ni sorpresas de última hora y sacando realmente todo el valor a la nube.

Cualquier otra alternativa será una oportunidad perdida porque en lugar de construir una infraestructura Cloud, con todas las ventajas que ello conlleva, estarás simplemente migrando a otro datacenter.