Modernización de aplicaciones: un enfoque de evaluación rápida

La intención de la evaluación rápida es definir un conjunto de criterios de alto nivel que se puedan aplicar rápidamente a la cartera de aplicaciones para disponer rápidamente todas las aplicaciones en un recorrido hacia la nube. Se trata de una evaluación preliminar, con la intención de desarrollar un punto de vista inicial sobre el patrimonio de la aplicación. La intención es estar dentro de más o menos el 10-20 % de las disposiciones que se derivarían de un análisis más exhaustivo. 

Es necesario desarrollar un punto de vista sobre la disposición de todo el patrimonio de aplicaciones para hacer lo siguiente:

• Impulsar el caso de negocio general para la transformación de la nube híbrida.
• Elaborar estimaciones para modernizar y migrar la cartera de aplicaciones a la nube.
• Demostrar un enfoque de modernización estandarizado que maximice el valor general del negocio.
• Demostrar la capacidad de desarrollar rápidamente una comprensión de la cartera de aplicaciones e identificar los atributos que impulsan la complejidad, el tiempo de comercialización, el rendimiento y la escalabilidad.

A la hora de definir el enfoque de evaluación rápida, resulta útil analizar por separado las cargas de trabajo distribuidas y las de mainframe. Estas plataformas suelen tener diferentes controladores de modernización, SLA y tecnologías de soporte, lo que impulsa un conjunto variable de criterios para evaluar la cartera. Aunque muchas aplicaciones distribuidas tienen backends de mainframe, o "sistemas de registro", una carga de trabajo distribuida, en este caso, se define como aquella que tiene su hilo de ejecución principal ejecutándose en una plataforma distribuida.

Una distribución típica de alto nivel de disposiciones de aplicaciones distribuidas y sus definiciones es la siguiente:

• Refactorizar/modernizar a nativo de la nube: 5-15 % consiste en aplicaciones altamente valoradas y críticas para el negocio. Estas aplicaciones se refactorizan o reescriben como aplicaciones nativas de la nube/de 12 factores. Esta disposición proporciona el mayor valor comercial, ya que la aplicación se vuelve más ágil, escalable y altamente disponible, pero a un costo elevado. En consecuencia, estas aplicaciones deben elegirse con criterio, ya que representan inversiones estratégicas que suelen ser de millones de dólares por aplicación. 
• Contenerizar: 50-60 % que consiste en la mayoría de las aplicaciones Java y algunas aplicaciones de Windows. Estas aplicaciones están contenedorizadas para ejecutarse en un contenedor Kubernetes, idealmente en Red Hat OpenShift. Las aplicaciones contenedorizadas proporcionan el ROI óptimo basado en el costo de contenerizar en comparación con el beneficio general obtenido.
• Migrar: 30-40 % que consiste en COTS, algunos Windows y otros "exóticos" que se ejecutan en bare metal o máquinas virtuales. Estas aplicaciones siguen un patrón de "lift-and-shift" con pocos o nulos cambios de código para moverlas a la nube. Los patrones de migración más comunes son de físico a virtual y de virtual a virtual.
• Dejar tal cual: <10 % compuesto por aplicaciones de escritorio, aplicaciones móviles (sin incluir el backend) y aplicaciones que ya están en la nube (especialmente SaaS, aunque algunas aplicaciones en la nube podrían moverse a una nube más preferida).

Tenga en cuenta que estas disposiciones difieren de otras rúbricas de categorización de aplicaciones, como las 7 R de Gartner, pero proporcionan una forma mucho más sencilla y directa de clasificar la cartera, al tiempo que identifican las aplicaciones que ayudarán a impulsar el mayor valor de transformación: las aplicaciones que serán refactorizadas y contenerizadas:

Se necesita un conjunto mínimo de atributos de datos para ejecutar la evaluación rápida para aplicaciones distribuidas. Veamos cada criterio con más detalle.

Aplicaciones comerciales listas para usar (COTS)

Dado que el código fuente de las aplicaciones comerciales listas para usar (COTS) normalmente no se distribuye al comprador, estas aplicaciones deberán migrarse a la nube. Durante una evaluación más detallada (normalmente un sprint de 30 días), se puede realizar una investigación adicional para determinar si el proveedor de COTS tiene planes de mover la aplicación a contenedores o desarrollar una versión nativa de la nube.

Algunos adaptadores personalizados COTS desarrollados por el cliente pueden ser candidatos para la refactorización o la contenerización. Esta disposición a nivel de componente se determinaría durante una evaluación más detallada.

Aplicaciones SaaS o aplicaciones que ya se movieron a la nube

Las aplicaciones que ya se ejecutan en la nube suelen permanecer "tal cual" si el objetivo final es acelerar el movimiento general hacia la nube. Las aplicaciones podrían moverse a otra nube si el objetivo es mover todas las cargas de trabajo a un proveedor de la nube específico, pero lo más seguro es suponer que estas aplicaciones permanecerán donde residen actualmente.

Aplicaciones de misión crítica/críticas para el negocio

Las aplicaciones de misión crítica o críticas para el negocio deben considerarse para modernizar o refactorizar aplicaciones nativas de la nube, ya que son las que más se benefician del alto costo de refactorización. 

A partir de este conjunto de aplicaciones, determine las aplicaciones que:

