Un proyecto de migración al Cloud empieza cuando una organización decide migrar sus aplicaciones desplegadas en infraestructura on-premises (sea infraestructura propia o de terceros) hacia la nube pública. Los proyectos de estas características son complejos, costosos y de largo aliento (obviamente en función del tamaño de la organización).
* Nota: Aunque pueden existir otros tipo de migraciones Cloud, como por ejemplo de un proveedor de Cloud a otro proveedor Cloud o de infraestructura on-premise a Cloud privados, para el alcance de este articulo nos estamos refiriendo exclusivamente a migraciones OnPremise -> Cloud Público.
Cuando estamos planificando un proyecto de estas características, normalmente las siguientes son preguntas frecuentes -aunque no las únicas preguntas- que las organizaciones se hacen:
- ¿A que nube debo ir? (¿AWS?, ¿GCP?, ¿Azure?, ¿Otra?)
- ¿Debo elegir una sola nube o más de una?
- ¿Cuál es el costo de migrar?
- ¿Cuál es el beneficio (cuantitativo y cualitativo) de migrar?
- ¿Que tipo de workloads debo migrar? (Aplicaciones de negocio paquetizadas, desarrollos, procesos de datos, etc.)
- ¿Que tipo de aplicaciones debo migrar? (Aplicaciones legadas, aplicaciones comerciales, desarrollos, etc.)
- ¿Como debo migrar mis aplicaciones?
El articulo busca dar una respuesta a la última pregunta del listado anterior.
Al momento de decidir migrar tus aplicaciones, una de las actividades que debemos hacer es evaluar tus aplicaciones en 3 dimensiones:
- Fitness Funcional: ¿Están los usuarios contentos con la aplicación? ¿Satisfacen los requerimientos de negocio? ¿La velocidad de cambio es aceptable?
- Fitness Técnico: ¿Qué tan alineada está la aplicación a la estrategia tecnológica de la empresa? ¿Tiene obsolencencia tecnologica? ¿Es escalable a la demanda del negocio? etc.
- Fitness Financiero: ¿Cuanto nos cuesta mantener y evolucionar la aplicación?
En función de los resultados obtenidos en el análisis anterior, podemos determinar la mejor estrategia a seguir tomando como base las famosas 5 “r”s en cuanto a modernización de aplicaciones:
- Rehost (cambiar de host): Implica mover tu aplicación as-is, sin cambios en su arquitectura a infraestructura Cloud. Esta es la opción con menos impacto y normalmente la que implica menor esfuerzo de migración. Comunmente conocida como Lift & Shift.
- Replatform (cambios mínimos de plataforma aplicativa): Implica mover tu aplicación, manteniendo su arquitectura base, pero con cambios en algún componente de su plataforma aplicativa, como por ejemplo cambiar el servidor de aplicaciones o base de datos. Esto puede ser debido a obsolecencia, falta de soporte de dicho componente o bien para aprovechar el uso de la nube cambiando, por ejemplo, una base de datos gestionada por una auto-gestionada en la nube. Cambios en código fuente son mínimos, así como impacto funcional.
- Rearchitect (cambios a la arquitectura de tu aplicación): implica cambios al código fuente de tu aplicación, lo suficientemente profundos que signifiquen un cambio en su arquitectura. Esto puede ser para aprovechar mejor componentes nativos de la nube (ejemplo: utilizar integración via eventos en una plataforma de mensajería autogestionada), para resolver deuda técnica o para mejorar la calidad técnica de la aplicación.
Nota: “Refactor” muchas veces se incluye como aquella estrategia intermedia entre Replatform y Rearchitect, cuyo foco principal es la optimización del codigo fuente de la aplicación, pero en nuestra experiencia esta estrategia no se da normalmente en este tipo de migraciones, por lo cual la excluimos del listado principal. - Rebuild (reconstruir tu aplicación): implica realizar una reingeniería mayor a tu aplicación. Es aquí donde empieza el mayor impacto funcional ya que probablemente los requerimientos de negocio también cambien. Esta reingeniería se da muchas veces cuando la aplicación arrastra durante mucho tiempo excesiva deuda técnica y obsolescencia tecnológica.
- Replace: Retirar y reemplazar tu aplicación por una nueva, ya sea SaaS o un paquete comercial que instales en la nube. Al reemplazar un sistema tiene un alto impacto en la arquitectura completa, y el impacto funcional puede variar en función de si decides replicar el sistema funcionalmente o realizar una reingeniería de requerimientos.
- Retain: Dejar la aplicación OnPremise sin realizar ningún cambio. Esto sucede, por ejemplo, cuando la aplicación está en plan de retiro y resulta conveniente esperar por su retiro en vez de hacer el esfuerzo de migrarla a la nube.
Como hemos mostrado, las alternativas para decidir la estrategia de migración de tu aplicación no se limitan a hacer un Lift & Shift, sino que puede resultar mas compleja en función de tu estrategia tecnológica y de negocio.
Cada opción tiene distintos niveles de esfuerzo de migración (la opción 1 el “menor” esfuerzo, la 5 el “mayor” esfuerzo pues implica implementar una aplicación desde 0) y también distintos niveles de impacto en la infraestructura, en la tecnología aplicativa, y en la funcionalidad.
Muchas empresas empiezan estos viajes sin tener un objetivo y outcomes claros ni decidir una adecuada estrategia de migración y con ello incrementan las probabilidades de fracasar en el camino. En nuestra experiencia, tener éxito en este tipo de proyectos depende de un correcto análisis de estrategia de migración y de esta forma preparar tus aplicaciones adecuadamente para el futuro.