¿Por qué es ahora tan importante modernizar las aplicaciones?

La nube se ha instalado definitivamente en la sociedad. Las empresas han asumido de forma mayoritaria que funciona bien y son conscientes de los beneficios que ofrece en cuanto a flexibilidad, agilidad, seguridad, capacidad de innovación… Pero el número de aplicaciones que se ha llevado a la nube todavía no es notorio. Está empezando a crecer, pero es necesario que las empresas trasladen el grueso de sus aplicaciones al cloud para que puedan aprovechar todas esas ventajas.

Hasta ahora se ha iniciado el camino con soluciones más pequeñas. Poco a poco se va avanzando, pero las grandes aplicaciones críticas todavía no están en la nube, sino en entornos legacy, ejecutándose en las infraestructuras del cliente. Ahora es cuando empieza el gran reto y las empresas tienen muchas dudas a la hora de plantear el camino hacia la cloud.

El ciclo de release en un entorno legacy no es comparable con un desarrollo Agile en la nube. Es como competir con distintas armas

Pero esto ya es una realidad. Cuando los grandes bancos a nivel nacional o europeo, o los gigantes energéticos, han tomado la decisión de salir de su entorno legacy y llevar su core a la nube, es que ya no hay marcha atrás. El argumento de que los modelos cloud no van a soportar esas grandes y complejas aplicaciones se cae cuando demuestras que funcionan. Ya no hay excusa.

¿Es un movimiento generalizado?

Sí, se trata de una tendencia que está llegando a casi todos los sectores. En general, todas las compañías están considerando estos procesos de modernización y calibrando los retos que plantea llevar las aplicaciones críticas a la nube: cuál es la mejor fórmula, si hay que reescribirlas, hacer una rearquitectura o llevarlas tal y como están a un modelo cloud… Estas son cuestiones que están en la mesa de todas las compañías.

Quizá la Administración Pública sea el sector que va algo más rezagado en este sentido; en cualquier caso, y aunque no se trate de un ejemplo de movimiento a cloud, se pueden destacar los pasos que han dado importantes instituciones en nuestro país para trasladar muchas de sus aplicaciones de un entorno legacy a sistemas abiertos.

En este sentido, España es una de las regiones mejor posicionadas con respecto a los procesos de modernización, tanto en las Administraciones Públicas como en firmas españolas que son una referencia mundial en el sector banca o energía. De hecho, hay otros países, como Alemania o Francia, que todavía tienen un entorno legacy muy extendido, con una amplia base de aplicaciones basadas en Natural, Adabas, Pl1, IMS, Cobol, etc.

¿Por qué ahora?

Una vez que la nube se ha consolidado como una infraestructura robusta y fiable, que funciona, y vistos los movimientos de estas grandes corporaciones, las empresas, de forma mayoritaria, se están planteando moverse a la nube, ya sea pública o privada. Atendiendo a esta inercia, ahora le llega el turno a las grandes aplicaciones.

Pero es que el escenario es muy evidente: por ejemplo, el ciclo de release de una aplicación en un entorno legacy se puede ir a dos o tres meses mientras montas el entorno de ejecución, haces el desarrollo, lo despliegas, lo pruebas… Esto mismo, llevado con un desarrollo Agile en la nube, permite tener releases cada dos o tres semanas. Es un cambio realmente diferencial. Es como competir con distintas armas. Permite actualizar la aplicación y ofrecer nuevos servicios en tres semanas, mientras la otra compañía necesita tres meses.

Las empresas deben plantearse si van a permanecer en un entorno que está abocado a desaparecer

Otra razón añadida está relacionada con que la mayoría de esas aplicaciones se hicieron en los años 70, 80 o 90. La gente se jubila y el conocimiento se pierde. Es muy difícil encontrar profesionales en el mercado que conozcan los lenguajes con los que están escritas estas aplicaciones, como NATURAL, PL1 o Cobol (aunque este último está mucho más extendido). Se puede captar gente de la universidad y formarla, pero ¿cómo los motivas para formarse en NATURAL? Es mucho más atractivo aprender Java, Python u otros lenguajes más interesantes y productivos.

Estos retos están llegando ya a las empresas y la respuesta pasa por evolucionar la aplicación, reescribiéndola a Java nativo o transformándola de alguna forma (rehosting) manteniendo los lenguajes.

¿Qué ocurre si no se hace…, si simplemente se dejan tal cual?

Más allá de las razones anteriores, hay otro tema importante: la capacidad de inversión del proveedor que continúa en un entorno legacy va a depender del volumen de facturación que sea capaz de capturar. A medida que las empresas se salgan de ese entorno, las ventas de este tipo de aplicaciones se reducirán y, por consiguiente, la capacidad de inversión y de innovación va a ser menor.

Las empresas deben plantearse si van a permanecer en un entorno que está abocado a desaparecer, en el que, conforme avance el tiempo, los proveedores van a obtener menos ingresos, lo que se traduce en menor capacidad de inversión y de evolución.

Hay casos que ya son sangrantes, como por ejemplo el de CA, una compañía de software cuya oferta, aunque cuenta con soluciones para sistemas abiertos, está básicamente centrada en entornos legacy. Después de ser adquirida por Broadcom, se tomó la decisión de maximizar la rentabilidad. Claramente, es una empresa en decadencia, que cada vez tiene menos clientes, que cada vez vende menos, y la respuesta está siendo una subida progresiva de los precios. Vende menos, pero lo que vende lo hace a un precio mucho mayor, para mantener el retorno constante a costa de sus clientes.

Si la decisión sobre salir de ese contexto se retrasa, cada vez costará más tiempo y esfuerzo dar el paso. Peligra incluso la supervivencia de la empresa.

