modernización de las aplicaciones-

Estrategias para afrontar la modernización de las aplicaciones a la nube


¿Cómo saber cuándo hay que trasladar simplemente una aplicación y cuándo hay que reconstruirla desde cero?

He aquí algunos consejos para evaluar correctamente tanto la parte técnica como sus los aspectos comerciales.

modernización de las aplicaciones - Adaptar las aplicaciones a la nube
modernización de las aplicaciones – Adaptar las aplicaciones a la nube


Modernización de las aplicaciones a la nube


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 una mejor experiencia, una mayor fiabilidad, un rendimiento más rápido e, idealmente, un despliegue más frecuente de funciones. Los arquitectos, los desarrolladores de software y los ingenieros de DevOps tienen diferentes respuestas a 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 está clara.

Por ejemplo, una aplicación de flujo de trabajo utilizada por docenas de usuarios y escrita en las últimas versiones de Java y MySQL puede ser fácilmente migrada y trasladada a una nube pública.

Este enfoque requiere poca reescritura de código, pero probablemente los cambios de configuración, las actualizaciones de CI/CD y la reejecución de las automatizaciones de prueba. Por otro lado, si la misma aplicación está escrita en Cobol y se ejecuta en un mainframe, es muy probable que tenga que reescribirse antes de poder ejecutarse en la nube.

Entre el lifting y el cambio y la revisión completa, todavía hay una serie de opciones técnicas disponibles; que permiten abordar la modernización de las aplicaciones en la nube de una forma adecuada.

Hay pequeñas diferencias entre las fuentes, pero son representativas de las opciones de modernización de alto nivel.


Factores a tener en cuenta

Las organizaciones tienen cientos o miles de aplicaciones heredadas, aplicaciones que tienen una deuda técnica importante y aplicaciones que tienen beneficios para el usuario o el negocio de la migración. Los arquitectos y los directores técnicos suelen adoptar distintos enfoques de modernización en función de las necesidades empresariales y los retos técnicos.

Lo primero que hay que tener en cuenta es el impacto en las operaciones de la empresa y en los usuarios. Las aplicaciones de misión crítica y de mayor utilización requieren un enfoque técnico diferente al de las aplicaciones más episódicas. Cualquier actualizació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.

Uno de los mayores retos a los que se enfrentan las organizaciones es identificar y saber qué aplicaciones hay que actualizar y trasladar, refactorizar o reescribir, y en qué orden. La modernización de las aplicaciones requiere un cuidadoso equilibrio entre la velocidad de comercialización y la escalabilidad, la optimización de los costes, la deuda técnica futura y la mitigación del tiempo de inactividad operativa.

Pasar a la nube puede tener una serie de beneficios, como la reducción de costes, la mejora de la seguridad y la flexibilidad, y la facilidad para que los clientes escalen la prestación de servicios para esto 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 tendrán que revisar los impulsores 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.

modernización de las aplicaciones a la nube - DEVOPS y CI/CD
modernización de las aplicaciones a la nube – DEVOPS y CI/CD

Retirar las aplicaciones que ya no aporten valor


¿Todavía tu empresa utiliza aplicaciones que admiten conexiones telefónicas, faxes u otras formas antiguas de soportar el negocio? Si tus aplicaciones realizan funciones que ya no son necesarias, la estrategia de modernización correcta es retirarlas.

A veces hay una decisión clara de retirar una aplicación: los usuarios de la empresa han acordado dejar de usar la aplicación, o retirarla no tiene impacto en las operaciones de la empresa. Pero aunque las aplicaciones se utilicen poco o realicen una función empresarial, su valor de negocio debe sopesarse con los costes de modernización y soporte continuo.

Para mejorar la experiencia del usuario, las empresas deben considerar una estrategia de retirada adecuada y a tiempo. Abandonar las aplicaciones obsoletas y heredadas supondrá una mayor eficiencia, que se traducirá en una mejor experiencia de usuario para los clientes. Del punto de vista de ciberseguridad, también supondrá una superficie de ataque reducida que se traducirá en una mayor seguridad.

Reemplazar aplicaciones por SaaS, opciones comerciales o de código abierto

La sustitución puede ser apropiada cuando las soluciones propietarias ya no son necesarias o ya no consiguen evolucionar para dar esa respuesta. La substitución de una aplicación debe ser evaluada cuando una organización ya no consigue generar valor de las aplicaciones desarrolladas a medida, y debe considerar pasar a una aplicación de terceros proporcionada por un proveedor, alojada o no en la nube , y preconstruida.

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 SaaS, comerciales o de código abierto equivalentes en ese momento no satisfacían las necesidades empresariales.

