Estrategias de migración a la nube (6R'S)

Dentro del campo de la migración a la nube, existen diferentes métodos y formas de poder sobrellevarlo a cabo, por lo tanto, puede llegar a ser muy confuso para quien no tiene experiencia en el campo o quienes quieren seguir avanzando, pero no saben que existe este tipo de movimientos.

Sin embargo, la nube de AWS nos apoya con una serie de diferentes formas de sobrellevarlo, como son las 6 R´s las cuales nos ofrecen una migración desde distintas perspectivas o puntos, que se adaptan ante cualquier tipo de infraestructura y necesidad.

1. REHOSTING

También conocido como "lift-and-shift".

Descubrimos que muchos de los primeros proyectos en la nube gravitan hacia un nuevo desarrollo neto que utiliza las capacidades nativas de la nube, pero en un escenario de migración de grandes legados en el que la organización busca escalar su migración rápidamente para cumplir un caso de negocio, descubrimos que la mayoría de las aplicaciones se realojan. GE Oil & Gas, por ejemplo, descubrió que, incluso sin implementar ninguna optimización de la nube, podía ahorrar aproximadamente un 30% de sus costes mediante el realojamiento.

La mayor parte del realojamiento puede automatizarse con herramientas (por ejemplo, CloudEndure Migration, AWS VM Import/Export), aunque algunos clientes prefieren hacerlo manualmente mientras aprenden a aplicar sus sistemas heredados a la nueva plataforma en la nube.

También hemos comprobado que las aplicaciones son más fáciles de optimizar/reorganizar una vez que ya se están ejecutando en la nube. En parte porque su organización habrá desarrollado mejores habilidades para hacerlo, y en parte porque la parte difícil -la migración de la aplicación, los datos y el tráfico- ya se ha hecho.

La intención de esta estrategia es alcanzar el caso de negocio de una forma acelerada.

RE-PLATFORM

En este caso, es posible que se realicen algunas optimizaciones en la nube (o de otro tipo) para lograr algún beneficio tangible, pero no se cambia la arquitectura principal de la aplicación. Es posible que busque reducir la cantidad de tiempo que dedica a la administración de instancias de bases de datos mediante la migración a una plataforma de base de datos como servicio, como Amazon Relational Database Service (Amazon RDS), o la migración de su aplicación a una plataforma totalmente administrada, como Amazon Elastic Beanstalk.

Una gran empresa de medios de comunicación con la que trabajamos migró cientos de servidores web que ejecutaba en sus instalaciones a AWS y, en el proceso, pasó de WebLogic (un contenedor de aplicaciones Java que requiere una costosa licencia) a Apache Tomcat, un equivalente de código abierto. Esta empresa de medios de comunicación se ahorró millones en costes de licencias, además del ahorro y la agilidad que obtuvo al migrar a AWS.

RE-PURCHASE

Lo más habitual es ver la recompra como un cambio a una plataforma SaaS. Se trata de cambiar un CRM por Salesforce.com, un sistema de recursos humanos por Workday, un CMS por Drupal, etc.

Identificar app o servidores que posiblemente ya lo ofrece un tercero.

Por ejemplo, tengo un CRM On premise que me consume un front end un backend y una base de datos 2 o 3, me consume tantos GB de almacenamiento, me consume tanto licenciamiento, y a lo mejor es nada más para un nicho de clientes que tengo muy segmentado y que con una app de un tercero de algo que se ofrece como SaaS, que en Google puedas poner CRM y te van a salir varias opciones y se puede acoplar para ese tipo de uso en particular

Es un servicio que en realidad necesito o pudiera estar pagárselo a un tercero para que lo mantenga y yo nada más lo consumo como un SaaS

REFACTOR

Re imaginar la arquitectura y el desarrollo de la aplicación, normalmente utilizando características nativas de la nube.

Esto suele estar motivado por una fuerte necesidad empresarial de añadir funciones, escala o rendimiento que, de otro modo, serían difíciles de conseguir en el entorno actual de la aplicación.

¿Busca migrar de una arquitectura monolítica a una arquitectura orientada a los servicios (o sin servidores) para impulsar la agilidad o mejorar la continuidad del negocio (he oído historias de correas de ventilador de mainframe que se piden en e-bay)? Este modelo tiende a ser el más caro, pero, si tiene un buen ajuste producto-mercado, también puede ser el más beneficioso.

Esto es muy bueno siempre y cuando tengas en claro cuales son los objetivos de negocio y hacia donde se quiere ir.

RETAIN

Por lo general, esto significa "revisar" o no hacer nada (por ahora).

Tal vez todavía esté aguantando alguna depreciación, no esté preparado para dar prioridad a una aplicación que se ha actualizado recientemente o, por el contrario, no esté dispuesto a migrar algunas aplicaciones. Sólo debe migrar lo que tiene sentido para el negocio; y, a medida que la gravedad de su cartera cambia de las instalaciones a la nube, probablemente tendrá menos razones para retenerla.

RETIRE

Deshágase de.

Una vez que haya descubierto todo lo que hay en su entorno, puede preguntar a cada área funcional a quién pertenece cada aplicación. Hemos comprobado que hasta un 10% (yo he visto un 20%) de la cartera de TI de una empresa ya no es útil, y puede simplemente desactivarse. Este ahorro puede impulsar el caso de negocio, dirigir la escasa atención de su equipo a las cosas que la gente utiliza, y disminuir la superficie que tiene que asegurar.

Estas son las estrategias de migración, de aquí en adelante hay mucha más información de como desmenuzar cada una de ellas, esto es solo la punta del iceberg y considerar que hay opciones al momento de migrarse a la nube, que no es nada más blanco o negro, no solamente es todo en la nube o todo On premise, lo ideal es tener un mix o incluso tener esquemas de replicación en la nube, en distintas regiones.

Gracias a esto se pueden llegar a esquemas bastante interesantes y todo gracias a las estrategias de migración.

Contáctanos para cualquier duda o comentario que tengas.