¿Cuál es la estrategia adecuada? ¿Industrializar la transformación?

Depende mucho del modelo de transformación. En general, si hablamos de proyectos de rehosting o de rearquitectura, en los que se va a mantener la funcionalidad de la aplicación —tal como está, pero llevándola a un contexto cloud—, es vital que esta transformación se realice del modo más automatizado posible. En nuestra experiencia, esta es una de las claves: hacerlo de forma industrializada, evitando la intervención manual lo máximo posible.

Es clave generar casos de prueba automáticamente y validarlos en el entorno de destino también de forma automática

Hablamos de aplicaciones con millones de líneas de código. Eso no se puede transformar a mano. Hay que automatizar al máximo todo el proceso de análisis del código y de las reglas que hay que aplicar para que pueda ejecutarse correctamente en la nube, y que después se haga el traspaso también de forma automatizada.

A partir de ahí, otra de las claves está en los procesos de pruebas que permitan certificar que la aplicación funciona correctamente en el entorno de destino. En este tipo de proyectos, los casos de prueba son muy diferentes a los que se desarrollan en un mantenimiento evolutivo de la aplicación, ya que hay que tener en cuenta todo el contexto, incluso aquello que no ha sufrido modificaciones desde hace años.

Es muy importante poder generar casos de prueba automáticamente y validarlos en el entorno de destino también de forma automática. La industrialización de la transformación y de las pruebas es un elemento crítico, porque es lo que permite modernizar la aplicación en un tiempo adecuado.

Además, de esta forma también se le asegura al cliente que la aplicación funciona correctamente en el entorno de destino, y que el rendimiento va a ser el adecuado.

¿Cómo se conjuga la necesidad de rendimiento con los microservicios?

Este es un tema que hay que plantear con cuidado en todos los procesos de modernización: el concepto de microservicio. En nuestra experiencia, dar el salto mortal desde una aplicación legacy, que es básicamente un espagueti muy entrelazado con todos sus componentes y su modelo de datos, a un modelo de microservicios es muy complicado. Se puede segregar la aplicación como tal, pero esto puede plantear problemas de rendimiento muy importantes, con tasas inasumibles en un contexto empresarial.

Pongamos el ejemplo de la llamada a un servicio, que en un contexto legacy tarda un microsegundo. Resulta que cuando esa llamada se “apifica” y se lleva a un modelo cloud, es posible que ese tiempo se dilate hasta los cien milisegundos. La incidencia de esta demora dependerá de las veces que se llame al servicio en cuestión. Si se llama una vez, no pasa nada, pero si se llama un millón de veces, los tiempos de respuesta son totalmente inadmisibles: lo que antes se ejecutaba en cinco minutos ahora tarda cuarenta días.

El concepto de macroservicio permite ejecutar en máquinas virtuales cada división funcional de la aplicación

Un paso intermedio sería ir al concepto de macroservicio. A grandes rasgos, se trata de dividir la aplicación en segmentos de mayor envergadura que se ejecuten en distintas máquinas virtuales, que se hacen cargo de cada división funcional de la aplicación. Con esto se consigue simplificar ese “espagueti” entrelazado y resolver algunos de los inconvenientes que puede suponer dar el salto al modelo de microservicios.

Hay que tener muy en cuenta todos los aspectos que intervienen —a todos los niveles— a la hora de convertir un servicio local y cercano en un servicio remoto.

¿Cuál es el camino más recomendable?

Lógicamente, todo depende de las características de cada proceso, pero la forma más fácil de emprender este tipo de transformaciones es hacer lo que se llama un big bang, es decir, mover la aplicación a la nube tal y como está. Es cierto que el cliente puede percibir un mayor riesgo, pero de esta manera se evitan todos los problemas relacionados con los procesos de segregación, de “apificación” para convertir los servicios locales en remotos, de rendimiento…, sobre todo en el período de convivencia de ambos modelos, cuando hay una parte de la aplicación en legacy y otra en la nube.

Lo más fácil es llevárselo todo de una vez. Es el proyecto más sencillo y rápido. Es cierto que hay un riesgo percibido (si algo falla, falla la aplicación completa), pero aquí entra en juego todo lo que hemos mencionado, especialmente una buena estrategia de pruebas de regresión automatizadas, en las que se validan el funcionamiento de la aplicación y el rendimiento de forma completa. Esto es lo que ayuda a introducir un factor de seguridad adicional a la hora de tomar la decisión.

Esta es la estrategia que están siguiendo muchas de las grandes empresas de nuestro país a la hora de enfocar sus proyectos de transformación. Es algo bastante habitual.

Cuando analizas la complejidad que implica hacer una transformación por fases, especialmente en el período de convivencia, el modelo big bang permite completar la transformación en menos tiempo, recuperar antes la inversión y aprovechar rápidamente las ventajas de la nube.

¿Cuáles son los tiempos que se manejan?

Todo depende de la estrategia. Indudablemente, un modelo por fases suele ser un proyecto más costoso en dinero y en tiempo. Dependerá de las fases en las que se vaya a hacer, de la arquitectura de convivencia que se defina… Estaríamos hablando de proyectos de al menos tres o cuatro años.

Por su parte, los enfoques denominados de big bang son proyectos que, en función del tamaño de la empresa y de la aplicación, pueden hacerse en menos de un año, o en dos años cuando se trata de aplicaciones o contextos especialmente complejos.

Por norma general, el proyecto para modernizar una aplicación de tipo medio se puede completar en ocho meses, y se puede ir a dos años cuando hablamos de aplicaciones más grandes, con muchas líneas de código.