Hoy en día, los usuarios de las empresas pueden encontrar opciones de terceros mejores y más baratas en comparación con su propia solución propietaria que debe ser actualizada.

Recolocar las aplicaciones hacia la nube

Las aplicaciones que se ejecutan en paquetes de software que satisfacen las necesidades de la empresa y pueden recibir soporte pueden ser candidatas a la migración. En lugar de ejecutarse en hardware dedicado o en máquinas virtuales, el equipo de arquitectura y devops encontrará beneficios técnicos y empresariales al trasladarlos al entorno de la nube.

Por ejemplo, puede ser más fácil configurar los entornos de desarrollo y prueba, escalar automáticamente la producción y configurar los entornos de recuperación de desastres cuando la aplicación se ejecuta en una nube pública o privada.

la migración no equivale a la modernización”. Lo explica. Casi todas las empresas consiguen algunos beneficios a corto plazo, pero el error que cometen muchos líderes tecnológicos es pensar que el trabajo termina ahí.

Devops puede proporcionar flexibilidad en la infraestructura, mejoras en la seguridad y reducciones de costes, pero no aborda los problemas relacionados con la aplicación y el soporte del código subyacente.

Esta es la realidad: un monolito en la nube se enfrenta a los mismos problemas espinosos que en las instalaciones: velocidad de ingeniería lenta, falta de escalabilidad y difícil mantenimiento.

Esta fase se denomina “arrepentimiento por elevación”, ya que los costes aumentan y las ventajas de la nube siguen estando fuera de su alcance. Para disipar este mito, la migración debe considerarse y planificarse en el contexto de una estrategia de modernización más amplia y estratégica”.

modernización de las aplicaciones-  Apps Cloud Architecture
modernización de las aplicaciones- Apps Cloud Architecture

Reemplazar componentes de plataforma con ventajas operativas

Muchos ven en el “lift and shift” una opción de migración que requiere una participación mínima del equipo de desarrollo y no requiere actualizaciones de código o cambios importantes de configuración. La esperanza es que algunas de las ventajas de la migración puedan conseguirse sin el trabajo y el coste adicionales de la reelaboración del código.

Sin embargo, 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 de volver a ponerlos en marcha durante la migración.

Aunque la re-planificación suele requerir la intervención de los desarrolladores, es posible que no sea necesario realizar cambios significativos en el código, sobre todo si se incorporan a la pila plataformas básicas, estandarizadas o casi equivalentes.

En lugar de levantar un almacén de datos heredado o un lago de datos y trasladarlo a la nube, la migración a la nube crea una oportunidad para adoptar arquitecturas de almacén abiertas y enfoques de redes 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 costes. Otras opciones de re-planificación son 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 aplicaciones estratégicas.

Una vez que los arquitectos y los equipos de desarrollo deciden actualizar el código como parte de la modernización de las aplicaciones, tienen varias opciones:

  • Pueden reutilizar los modelos de datos, servicios y APIs existentes de la aplicación, pero también pueden rediseñar la experiencia del usuario.
  • Refactorizar el código para mejorar el rendimiento, la seguridad, la mantenibilidad y otras actualizaciones no funcionales.
  • Reconstruir los módulos y las capacidades para mejorar la funcionalidad, solucionar los errores o reducir la deuda técnica. Algunos están reconstruyendo aplicaciones monolíticas en microservicios.

La estrategia de refactorización y rearquitectura, aunque es el enfoque más caro, debería considerarse si las empresas quieren avanzar hacia un modelo de devops más ágil. También es una estrategia para impulsar la innovación continua, que en última instancia contribuye a mejorar el rendimiento.

Los equipos de DevOps también pueden considerar un enfoque por fases. Por ejemplo, pueden volver a alojar primero las aplicaciones que se ejecutan en plataformas elegibles para obtener las ventajas operativas de ejecutarlas en nubes privadas o públicas. En ese caso, pueden considerar la posibilidad de reutilizar las aplicaciones de poco uso que no se actualizan con frecuencia, y de rediseñar otras aplicaciones en las que la empresa necesita actualizaciones frecuentes.

La modernización de las aplicaciones no está exenta de costes y riesgos. Para las organizaciones con miles de aplicaciones, puede llevar años modernizar completamente una cartera. Los equipos de DevOps y los arquitectos deben utilizar una lente de practicidad y mirar todos los factores antes de seleccionar una estrategia de modernización de aplicaciones.

Puedes encontrar más articulos interesantes en nuestro blog.