Seis estrategias para migrar aplicaciones a la nube

Las empresas normalmente comienzan a considerar cómo migrar una aplicación durante la segunda fase del "proceso de migración" –Descubrimiento y planificación del portafolio. Esto sucede cuando determinan qué hay en su entorno, cuáles son las interdependencias, qué va a ser más fácil de migrar y qué será lo más difícil, y cómo migrarán cada aplicación.

Basado en este conocimiento, las organizaciones pueden determinar un plan (el cual estará sujeto a cambios a medida que avanza el proceso de migración y aprendizaje) sobre cómo abordarán la migración de cada una de las aplicaciones de su portafolio y en qué orden.

La complejidad de migrar aplicaciones que ya existen varía, dependiendo de la arquitectura y de los acuerdos existentes de las licencias. Si pienso en el universo de aplicaciones para migrar en un espectro más complejo, pondría una arquitectura virtualizada orientada al servicio en el extremo de baja complejidad del espectro y un servidor monolítico en el extremo de alta complejidad del espectro.

Sugiero comenzar con algo de baja complejidad del espectro, por la obvia razón que será más fácil completar, lo que dará un reforzamiento positivo inmediato o "victorias rápidas" a medida que aprenda.

Las seis estrategias para migración de aplicaciones más comunes que vemos son:

1. Realojar

También conocido como "levantar y desplazar". Encontramos que muchos proyectos tempranos en la nube gravitan hacia un nuevo desarrollo neto utilizando capacidades nativas de la nube, pero en un gran escenario de legado de migración, donde la organización está buscando escalar su migración rápidamente para hacer frente a un caso de negocio, encontramos que la mayoría de aplicaciones están realojadas. GE Oil & Gas, por ejemplo, encontró que incluso sin implementar ninguna optimización de la nube, podría ahorrar aproximadamente el 30% de sus costos realojando.

La mayoría de los realojamientos pueden ser automatizados con herramientas (por ejemplo AWS VM Import/Export , Racemi), aunque algunos clientes prefieren hacerlo manualmente a manera que aprenden cómo implementar sus sistemas a la nueva plataforma en la nube.

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

2. Redistribución

Algunas veces lo llamo “levantar-entretenerse-y-cambiar”. Aquí puede hacer algunas optimizaciones en la nube (u otras) para obtener algún beneficio tangible, pero no está cambiando de otra manera la arquitectura principal de la aplicación. Quizá puede estar buscando reducir la cantidad de tiempo que pasa administrando instancias en base de datos migrando a una plataforma de base de datos como servicio como Amazon Relational Database Service (Amazon RDS) o migrando su aplicación a una plataforma totalmente administrada como Amazon Elastic Beanstalk.

Una gran empresa de medios  con la que trabajamos migró cientos de servidores web que ejecutaban en sus instalaciones a Amazon Web Services y, en el proceso, pasó de WebLogic (un contenedor de aplicaciones Java, le cual requiere una licencia costosa) a Apache Tomcat , un  equivalente de fuente abierta. Esta compañía de medios ahorró millones en costos de licencias por encima de los ahorros y obtuvo agilidad al migrar a Amazon Web Services.

3. Readquirir

Pasar a un producto diferente. Lo más común es ver la readquisición como pasar a una plataforma de software como servicio. Pasar un CRM a Salesforce.com, un sistema HR a Workday, un CMS a Drupal, y así sucesivamente.

4. Refactorización / Re-arquitecturizar

Re-imagine cómo se diseña y desarrolla la aplicación, usualmente utilizando características nativas de la nube. Esto suele estar impulsado por una fuerte necesidad de negocio de agregar características, niveles o rendimiento, que de otro modo serían difíciles de lograr en el entorno existente de la aplicación.

¿Está buscando migrar de una arquitectura monolítica a una arquitectura orientada a servicios (o sin servidores) para aumentar la agilidad o mejorar la continuidad del negocio (he oído historias de correas de ventilador para computadoras siendo ordenadas por eBay)? Este patrón tiende a ser el más caro, pero, si tiene en buen estado su producto/mercado, también puede ser el más beneficiado.

5. Retirarse

Significia “Deshacerse de”. Una vez que haya descubierto todo en su entorno, puede preguntar en cada área funcional a quién pertenece cada aplicación. Hemos encontrado que hasta un 10% (he visto hasta un 20%) del portafolio de TI de una empresa ya no es útil, simplemente se puede desactivar. Estos ahorros pueden impulsar el negocio, dirigir la escasa atención de su equipo a las cosas que la gente utiliza y disminuir la superficie que tiene que asegurar.

6. Retener

Por lo general esto significa "revisitar" o no hacer nada (por ahora). Tal vez se encuentre en cierta depreciación, no está listo para priorizar una aplicación que se actualizó recientemente, o de lo contrario no está dispuesto a migrar algunas aplicaciones. Sólo debe migrar lo que sea benéfico para el negocio; y así, a medida que su portafolio cambie de estar físicamente en un sitio a la nube, probablemente tendrá menos razones para conservarlo.

Sobre el autor: Stephen Orban es director global de Estrategia Empresarial en Amazon Web Services.