[02/11/2022] Cuando alguien dice que quiere modernizar una aplicación para la nube, ¿a qué se refiere exactamente? Los usuarios tienen una perspectiva: Esperan que la modernización traiga consigo mejores experiencias, mayor fiabilidad, un rendimiento más rápido e, idealmente, una mayor frecuencia de despliegue de funciones. Los arquitectos, los desarrolladores de software y los motores de desarrollo tienen respuestas diferentes sobre lo que significa la modernización de las aplicaciones. Esto se debe a que hay varios enfoques técnicos para la modernización de aplicaciones, y la elección óptima no siempre es obvia.
[Reciba lo último de CIO Perú suscribiéndose a nuestro newsletter semanal]
Por ejemplo, una aplicación de flujo de trabajo utilizada por docenas de usuarios escrita en las últimas versiones de Java y MySQL puede ser fácil de trasladar a una nube pública. Este enfoque requiere poca reescritura de código, pero probablemente requiera cambios de configuración, la actualización del CI/CD y la reejecución de las automatizaciones de prueba. Por otro lado, si esa misma aplicación está escrita en Cobol y se ejecuta en un mainframe, es muy probable que necesite una revisión antes de ejecutarse en la nube.
Todavía hay varias opciones técnicas entre el levantamiento y el cambio y una revisión completa; se conocen como las 7R de la modernización de aplicaciones en la nube. Hay pequeñas diferencias de una fuente a otra, pero representan bien las opciones de modernización de primer nivel.
Factores a tener en cuenta
Las organizaciones tienen entre cientos y miles de aplicaciones heredadas, aplicaciones con una deuda técnica importante, y otras con beneficios para el usuario o el negocio en una migración. Los arquitectos y los responsables técnicos suelen utilizar diferentes enfoques de modernización en función de las necesidades del negocio y los retos técnicos.
Las primeras cuestiones a tener en cuenta son las repercusiones en las operaciones empresariales y los usuarios. Las aplicaciones de misión crítica y de mayor uso requerirán enfoques técnicos diferentes a los de las aplicaciones utilizadas de forma episódica. Cada modernización requerirá la comunicación con los usuarios, la realización de pruebas y la formación del personal sobre los cambios en el flujo de trabajo.
Nitha Puthran, vicepresidenta senior de la nube y la infraestructura de Persistent Systems, ofrece una visión general de algunos de los factores empresariales a la hora de seleccionar los enfoques y las hojas de ruta de la modernización de aplicaciones. Señala: "Uno de los mayores retos a los que se enfrentan las organizaciones es identificar y saber qué aplicaciones deben ser levantadas y cambiadas, refactorizadas o reescritas y en qué orden. Las modernizaciones de aplicaciones requieren un cuidadoso equilibrio entre la velocidad de comercialización y la escalabilidad, la optimización de costes, la mitigación de la deuda técnica futura y el tiempo de inactividad operativa".
Garth Fort, jefe de producto de Splunk, comparte cómo los equipos de devops se benefician de las modernizaciones de apps. "Puede haber muchos beneficios en una migración a la nube, incluyendo la reducción de costos, la mejora de la seguridad y la resiliencia, y facilitando el escalado de la prestación de servicios para los clientes", anota. "Para los equipos de devops, puede mejorar la agilidad y la productividad del personal, permitiendo a los equipos centrarse en la experiencia del cliente".
Los equipos de Devops y los arquitectos deben revisar los factores de negocio, técnicos, operativos y de seguridad de cada aplicación y luego considerar estos enfoques para la modernización de la nube de aplicaciones.
Retirar las aplicaciones que ya no son valiosas
¿Todavía tiene aplicaciones que soportan las conexiones telefónicas, los faxes u otras formas heredadas de hacer negocios? Cuando las aplicaciones realizan funciones que ya no son necesarias, la estrategia de modernización adecuada es retirarlas.
A veces, la decisión de retirar una aplicación está clara: Los usuarios de la empresa han dado su visto bueno al cierre de la misma, o la retirada de la aplicación no tiene impacto en las operaciones de la empresa. Pero incluso cuando las aplicaciones se utilizan poco o desempeñan una función comercial, su valor comercial debe sopesarse frente a los costos de modernización y soporte continuo.
Amit Patel, vicepresidente senior de Consulting Solutions, afirma: "Para mejorar la experiencia del usuario, las empresas deberían considerar la estrategia de retirada. Abandonar las aplicaciones heredadas obsoletas crea una mayor eficiencia, lo que conduce a una mejor experiencia de usuario para sus clientes. La reducción de la superficie de ataque también conduce a una mayor seguridad".
Reemplazar las aplicaciones por opciones SaaS, comerciales o de código abierto
Fort explica que la sustitución puede ser apropiada cuando las soluciones propietarias ya no son necesarias. "Reemplazar una app es cuando una organización deja de depender de sus propias aplicaciones construidas a medida, y migra hacia aplicaciones de terceros preconstruidas proporcionadas por un proveedor y alojadas en una nube".
Algunos ejemplos son las herramientas de gestión de las relaciones con los clientes, los sistemas de gestión de contenidos o las herramientas de flujo de trabajo personalizadas desarrolladas cuando las soluciones equivalentes de SaaS, comerciales o de código abierto de ese momento no satisfacían las necesidades del negocio. Hoy en día, los usuarios empresariales pueden encontrar opciones de terceros mejores y más baratas en comparación con la propietaria que necesita ser actualizada.
Reubicar la aplicación a la nube
Las aplicaciones que satisfacen las necesidades de la empresa y se ejecutan en pilas de software compatibles pueden ser candidatas a la reubicación. En lugar de ejecutarlas en hardware dedicado o máquinas virtuales, el equipo de arquitectura y desarrollo encuentra beneficios técnicos y empresariales al trasladarlas a entornos de nube. Por ejemplo, puede ser más fácil configurar los entornos de desarrollo y prueba, autoescalar la producción y configurar los entornos de recuperación de desastres con la aplicación que se ejecuta en una nube pública o privada.
Pero Bob Quillin, director del ecosistema de vFunction, señala: "La migración no equivale a la modernización. Hay beneficios de devops que se obtienen con el método de migración lift-and-shift. Casi todas las empresas consiguen algunos beneficios a corto plazo, pero el error que cometen muchos líderes tecnológicos es creer que el trabajo termina ahí".
La reubicación puede proporcionar flexibilidad en la infraestructura, mejorar la seguridad y reducir los costos, pero no aborda los problemas de soporte de la aplicación y el código subyacente.
"Esta es la realidad: Un monolito en la nube tiene los mismos problemas espinosos que tenía en las instalaciones: velocidad de ingeniería lenta, falta de escalabilidad y dificultad de mantenimiento", explica Quillin. "Esta fase se conoce como 'arrepentimiento de levantar y cambiar', ya que los costos aumentan y los beneficios de la nube siguen estando fuera de su alcance. Para acabar con este mito, la migración debe verse y planificarse en el contexto de una estrategia de modernización más amplia y estratégica".
Reemplazar los componentes de la plataforma que tienen beneficios operativos
Muchos interpretan el "lift and shift" como una opción de migración que requiere una participación mínima del equipo de desarrollo, y que no necesitará actualizaciones de código ni cambios importantes de configuración. La esperanza es obtener algunos beneficios de la migración sin el trabajo y los costos añadidos de la reingeniería del código.
Pero entre el código y la infraestructura se encuentran las plataformas de bases de datos, los marcos de trabajo y los componentes, y las oportunidades para replantearlos durante la migración. Aunque la replanificación suele requerir la intervención de los desarrolladores, es posible que no sea necesario realizar cambios sustanciales en el código, sobre todo si se incorporan a la pila plataformas básicas, estandarizadas o casi equivalentes.
Tomer Shiran, cofundador y director de producto de Dremio, comparte un ejemplo. "En lugar de levantar y trasladar un almacén de datos heredado o un lago de datos a la nube, una migración a la nube introduce oportunidades para adoptar arquitecturas de lago abiertas y enfoques de malla de datos para la gestión de datos".
Los arquitectos de la nube pueden modernizar los almacenes de datos y los lagos de datos para desplegarlos como servicios de nube pública que ofrecen ventajas operativas y de costos. Otras opciones de replanificación incluyen la migración de los buses de servicios, el paso a las herramientas estándar de CI/CD de una organización, o el cambio de las redes de entrega de contenidos.
Reutilizar, refactorizar o reconstruir las aplicaciones que ofrecen impactos empresariales a largo plazo
Una vez que los arquitectos y los equipos de desarrollo deciden actualizar el código como parte de la modernización de la aplicación, tienen varias opciones:
* Reutilizar los modelos de datos, servicios y APIs existentes de la aplicación, pero rediseñar la experiencia del usuario.
* Refactorizar el código para mejorar el rendimiento, la seguridad, la capacidad de mantenimiento y otras actualizaciones no funcionales.
* Reconstruir los módulos y las capacidades para mejorar la funcionalidad, abordar los defectos o reducir la deuda técnica. Algunos rediseñarán las aplicaciones monolíticas para convertirlas en microservicios.
¿Qué enfoque es el mejor para su aplicación? Patel comparte su punto de vista: "La estrategia de refactorización y rearquitectura, aunque es el enfoque más costoso, debería considerarse cuando las empresas quieren avanzar hacia un modelo de devops más ágil. Esta estrategia también ayuda a la innovación continua, ayudando en última instancia a aumentar el rendimiento".
Los equipos de Devops también pueden considerar enfoques por fases. Por ejemplo, primero pueden volver a alojar las aplicaciones que se ejecutan en plataformas compatibles para obtener las ventajas operativas de ejecutarlas en nubes privadas o públicas. A continuación, pueden considerar la reutilización de las aplicaciones de bajo uso que no se actualizan con frecuencia y la reingeniería de otras aplicaciones en las que hay una necesidad de negocio de mejoras frecuentes.
Las modernizaciones de aplicaciones no están exentas de costos o riesgos. Para las organizaciones con miles de aplicaciones, puede llevar años modernizar completamente la cartera. Los equipos de desarrollo y los arquitectos deben utilizar una lente de practicidad y revisar todos los factores antes de seleccionar la estrategia de modernización de una aplicación.
Basado en el artículo de Isaac Sacolick (InfoWorld) y editado por CIO Perú