Estrategias de Migración al Cloud: Análisis del Framework 5 Rs de Gartner

¿Por qué migrar al Cloud?

Mucho se viene hablando de cambiar los entornos locales por la nube pero, ¿sabríamos indicar el por qué?

La migración al Cloud o la externalización de las TI desde el control y la operación directa de la empresa a uno o más proveedores de servicios externos es una decisión estratégica de la compañía, y puede producirse por diversos motivos:

• Reducir los costes, además de mejorar la entrega de valor y pasar de costes fijos a costes variables.
• Volver a centrar los esfuerzos del equipo TI en la parte core, y llevarse al Cloud lo que no es core del negocio (las commodities).
• Responder a las condiciones cambiantes de la empresa con mayor rapidez y eficacia, creando una asociación estratégica basada en el valor con la empresa.

Existen diversas estrategias para llevar a cabo esta migración, así que en esta entrada vamos a ver y analizar una de ellas.

Framework 5 Rs de Gartner para migración al Cloud

En 2010 Gartner publica la primera versión del framework 5 Rs ,el cual que define todas las opciones básicas para migrar una aplicación al Cloud (podemos encontrar más información al respecto en este enlace, pero requiere que nos registremos). Desde entonces Gartner lo ha ido mejorando y completando, además otras compañías lo han usado como framework base para construir sus propias estrategias y metodologías de migración el Cloud, como el modelo 6 Rs de AWS.

En el modelo de 5 Rs de Gartner las estrategias de migración de aplicaciones son:

• Rehost: también conocida como «lift and shift», la aplicación pasa desde su actual entorno físico o virtual a un IaaS en la nube. Al hacerlo, se evita cualquier modificación del sistema que no sea la necesaria para adaptarse al propio entorno de alojamiento (monitorización, por ejemplo). Aunque esta es la alternativa menos ambiciosa y beneficiosa, también es la más rápida de implementar para «llegar a la nube». En este caso, la aplicación no es Cloud-native como tal.
• Revise (Revisión): se modifica la aplicación para que esta pueda empezar a aprovechar las capacidades de la nube para obtener elasticidad y minimizar el uso de recursos. Esta estrategia se centra en la reducción de la carga operativa mediante el uso de servicios gestionados en la nube (por ejemplo, PaaS de bases de datos). Se puede optar por utilizar IaaS o CaaS para reducir la complejidad operativa.
• Rearchitect (Rearquitecturado): se modifica significativamente la aplicación para poder adaptarla a una arquitectura Cloud-native, haciendo un uso intensivo de las capacidades nativas de la nube. La alternativa de rearquitecturado es una labor profunda que requiere cambios en la metodología, la tecnología, el proceso de desarrollo, etc. En esta estrategia se incluyen PaaS (aPaaS), Kubernetes, function PaaS (fPaaS) y capacidades Serverless.
• Rebuild (Reconstrucción): propone que se empiece desde cero, desechando parte o todo el código existente que se ha acumulado a lo largo de los años. Esta alternativa prescribe el uso de servicios Cloud, Kubernetes, aPaaS, fPaaS, etc. Las razones para usar este enfoque son entre otras permitir:
  • A los desarrolladores, centrar sus esfuerzos en la entrega de código.
  • A los no desarrolladores, entregar aplicaciones mediante modelos LowCode.
  • Amortizar la deuda técnica.
  • Adoptar nuevos paradigmas de arquitectura que se adapten mejor a los requisitos actuales del negocio (procesamiento en streaming, Big Data, etc.).
  • Simplificar la aplicación.
• Replace (Sustitución): se opta por una solución SaaS para reemplazar su paquete de software COTS o una aplicación totalmente personalizada. Aunque se trata de un patrón común para la sustitución de soluciones COTS locales antiguas, también aplica para aplicaciones de software personalizadas. Estas soluciones SaaS tienen pocas barreras de entrada en términos de restricciones técnicas y de capital, lo que hace que sea una opción muy atractiva desde la perspectiva del coste inicial/de capital y del tiempo de entrega si se puede encontrar un proveedor que cumpla los requisitos de su aplicación.

Ejemplos de las estrategias

Dicho todo esto, vemos algunos ejemplos de a lo que nos referimos:

• Rehost: despliegue de una aplicación Java EE existente EE en instancias Linux EC2 de Amazon Web Services (AWS).
• Revise:
  • Pasar de utilizar la implementación JMS del aplicaciones Java EE a utilizar un proveedor de mensajería basado en la nube.
  • Para una aplicación alojada en Amazon EC2, la sustitución de una instancia de Oracle DBMS alojada en la nube por Google Cloud SQL, Azure Sql Database o Amazon Relational Database Service (RDS).
• Rearchitecture: rediseño de una aplicación Java monolítica, descomponiendo la funcionalidad en servicios más pequeños para ser desplegados de forma independiente, y luego desplegando en Amazon EC2 Container Service o Google Kubernetes Engine.
• Rebuild:
  • Construir una aplicación bancaria moderna a la que se pueda acceder a través de múltiples canales, empaquetada en contenedores y desplegada y ejecutada en Kubernetes con la malla de servicios Istio y Prometheus para la monitorización.
  • Reconstrucción de partes de un ERP mediante flujos de trabajo sencillos utilizando una Plataformas Low Code como Mendix, OutSystems u Onesait Platform.
• Replace:
  • Salesforce CRM y Microsoft Dynamics 365 para la gestión CRM de una organización.
  • Microsoft 365 como suite de productividad.

Comparación de las estrategias del framework

Vistos algunos casos de ejemplos, a continuación vamos a resumir en un cuadro algunas de las diferencias que afectan al alcance, la complejidad y el nivel de esfuerzo que introduce cada una de las alternativas:

	Rehost	Revise	Rearchitect	Rebuild	Replace
