Journey to Cloud Tales II – El éxito de la terraza de verano

José María Silva Bravo
Application Engineering Services – Practice Leader SPGI
IBM Consulting

En mi anterior artículo, y primero de la serie Journey to Cloud Tales, expliqué los síntomas y motivos de lo que denomino la Paradoja de la discoteca vacía, un término acuñado en diferentes proyectos e interacciones con clientes y que es relativo al hecho de no poblar una nube a la velocidad y con los beneficios esperados. Pensaba que iba a ser el primero y último de una breve carrera literaria, pero su aceptación ha sobrepasado cualquier expectativa por mi parte; por tanto, amenazo con continuar y acabar la serie.

Hoy planteo diversos enfoques que nos ayudan a prevenir y evitar esa paradoja, enfoque que, evidentemente, también tiene su nombre propio: El éxito de la terraza de verano.

Una terraza de verano es un concepto que tiene un éxito abrumador, y eso que a priori presenta ciertos inconvenientes: las instalaciones y equipamiento suelen ser más incómodos que en un restaurante tradicional, los servicios son menos personalizados, sólo abren en ciertas temporadas y a veces están muy llenos.

Sin embargo, presentan múltiples atractivos: suelen estar localizados en sitios fácilmente accesibles por sus clientes, prestan los servicios que estos quieren y a los que están acostumbrados, se suele servir con rapidez, hay servicios muy básicos o sofisticados; y lo mismo ocurre con los precios: en el mismo establecimiento hay productos asequibles o muy caros.

La misma idea subyace en una transformación hacia la cloud si queremos que sea exitosa: hay que prestar los servicios mínimos que necesitan las cargas y aplicaciones, debe ser relativamente sencillo llegar hasta allí y el servicio prestado debe ser más rápido, eficiente, ampliable y automatizado de lo que es actualmente.

Retomando lo expuesto en el artículo anterior, ¿qué significa eso en términos de mover cargas, desarrollar aplicaciones cloud o mover aplicaciones a la nube?

Movimientos de cargas

Centrándonos solo en los aspectos tecnológicos, existen dos grandes retos a afrontar: la obsolescencia y el grado de acoplamiento entre componentes.

Una de las grandes ventajas de las nubes reside en su estandarización y la automatización que esto permite, pero precisa limitar el soporte a productos y versiones específicas de software, por ejemplo, RedHat Linux 7.9 en adelante.

 Sin embargo, es un hecho obvio el elevado grado de obsolescencia que existe en muchas instalaciones y, si por ejemplo existen servidores RedHat Linux 6.1, actualizar la versión a la existente en la nube no es un proceso sencillo ni trivial. De hecho, precisamente por eso existe la obsolescencia: en algún momento un cambio de versión fue más disruptivo y costoso de lo habitual.

Hay otro factor a considerar: ¿la nube presta el servicio necesario? Por ejemplo, si mi aplicación usa una base de datos MS SQL Server 2019, ¿la nube presta ese servicio específico de base de datos?

Por eso es más recomendable que nunca realizar un análisis de costes y beneficios. Para ello la mejor opción es realizar un descubrimiento exhaustivo de todos los componentes de infraestructura software y de las relaciones entre ellos.

El análisis de los datos resultados de este descubrimiento es el que va a permitir responder a:

• ¿Qué componentes y versiones exactas estoy usando?
• ¿Cuál es mi grado de obsolescencia?
• ¿La nube objetivo presta los servicios específicos demandados por las cargas?

La respuesta a estas preguntas nos lleva a obtener la información buscada:

• Cuántas cargas se pueden llevar directamente o con un coste mínimo a la nube.
• Qué costes tendré y qué beneficios reales voy a obtener si muevo estas cargas.
• En caso de no justificarse por sí mismo, si se realizara algún tipo de modernización en la aplicación, ¿se incrementarían los beneficios a obtener?

Olas de modernización a cloud

Pero esto es solo la primera parte (y la más fácil) de la ecuación. ¿Puedo llevar los componentes de forma individual o existen relaciones entre ellos que obligan a hacerlo de manera conjunta?

Por ejemplo, ¿qué pasa si me llevo una aplicación a un datacenter en Reino Unido, pero dejo los datos en España? Seguramente la distancia física introducida provocará problemas de latencia en el acceso a esos datos.

¿O si existen conexiones directas internas entre bases de datos que son transparentes a las aplicaciones que las usan? (por ejemplo, los muy usados dblink). Un movimiento parcial aquí provocaría múltiples fallos en cadena.

