6 estrategias para migrar aplicaciones a la nube @AWScloud @stephenorban
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 6 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í puedes 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-imagina 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 e-bay)? 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 - Deshacerse de.
Una vez que hayas descubierto todo en tu entorno, puedes 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 encuentres en cierta depreciación, no estás 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.
No hay comentarios.