• Tienen un alto grado de actividad de cambio o un gran retraso y obtendrían beneficio de ser más ágiles, o
• Actualmente no satisfacen las necesidades del negocio y se beneficiarían de ser reinventadas para reflejar un proceso de negocio modernizado o una experiencia de usuario mejorada.

Esta categoría suele representar no más del 5-15 % de toda la cartera. Para una cartera de 500 aplicaciones, eso se traduce en reescribir entre 25 y 75 aplicaciones en tres a cinco años: una cifra considerable que representa un enorme esfuerzo de desarrollo y costo.

Aplicaciones Java

Las aplicaciones Java son las principales candidatas para la contenerización. Cualquier aplicación que se ejecute en un servidor de aplicaciones JavaEE (WAS, WebLogic, Jboss, Tomcat, etc.) debería poder contenerizarse con un esfuerzo relativamente pequeño. Una suposición clave es que se hará lo "mínimo" para contenerizar la aplicación: las actualizaciones o movimientos de middleware (por ejemplo, mover la  base de datos relacional a una base de datos nativa de la nube, mover de MQ a Kafka) están fuera del alcance. Sin embargo, el pipeline CI/CD debería actualizarse para producir contenedores y aprovechar las características subyacentes de OpenShift.

Aplicaciones de Windows

Las aplicaciones de Windows tienen dos opciones para la contenerización:

• Ejecutar en contenedores Linux, que suelen ser cargas de trabajo .Net CORE
• Ejecutar en contenedores de Windows, que estuvieron disponibles en OpenShift V4.6

En general, los criterios de decisión para las aplicaciones de Windows son los siguientes:

• .Net CORE se traslada a contenedores Linux
• La aplicación de Windows personalizada .NET, VB, C o C# se mueve a contenedores de Windows

Se requiere un análisis más detallado para determinar mejor la idoneidad de la contenedorización, pero supongamos que, a efectos de planificación, al menos la mitad de las aplicaciones de Windows pueden contenerizarse.

Todas las demás aplicaciones: migrar

Todas las demás aplicaciones normalmente se migrarían a la nube, siendo el patrón más común físico a virtual o virtual a virtual para la mayoría de las cargas de trabajo distribuidas. Las tecnologías “exóticas” o “no convencionales” requieren una consideración más cuidadosa, ya que una zona de aterrizaje en la nube puede no estar fácilmente disponible. Las cargas de trabajo de iSeries y pSeries normalmente pueden moverse a Power Systems Virtual Server en IBM Cloud. Otras cargas de trabajo pueden requerir hardware especial para instalarse en el área CoLo de los IBM Cloud Data Centers, si es posible (por ejemplo, Unisys, Tandem Nonstop, etc.).

Las cargas de trabajo de mainframe presentan complejidades adicionales para definir las disposiciones de las aplicaciones. El destino final de estas aplicaciones no siempre está claro, dependiendo de la estrategia general de mainframe del cliente. Para las cargas de trabajo distribuidas, la zona de destino típica son los entornos en contenedores o virtualizados en servidores x86 en la nube. El destino objetivo para las aplicaciones de mainframe puede adoptar múltiples sabores y puede incluir lo siguiente, según la filosofía de mainframe y los objetivos comerciales del cliente:

• Optimice las aplicaciones en su footprint actual para reducir los costos de cómputo y operaciones (actualizaciones del compilador, eficiencias de programación, etc.).
• Modernice/transforme las aplicaciones in situ, continuando su ejecución en la plataforma IBM Z (ya sea z/OS o Linux on Z).
• Modernice/transforme las aplicaciones para que se ejecuten en un entorno de nube distribuida.
• Utilice y acceda mejor a los activos de aplicaciones de mainframe desde otras aplicaciones distribuidas.
• Evacue completamente el centro de datos on premises, incluidas las cargas de trabajo del mainframe.

Las respuestas a estas preguntas ayudarán a impulsar las disposiciones objetivo, como las siguientes:

• Modernice la aplicación a Linux on Z.
• Moderniza la aplicación a Linux en x86 en la nube.
• Refactorice la aplicación en su tecnología actual (plataforma y lenguaje de programación) para impulsar la eficiencia operativa.
• Externalice los servicios clave como API.

Para las cargas de trabajo que permanecerán en el mainframe, es necesario responder a las preguntas sobre dónde residirá el mainframe:

• Retener en centro de datos on premises.
• Mover a las instalaciones de IBM Cloud Co-Lo.
• Mover a IBM Z como un servicio gestionado proporcionado por un integrador de sistemas global.

Por consiguiente, la disposición de las aplicaciones de mainframe es mucho más compleja y requiere una conversación más detallada con el cliente y un análisis más profundo de las aplicaciones en cuestión. 

La siguiente figura representa un resultado de muestra de una evaluación rápida de modernización de aplicaciones en el contexto del desarrollo de una propuesta de modernización de la nube. La capacidad de desarrollar rápidamente un punto de vista opinativo sobre la cartera de aplicaciones del cliente fue un factor clave diferenciador de nuestro enfoque:

En ocasiones, pueden ser necesarias evaluaciones más detalladas; sin embargo, la evaluación rápida proporciona una forma rápida y sencilla de estimar el esfuerzo necesario para transformar la cartera de aplicaciones a la nube y brinda las entradas para determinar el caso de negocio global de la transformación en la nube.