Esto obliga a que los movimientos de cargas a la nube deban realizarse en grupos (normalmente denominados olas), moviéndose de forma unida todos los componentes interrelacionados.

Sin embargo, esto es más fácil de decir que de hacer. ¿Cómo identifico cada ola y sus componentes? ¿Cómo identifico las relaciones con componentes de otras olas? ¿Qué hago con esas relaciones?

En este caso, el inventario y descubrimiento realizado como punto de partida es un elemento necesario, pero no suficiente; deben aplicarse otro tipo de mecanismos que ayuden a determinar el contenido de cada ola. Pero esto… lo veremos en el siguiente capítulo.

Desarrollo de aplicaciones cloud nativas

Vayamos subiendo de dificultad… ¿Cómo empezamos a tener aplicaciones que saquen valor añadido real de las capacidades de una nube?

Como comentábamos en el artículo anterior, en los últimos años se han desarrollado aplicaciones que hacen uso de servicios de gran valor añadido (Machine Learning, Analítica Avanzada, RPA, etc.), pero aún se trata de un número pequeño y normalmente son sistemas desconectados de las aplicaciones corporativas, muchas veces comunicándose mediante el muy novedoso sistema de intercambio de ficheros.

Y, por el moment,o no se observa de manera extendida la existencia de arquitecturas aplicativas capaces de hacer un uso óptimo de las capacidades de una nube híbrida y multicloud.

De hecho, diseñar e implementar una arquitectura híbrida multicloud no es un proceso trivial; por ejemplo, una cosa es publicar y suscribirse a eventos, y otra habilitar una arquitectura reactiva que procese miles de mensajes por segundo y vaya más allá de los límites físicos de escritura en disco.

En un contexto donde encontrar un desarrollador de microservicios es un reto imposible, ¿cuántos arquitectos empresariales existen capaces de entender y resolver la complejidad de este tipo de arquitecturas novedosas? Y, ¿cuánto tiempo es necesario para habilitar una arquitectura cloud completa? ¿y para que la globalidad de la comunidad técnica la entienda y la convierta en productiva?

La magnitud del reto es tan enorme que solo existe la forma tradicional de acometerlo: imaginar la foto global y luego ir resolviendo el puzzle priorizando por partes y de manera iterativa.

Para ello, existen una serie de pasos recomendables:

• Identificar todos los “Building Blocks” o componentes de la nueva arquitectura y priorizarlos de acuerdo con las necesidades de la organización.
• Definir los parámetros que permitirán empezar a aterrizar esos componentes:
  • Decisiones sobre los componentes de base que será necesario adquirir o implantar: stack tecnológico, API’s managers, gestores de eventos, etc.
  • Identificar los diferentes patrones de aplicaciones que será necesario resolver: por ejemplo, microservicios con base de datos no relacional comunicándose mediante API’s Rest y Eventos.
• Priorizar los “Building Blocks” de acuerdo con los patrones a resolver y definir un plan de implementación iterativo.
  • Un hecho obvio, pero normalmente olvidado, es que muchas tareas se pueden lanzar de inmediato sin necesidad de complejos procesos de decisión. Por ejemplo, que se necesita seguridad es obvio, la discusión es sobre la mejor forma de implementarla técnicamente, no si hace falta.

Enfocándolo así, el proceso es más sencillo de lo que parece y permite ir proporcionando resultados según lo vayan requiriendo los equipos de trabajo y las aplicaciones. De nuevo, y por intentar mantener el interés, este tema lo detallaremos en siguientes capítulos.

Modernización de aplicaciones a cloud

Aunque esto de nuevas aplicaciones cloud parece complicado, pasemos a la complejidad real: ¿cómo modernizo aplicaciones existentes que funcionen en la cloud y hagan uso real de sus capacidades?

Es casi una ley de la física en informática: mantener o modernizar una aplicación es mucho más difícil y costoso que hacerla nueva desde cero.

E intentar mover directamente una aplicación a la nube es como querer que un coche vuele y para eso ponerle alas. Mo solo no va a volar, sino que irá más lento porque las alas chocarán con los obstáculos de la carretera.

En este punto, es importante distinguir entre aplicaciones normales y el santo grial de la modernización: los sistemas complejos como los mainframe Z o los IBM I que demandan y obviamente tendrán su propio capítulo.

Hablando de modernizar aplicaciones, la experiencia nos recomienda tener en cuenta las diferencias de paradigmas tecnológicos:

