lunes, 23 de mayo de 2011

Los cinco caminos para migrar aplicaciones a la nube

Según Gartner, las organizaciones que pretenden llevar sus aplicaciones a la nube disponen de cinco opciones: realojarlas en una infraestructura como servicio (IaaS), refactorizarlas en una plataforma como servicio (PaaS), revisarlas para adaptarlas a los modelos IaaS o PaaS, reconstruirlas sobre PaaS o reemplazarlas con software como servicio (SaaS). Además, de acuerdo con el director de Investigación de la consultora, Richard Watson, “Los objetivos de negocio y TI deben dirigir cualquier decisión de migración a la nube, sin dejarse llevar por la prisa por experimentar con nuevos juguetes”.

La consultora disertó sobre la modernización de aplicaciones en el Encuentro sobre Arquitectura, Desarrollo e Integración de Aplicaciones de Gartner, celebrado entre el 16 y el 17 de junio en Londres. Uno de los temas estelares fue la migración de aplicaciones a la nube.

“Cuando los CIOs reciben la directriz de mover algunas aplicaciones a la nube, los arquitectos se enfrentan a diferentes alternativas y sus decisiones deben considerar los requerimientos de la organización, los criterios de evaluación y los principios de su arquitectura”, explicó el director de Investigación en Gartner, Richard Watson.

Las diferentes alternativas de migración que la consultora sugiere a las organizaciones TI son:

1.- Realojamiento (IaaS): es decir, el despliegue de las aplicaciones en un entorno hardware diferente y el cambio de la configuración de la infraestructura de la aplicación. Realojar una aplicación sin hacer cambios en su arquitectura puede suponer una solución de migración a la nube más rápida. Sin embargo, la principal ventaja de IaaS (que los equipos pueden migrar sistemas rápidamente sin necesidad de modificar su arquitectura) puede convertirse en su principal desventaja, porque podrían perderse beneficios propios de esta infraestructura, como la escalabilidad.

2.- Refactorización (PaaS): significa correr las aplicaciones en la infraestructura de un proveedor de nube. La ventaja en este caso radica en una combinación de familiaridad e innovación, dado que al ser compatible con una vuelta atrás, los desarrolladores pueden reutilizar los lenguajes, marcos de desarrollo y contenedores en los que han invertido, aprovechando el valor del código que la organización considera estratégico.

Entre las desventajas de este modelo se incluyen la pérdida de capacidades, los riesgos propios de la transición y la dependencia de un framework determinado. En el actual estadio inicial del mercado PaaS, algunas de las capacidades de las que dependen los desarrolladores en las plataformas existentes pueden no estar incluidas en la oferta PaaS.

3.- Revisar: es decir, modificar o extender la base de código existente para soportar los requerimientos de modernización heredados, utilizando entonces las opciones de realojamiento y refactorización para desplegar las aplicaciones en la nube. Esta opción permite a las organizaciones optimizar la aplicación para aprovechar las características de la nube de los proveedores de infraestructura.

El inconveniente radica en que el inicio del proyecto de desarrollo (posiblemente el principal) requerirá una serie de inversiones por adelantado para movilizar al equipo de desarrollo. Dependiendo del alcance de la revisión, esta alternativa puede exigir más tiempo para sacar provecho de todas las capacidades de la nube.

4.- Reconstruir: implica la reconstrucción de la solución en un modelo PaaS, descartando el código de una aplicación existente y rediseñando su arquitectura. Aunque la reconstrucción supone la pérdida de familiaridad con el código y el framework, la ventaja de esta opción es que permite el acceso a funciones innovadoras de la plataforma del proveedor. Estas capacidades mejoran la productividad de los desarrolladores gracias a herramientas que permiten el uso de plantillas y modelos de datos, motores que hacen uso de los metadatos y comunidades que pueden proporcionar componentes preconstruidos.

Sin embargo, la dependencia constituye la principal desventaja, de forma que si el proveedor hace un cambio técnico o del modelo de precios que el consumidor no puede aceptar, incumple los acuerdos de nivel de servicio (SLAs) o no cumple con las expectativas, el cliente se ve forzado a cambiar, abandonando potencialmente algunos o todos los activos de su aplicación.

5.- Reemplazar (SaaS): es decir, descartar una aplicación o conjunto de aplicaciones existente, y utilizar software comercial facilitado como un servicio. Esta opción evita la inversión que exige la movilización de un equipo de desarrollo cuando los requerimientos de una función de negocio cambian rápidamente.

Entre las desventajas se pueden incluir la inconsistencia de la semántica de los datos, incidentes en el acceso a los mismos y dependencia del proveedor.

Como asegura Watson, “ninguna de las alternativas supone un puente de plata: todas requieren arquitectos para entender la migración de aplicaciones desde múltiples perspectivas y criterios, como los conocimientos del personal TI, el valor de las inversiones existentes y la arquitectura de aplicaciones”.

“Elegir la alternativa optima de migración de aplicaciones es una decisión que no puede realizarse en solitario”, advierte el consultor. “Cualquier decisión relacionada con la migración a la nube es, en esencia, un decisión de modernización de aplicaciones o arquitectura y requiere de una acercamiento amplio relacionado con la gestión de la cartera de aplicaciones y los programas de gestión del portofio de infraestructuras”.

“Esta decisión no está relacionada únicamente con la migración, sino verdaderamente con la optimización: qué plataformas cloud y que técnicas de migración ofrecen la oportunidad de optimizar la aplicación en línea con los objetivos establecidos en relación con las TI y el negocio”, concluye.

No hay comentarios: