Modernización y migración selectiva de aplicaciones a AWS

Las ventajas de AWS incluyen posibles reducciones de costos operativos, acceso a tecnologías avanzadas y un camino integrado hacia la innovación. La arquitectura ofrece alta disponibilidad, baja latencia y mayor resiliencia al mismo tiempo que proporciona más agilidad, automatización y un tiempo de salida al mercado más rápido que puede brindar una ventaja competitiva significativa. La pregunta ha cambiado. Es posible que se haya preguntado en años pasados: "¿Mi empresa realmente necesita migrar a la nube?” Ahora la pregunta es: "¿Cuál es la forma más eficiente de migrar a la nube y maximizar el ROI?"

No existe una estrategia de migración de AWS ideal y única que funcione para todas las organizaciones. En su lugar, encontrará varios enfoques que se pueden mezclar y combinar cuidadosamente seleccionados para diferentes aspectos del entorno de TI de su empresa.

Cada organización enfrenta un conjunto único de desafíos al migrar sistemas heredados a AWS. Al adoptar un enfoque de "modernización selectiva" para la migración, la empresa puede elegir qué conjunto de aplicaciones se adaptan bien a una modernización significativa para admitir la funcionalidad de AWS. Los clientes de PwC han obtenido muchos beneficios al seguir esta estrategia híbrida de modernización de AWS e invertir solo en aplicaciones donde es probable que se obtenga valor.

Cualquier empresa que se embarca en un viaje de modernización de aplicaciones y migración de AWS debe tener una comprensión sólida de su "deuda técnica", es decir, dónde se requiere una inversión significativa para volver a trabajar las aplicaciones para que admitan y aprovechen la funcionalidad de AWS. A fin de crear una estrategia eficiente a la migración de AWS, PwC considera la deuda técnica frente al valor de negocio de la aplicación.

Piense en la deuda técnica de esta manera: cuánto gasto y esfuerzo implica refactorizar un conjunto de aplicaciones existente al nivel de soporte que necesita para funcionar al menos tan bien como lo hizo en las instalaciones. Compárelo con el valor empresarial que la aplicación ofrece o podría ofrecer en AWS. El gráfico a continuación lo refleja:

Árbol de decisiones que muestra cómo debe migrar las aplicaciones heredadas a AWS

Las aplicaciones que generan un alto valor de negocio se adaptan mejor a un rediseño y modernización completos. Las aplicaciones con un valor de negocio bajo y una deuda técnica alta con frecuencia se construyen en plataformas heredadas y se escriben en versiones de lenguajes que ya han llegado al final de su vida útil. Estas aplicaciones tienen menor portabilidad y confiabilidad, a menudo no logran escalar rápidamente y vienen con la carga de mantener la infraestructura local. Cuando estas aplicaciones no son fuentes importantes de valor de negocio para la organización, no justifican el alto gasto que implica una reestructuración de aplicaciones a la medida.

Una estrategia de modernización selectiva recomienda un enfoque diferente: coloque las aplicaciones de baja criticidad y sus dependencias en contenedores, implementándolas con cambios mínimos en su código central. Este enfoque inicial ahorra dinero por adelantado y al mismo tiempo marca el camino para una modernización adicional en el futuro.

Aquí hay dos enfoques de uso que ilustran cómo manejar la modernización selectiva y la migración de aplicaciones heredadas:

• El primero es un enfoque de contenedores y cambios.
• El segundo utiliza servicios nativos de AWS para refactorizar la aplicación.

Los contenedores forman la columna vertebral de la modernización selectiva. La abstracción de la infraestructura de la aplicación y las capas del sistema operativo permite que las reglas de seguridad y redes se apliquen de manera consistente como parte de la configuración. La portabilidad de una aplicación en contenedores simplifica la integración continua/entrega continua (CI/CD) para aumentar la resiliencia y el tiempo de salida al mercado.

Ejemplo de aplicaciones con 'deuda técnica'

En el ejemplo de un cliente, una aplicación realizaba una función necesaria pero no proporcionaba un valor empresarial sustancial (gráfico anterior). La aplicación se ejecutaba en IBM WebSphere Application Server (WAS) 8.0 y estaba conectada a una base de datos IBM DB2, IBM MQ para la integración de servicios y SiteMinder para la gestión de identidades y accesos (IAM). La ruta de menor resistencia para contener la aplicación fue actualizar y personalizar el entorno de la aplicación a WAS 8.5.5 a través de Dockerfiles disponibles del proveedor.

La imagen resultante podría implementarse de diferentes maneras, como aprovisionar y ejecutar Kubernetes en instancias de Amazon EC2 o ejecutar Kubernetes utilizando EKS sin administrar el plano de control o las instancias maestras. En este caso, el cliente necesitaba un control total y se determinó que la mejor estrategia de hospedaje era un único pod de Kubernetes en AWS EC2.

Es mejor usar soluciones de CI/CD como AWS CodeBuild, CodeDeploy y CodePipeline para compilar y probar primero la aplicación y luego crear e implementar una nueva imagen de contenedor. Este enfoque produce la arquitectura de destino que se muestra en la siguiente ilustración.

La aplicación se modernizó de forma selectiva con un enfoque de contenedores y cambios

Un enfoque de migración y modernización de contenedores y cambios produce varias ganancias rápidas:

