Mover las aplicaciones heredadas a la nube para aprovechar la seguridad y los datos modernos, los contenedores, los microservicios y la portabilidad suele empeorar las cosas. Este es el por qué.
por David Linthicum
Pídale a cualquiera que defina la modernización de aplicaciones y escuchará muchas respuestas diferentes. Aquí hay una generalización de lo que todos estamos de acuerdo: la modernización de aplicaciones toma aplicaciones y conjuntos de datos existentes que ejecutan negocios y los hace más útiles, productivos y atractivos para quienes los usan, especialmente los clientes. La capacidad de mejorar la experiencia del cliente impulsa más negocios.
Algunos ven la modernización de aplicaciones como “poner lápiz labial en un cerdo”, pero ese no es el propósito en absoluto. La modernización de aplicaciones no debe consistir en hacer que las aplicaciones parezcan modernas; las aplicaciones deben verse y ser modernas.
Esto significa cambiar las interfaces de usuario y máquina, así como modernizar la arquitectura interna, la infraestructura de la plataforma de nube pública, las características de la aplicación y la tecnología habilitadora. También implica pasar de los procesos tradicionales de desarrollo en cascada a ágiles y devops.
¿Es una buena idea tomar valiosas aplicaciones heredadas, mejorarlas y trasladarlas a una nube pública? Por supuesto. Sin embargo, veo cada vez más que los desarrolladores y los arquitectos de la nube abordan la modernización con algún tipo de lista de verificación interminable que a menudo va demasiado lejos y hace demasiado, por lo que pierde las metas y objetivos de valor comercial del proyecto. https://imasdk.googleapis.com/js/core/bridge3.519.0_en.html#goog_20865237627 minutes, 20 seconds of 21 minutes, 50 secondsVolumen 0%
Hay tanta información disponible sobre la modernización de aplicaciones, incluidos procesos y metodologías, que muchos equipos intentan modernizar marcando marcas que, según otros, harán que su aplicación heredada sea verdaderamente moderna. Persiguen conceptos de moda como contenedorización, microservicios, aumento de datos, aumento de la arquitectura interna y otras cosas que pueden requerir una cirugía mayor. Ese enfoque podría poner en riesgo la aplicación al introducir una gran cantidad de complejidad, complicaciones y gastos, solo para marcar una casilla de verificación.
Aquí hay dos cuestiones pragmáticas a considerar.
Primero, hay un punto de inflexión en el que puede tener más sentido desechar la aplicación heredada original y comenzar de nuevo. Siempre estoy más dispuesto a arreglar las cosas que tirarlas. Sin embargo, a menudo veo casos en los que se gastan $2 millones para modernizar una aplicación cuando un nuevo desarrollo neto habría costado $1 millón.
Los ingenieros de software generalmente entienden que a menudo es más fácil y económico construir algo desde cero en lugar de refactorizar y recodificar un sistema existente que primero debe comprenderse por completo antes de que pueda cambiarse para mejorarlo. Es raro que los equipos que originalmente desarrollaron la aplicación todavía estén en el personal. La base de conocimiento es incompleta o inexistente. La aplicación se ha modificado tantas veces a lo largo de los años que nadie comprende completamente su alcance completo tal como existe hoy.
En segundo lugar, aquellos que modernizan las aplicaciones pasan por una extensa lista de verificación de modernización de aplicaciones de las cosas que deben hacerse. En muchos casos, hacen todo lo que está en la lista sin importar la necesidad real. Esto significa contenedorización, habilitación de microservicios, migración a una base de datos más moderna, portabilidad y movilidad. Estas características se consideran necesarias porque están en la lista. ¿Por qué tan pocas personas cuestionan la lista?
En la mayoría de los casos, no vale la pena forzar el ajuste de todo en las listas de verificación de modernización de aplicaciones. Incluso la creación de contenedores, que tiene muchos beneficios, no es adecuada para todas las aplicaciones. Hay un costo para las arquitecturas basadas en contenedores y la tecnología habilitadora, como es el caso de los microservicios e incluso la migración a la nube.
No digo que esas características no sean inversiones sólidas cuando se basan en las necesidades de la aplicación. Estoy diciendo que en algunos casos son excesivos y realmente no agregan valor al propósito general del negocio. Una vez más, no te preguntes si puedes, pregúntate si deberías.
Fuente: https://www.infoworld.com/article/3664178/making-application-modernization-pragmatic-and-useful.html