• La cloud está pensada para la automatización máxima, donde las aplicaciones escalan horizontalmente, están compuestas por servicios desacoplados, delegan funciones en servicios de la propia cloud y usan protocolos de comunicación estándar.
• Por el contrario, las aplicaciones tradicionales suelen ser de gran tamaño, escalan verticalmente, están muy acopladas, resuelven por sí mismas todas sus necesidades y se comunican mediante protocolos muy eficientes normalmente no soportados en la cloud.

Otro aspecto a considerar reside en que hablar de modernización de  aplicaciones implica hablar de cientos de aplicaciones, decenas de miles de objetos software, millones de líneas de código, diferentes capas aplicativas y desarrollos en diferentes etapas del tiempo. Por tanto, intentar acometer estos proyectos a mano es una tarea imposible.

La experiencia muestra que para afrontar esta situación es necesario realizarla desde dos vertientes complementarias:

1. Análisis quirúrgico de la arquitectura de las aplicaciones, centrado en aquellos aspectos que faciliten o dificulten la modernización.
2. Análisis automatizado de todos los componentes software y de las relaciones entre ellos, detectando lo que se denominan barreras y aceleradores en la modernización. Un factor favorable es que estas barreras suelen ser siempre las mismas y se repiten en múltiples partes de las aplicaciones; dada una solución, puede replicarse o invocarse las veces que sea necesario.

Estos análisis permitirán responder a las grandes preguntas necesarias para saber si se puede modernizar y el esfuerzo necesario para ello:

• ¿Cuáles son los principales patrones de arquitectura de aplicaciones existentes?
• ¿Es necesario o recomendable realizar cambios en componentes base? (bien por aspectos técnicos, bien por motivos económicos y ahorro de licencias)
  • ¿Migrar de servidor de aplicaciones pesado a servidor de aplicaciones ligero para que el contenedor pueda funcionar?
  • ¿O de tipo de bases de datos?
• ¿Existe posibilidad de crear piezas de arquitectura que den solución común y eficiente a las barreras detectadas?
• Los componentes base (base de datos, servidor de aplicaciones, etc.), ¿tienen soporte en la cloud objetivo?
• ¿La aplicación gestiona la sesión de los usuarios (statefull) o delega en sistemas externos (stateless)?
• Las aplicaciones incorporan dependencias de:
  • Servidor de aplicaciones.
  • Versiones del lenguaje de programación.
  • Procedimientos almacenados en las bases de datos.
  • Librerías open-source.
• ¿Cuál es el tamaño y consumo de recursos de las aplicaciones?
• ¿Existen protocolos de comunicación no soportados en la nube?
• ¿Se usan direcciones directas o locales de directorios o ficheros?
• ¿Se usan urls y protocolos no securizados?
• ¿Puedo llevarlo todo a la vez o necesito definir olas como en el caso de las cargas contemplando las dependencias entre ellas? (la respuesta es obvia).

Estimación de esfuerzos y plazos

Esta información permitirá conocer todos los puntos a modificar, pero aún queda otra gran respuesta: ¿cuál es el plazo y el esfuerzo necesario para llevar estas aplicaciones a la cloud?

Esta estimación no es trivial y puede llevar a grandes desviaciones en tiempo y coste de los proyectos. La experiencia muestra que la única manera de realizar a priori una estimación adecuada se basa en varios aspectos:

• Categorización y clasificación de las aplicaciones:
  • Patrones de arquitectura de las aplicaciones: Número de capas, servidor de aplicaciones, base de datos, lenguaje, etc.
  • Tamaño y consumo de recursos.
  • Número de barreras y su criticidad.
  • Número de aceleradores y su importancia.
• Identificación y estimación de piezas arquitecturales comunes que den respuesta a las barreras identificadas.
• Uso de tallas preestimadas para los diferentes patrones de aplicaciones detectados (obviamente, esto es la fórmula secreta del proceso).
  • Contemplar la casuística de “no hay talla” para aplicaciones que se salen de los umbrales y deberán analizarse de manera individualizada.
• Realización de pequeñas pruebas de concepto que validen la estimación para cada uno de los patrones.
• Y, muy importante, incorporar en el proyecto etapas de análisis detallado y reestimación que permitan adaptarse a lo largo del mismo.

Ya sabemos lo que tenemos que hacer, sabemos que tenemos que hacerlo en una serie de olas, hemos estimado el esfuerzo… Ahora toca preguntarse: ¿cómo defino esas olas? ¿Cómo modernizo? ¿Y quién lo hace? La respuesta, en los siguientes capítulos.