Código fuente	Sin cambios	Pequeños cambios	Actualización + Nuevo	Nuevo	N/A
Configuración	Sin cambios	Extensión	Transformación	Nuevo	N/A
Configuración y despliegue	Sin cambios	Actualización o nuevo	Transformación	Nuevo	N/A
Datos de la aplicación	Sin cambios	Sin cambios o ajustes	Transformación	Transformación	Transformación

El alcance, la complejidad y el nivel de esfuerzo asociados a cada estrategia de migración varían. La computación en la nube tiene el potencial de aportar importantes beneficios a su empresa, pero cuantos más beneficios desee desbloquear, más inversión deberá realizarse en la migración.

No todas las aplicaciones necesitan ser reconstruidas desde cero, y los objetivos de retorno de la inversión varían de una aplicación a otra. Si no se va lo suficientemente lejos con la modernización de la aplicación, puede haber problemas con una menor calidad de servicio en la aplicación migrada frente a la original.

Consideraciones en la elección de una estrategia de migración

Ahora bien, antes de lanzarnos a migrar a la nube, tenemos que tener en cuenta ciertas consideraciones a la hora de escoger la estrategia a seguir, tanto a nivel de las 5 Rs como de los principios empresariales.

Sobre las 5Rs:

• No todas las aplicaciones necesitan ser reconstruidas desde cero, y los objetivos de retorno de la inversión varían de una aplicación a otra. En algunos casos, si se hace una modernización de la aplicación insuficiente puede haber problemas con una menor calidad de servicio en la aplicación migrada frente a la original.
• La migración de aplicaciones a la nube no siempre da lugar a un resultado empresarial positivo o a un retorno de la inversión, en cuyo caso deben evaluarse otras alternativas. Por ejemplo, hay dos estrategias adicionales que son la de Retain y Retire.
• Las organizaciones están adoptando cada vez más los servicios Cloud CAPS y los contenedores como servicio, lo que requiere que sus desarrollos a medida sean rearquitecturados (Rearchitect) o reconstruidos (Rebuild) para beneficiarse de las capacidades de la nube, lo que requiere un mayor compromiso tanto del desarrollo como de las operaciones, pero ofrece una mejor escalabilidad, resistencia y flexibilidad.
• La estrategia de realojamiento (Rehost) es el camino más directo hacia la nube, pero también el menos beneficioso. El realojamiento ofrece una oportunidad limitada de mejorar las características del tiempo de ejecución de la aplicación y no ofrece ninguna oportunidad de rediseñar la arquitectura subyacente para aprovechar las capacidades nativas de la nube y de optimización de costes.
• La estrategia de reemplazo (Replace) a través de SaaS, es una forma alternativa de transición de las capacidades empresariales a un servicio en la nube. Esta opción conlleva el mayor riesgo de lock-in con el proveedor SaaS, especialmente si también se requiere personalización.

Principios empresariales

Cuando se elige una opción de migración, ésta debe contemplarse bajo unos principios exclusivos de la organización, por lo que es importante tenerlos en cuenta. Algunos de ellos son estos:

• Grado de autonomía: debido a las características de pago por uso y autoservicio de la nube, la migración de aplicaciones a los proveedores de la nube puede respaldar una estrategia de autonomía de los equipos, departamentos o unidades de negocio. Esto influye en la migración, ya que algunas alternativas pueden requerir menos apoyo de TI. Un ejemplo de ello es el uso de plataformas Low Code.
• Soluciones cerradas frente a soluciones abiertas: las organizaciones que favorecen las soluciones basadas en plataformas abiertas (por ejemplo, Kubernetes, Kafka, etc.) tienen una elección reducida de servicios de su proveedor Cloud porque muchos servicios del proveedor son cerrados/propios. Con una solución de código abierto, no hay que pagar a un proveedor y, a menudo, se puede elegir entre varios proveedores que ofrecen soporte, por el contrario, los servicios cerrados del proveedor son mucho más económicos.
• Un único proveedor frente a una combinación de los mejores: los principios de aprovisionamiento de la organización pueden dictar el uso de un único proveedor en lugar de una combinación de los mejores proveedores e influir en la decisión cuando varias opciones de migración cumplen los requisitos de una aplicación.
• Lock-in, portabilidad, multicloud e interoperabilidad: La portabilidad no sería una consideración si un arquitecto pudiera migrar una aplicación, junto con sus datos, a un proveedor Cloud y dejarla allí durante toda su vida. Pero ignorar el lock-in de la plataforma es arriesgado, por lo que los arquitectos deben considerar una estrategia de múltiples proveedores para las múltiples facetas de la portabilidad en la nube.
• Capacidades de desarrollo y operaciones: externalizar una aplicación migrando a una plataforma en la nube implica ceder parte del control operativo al personal del proveedor. El examen de los perfiles de competencias de los equipos de desarrollo y operaciones restantes determinará el grado de control que conviene ceder al proveedor.
• Coste de la migración: las aplicaciones migradas tienen que cumplir unos niveles de servicio adecuados. Desglosar los acuerdos de nivel de servicio de la aplicación existente es un paso importante. Los ingenieros tienden a ignorar la necesidad porque la presupuestación de las aplicaciones locales puede capitalizar los recursos, como el servidor o el almacenamiento, para hacer desaparecer el coste de esos recursos como «coste hundido».

---

Bueno, como podemos ver migrar a la nube es algo tan sencillo o directo como parece en un primer momento, por lo que toca hacer una pequeña reflexión sobre qué es lo que buscamos y necesitamos.

Referencias

• Migrating Applications to the Cloud: Rehost, Refactor, Revise, Rebuild, or Replace?
• The 6 R’s: AWS Migration Strategies

✍🏻 Author(s)