• Configurar las redes de forma centralizada a través de la consola de AWS, la CLI o IaC (a través de CloudFormation), promoviendo una interfaz de configuración común en todo el entorno de la aplicación.
• La ejecución de la aplicación en un contenedor garantiza la coherencia entre los entornos de desarrollo, prueba y producción, lo que aumenta la confiabilidad de las implementaciones.
• La automatización de la compilación y la implementación a través de canalizaciones de CI/CD nativas de AWS permite un tiempo de salida al mercado más rápido de los cambios de aplicaciones.
• Un entorno de varios módulos permite una gestión del ciclo de vida más rápida (inicio/detención/reinicio).
• Los estándares de cumplimiento están integrados en IAM local o las bases de datos permanecen en su lugar.
• Las aplicaciones en AWS ofrecen una mayor resiliencia integrada que se adapta más rápidamente y se recupera del tiempo de inactividad en comparación con la infraestructura local.

Un inconveniente de este enfoque es que la aplicación no puede aprovechar la agilidad que pueden ofrecer los tiempos de ejecución de contenedores debido a la estrategia de hospedaje de la organización al elegir EC2 y no optar por los entornos EKS o ECS. Esta estrategia de alojamiento tampoco puede aprovechar los beneficios de escalado dinámico de AWS para la arquitectura que permanece en las instalaciones. Se adapta a los casos en los que el objetivo principal de la migración de AWS es mantener el status quo desde el punto de vista de la arquitectura y, al mismo tiempo, eliminar parte de la dependencia de la infraestructura local.

Los arquitectos que buscan lograr una mayor elasticidad y disponibilidad de los servicios pueden aumentar las aplicaciones en contenedores con servicios nativos de AWS. El intercambio de componentes locales discretos, como bases de datos y proveedores de identidad, por soluciones nativas de AWS puede proporcionar los beneficios de la infraestructura de AWS y, al mismo tiempo, limitar los cambios de código necesarios a los componentes principales de la aplicación.

En nuestro ejemplo (gráfico a continuación), hay muchas oportunidades para la modernización selectiva de los servicios nativos de AWS, incluido el intermediario de mensajes, el proveedor de identidad y la administración de contenedores/informática. Utilizando la herramienta de conversión de esquemas de AWS (SCT) y el servidor de migración de bases de datos de AWS (DMS), puede migrar el IBM DB2 local a una base de datos de Amazon Aurora. De manera similar, podría sustituir Amazon MQ nativo de AWS por IBM MQ para manejar la integración de servicios y los servicios de intermediario de mensajes. Y debe tocar AWS Cognito para la gestión de identidad de la aplicación. El uso de los servicios EKS y ECR nativos de AWS reducirá los gastos generales y aumentará la facilidad de uso y la seguridad al permitir que AWS administre el plano de control de Kubernetes a través de EKS y ECR. Distribuirán, implementarán y protegerán de manera confiable las imágenes y los artefactos de los contenedores. El uso de Fargate como servicio de implementación para los nodos trabajadores de EKS proporciona una capa adicional de abstracción de la administración de servidores subyacentes para la aplicación.

La introducción del uso de servicios nativos de AWS elimina la sobrecarga de mantener servidores locales para aplicaciones heredadas y, al mismo tiempo, proporciona una solución más disponible, escalable y segura.

La aplicación se modernizó de forma selectiva con los servicios nativos de AWS habilitados

El segundo enfoque conlleva los mismos beneficios de configuración, desarrollo y tiempo de salida al mercado que el primer enfoque, pero agrega ventajas al adoptar servicios nativos de AWS.

• Los servicios nativos de AWS mejoran la confiabilidad de la aplicación sin el costo de reescribir los núcleos de las aplicaciones heredadas monolíticas.

• Simplificar el ecosistema general de aplicaciones conectando aplicaciones modernizadas selectivamente en soluciones nativas de AWS.

• Aumentar la agilidad y la elasticidad de las aplicaciones diseñadas para escalar para satisfacer la demanda.

• Poder abstraer y sustraer el mantenimiento de la infraestructura utilizando los servicios administrados de AWS.

Habilitar los servicios nativos de AWS puede requerir un aumento en el alcance y la revisión de la aplicación durante el proceso selectivo de modernización y migración. Las organizaciones de TI tendrán que equilibrar estas consideraciones con los beneficios de una mayor elasticidad y una deuda técnica reducida que traerá una modernización selectiva. 

Tenga en cuenta que no todas las aplicaciones se beneficiarán de la modernización selectiva. Las aplicaciones heredadas que requieren una infraestructura tradicional para realizar operaciones son menos ideales para la modernización y es posible que deban eliminarse gradualmente en ciclos de modernización posteriores. Para aumentar el valor de negocio, primero debe priorizar aquellas aplicaciones que probablemente produzcan el mayor beneficio a través de la modernización selectiva y la adopción de AWS.

Para la mayoría de las aplicaciones que generan menos valor de negocio y tienen una gran deuda técnica, la modernización selectiva presenta una compensación entre la modernización completa y la migración estricta a AWS. La modernización selectiva a través de contenedores puede extender, en gran medida, la vida útil de una aplicación a través de una mayor resiliencia, una reducción de los gastos generales de los servicios locales y un tiempo de salida al mercado más rápido de los cambios de la aplicación debido al uso de canalizaciones de CI/CD nativas. Las empresas que buscan oportunidades para modernizarse selectivamente pueden mantener saludable el ecosistema completo de aplicaciones mientras liberan recursos para rediseñar aplicaciones que generen el mayor valor de negocio. El resultado es un camino más simple, fluido y potencialmente menos costoso hacia AWS.