Conecta con nosotros

Opinión

Journey to Cloud Tales IV: ¿Arquitecturas elegantes como paradigma GreenIT?

Publicado el

Aunque en el anterior artículo de la serie Journey to Cloud Tales III – CUMULUS ¿cómo se crean las nubes? indiqué que el siguiente capítulo sería relativo a la modernización de aplicaciones mainframe, la importancia que está cogiendo la sostenibilidad y todo lo relativo a Green IT me ha hecho alterar el orden de la serie e incorporar un capítulo específico en este aspecto. 

El surgimiento de las arquitecturas elegantes

Es curioso observar que, desde el punto de vista de la sostenibilidad, la situación que vivimos actualmente en el mundo tecnológico se parece extraordinariamente a la revolución industrial del siglo XIX. En ese siglo, la aparición de nuevos métodos y tecnologías de fabricación produjo una explosión de la capacidad productiva y un gran consumo de materias primas, así como una alta contaminación.

Lo mismo está ocurriendo tecnológicamente ahora, pero mucho más acelerado por la famosa Ley de Moore (cada dos años se duplica la potencia de computación): hemos pasado de un consumo limitado de tecnología a una revolución que demanda un elevado consumo energético, genera una gran huella de carbono y un enorme coste económico.

Para comprender la situación actual podemos dividir la historia de la informática en tres etapas cronológicas. Desde la Prehistoria de la cultura de la eficiencia se pasó sin transición a la Era moderna de la computación sin límites. Y en estos momentos, por políticas de responsabilidad corporativa y presiones de costes, está comenzando la evolución hacia lo que podemos denominar El surgimiento de las arquitecturas elegantes.

Prehistoria de la cultura de la eficiencia

Durante muchos años, la falta de recursos produjo que los sistemas y aplicaciones se diseñaran con un enfoque de eficiencia máxima. Durante muchos años, un sistema transaccional de una corporación tenía 32 megas de memoria para software base y aplicaciones, y la interfaz de usuario se realizaba sobre terminales tontos, con nula capacidad de proceso, adonde se enviaban solo los cambios de caracteres.

Esto hacía que se trabajara, y aun se haga en algunos equipos, bajo paradigmas de eficiencia máxima. Por ejemplo, es habitual en arquitecturas mainframe recompilar la arquitectura cuando sale una nueva versión del lenguaje para adaptar el espacio que ocupa su ejecutable en disco y en memoria; mínima ganancia en bytes que, multiplicada por millones de ejecuciones diarias, redunda en un elevado ahorro de memoria y en una mejora muy significativa del rendimiento. 

Y esta eficiencia se trasladaba al resto de elementos; por ejemplo, en los centros de proceso de datos, existían jardines con fuentes de agua cuya principal función era ayudar a la refrigeración y reducir la necesidad de energía; de hecho, algunas eran hasta bonitas. 

La era moderna de la computación sin límites

Entonces llegó el PC, permitiendo separar las aplicaciones en capas y ejecutar cada capa en un sistema diferente. Y, gracias a la Ley de Moore, cada tipo de sistema fue multiplicando su capacidad de computación año a año permitiendo incorporar tratamientos más masivos e interfaces de usuario mucho más potentes.

Pero ¿por qué no tener un lenguaje de programación que permita ejecutar la misma aplicación en cualquier sistema operativo? Así surgió Java; además de incorporar la programación orientada a objetos, lleva embebido su propio runtime, que le permite ejecutar en diferentes plataformas.

El paso siguiente era obvio: si estábamos reutilizando el runtime, ¿por qué no hacer lo mismo con lógica, utilidades o imágenes ya preconstruidas? Esto llevó a la reutilización masiva de librerías de código y su incorporación a la aplicación, redundando en una aplicación aún más grande y, con ello, más demandante de energía. 

Este fue un punto de inflexión crítico en relación con la sostenibilidad. Las aplicaciones pasaron a ser mucho más grandes al empaquetarse con la mochila del runtime y múltiples librerías, precisando mucha más potencia, memoria y, de paso, un consumo energético mucho mayor. 

Y, entonces, llegó Internet y las intranets,  con lo que las aplicaciones pasaron a tener un número muy superior de usuarios, lo cual introdujo de repente un momento de duda generalizado: 

  • Estas aplicaciones consumían muchísimos recursos y no podían monitorizarse al mismo nivel que las anteriores. 
  • La estabilidad de las nuevas plataformas estaba muy lejos de la que proporcionaban los sistemas anteriores. 
  • No existía predictibilidad de la carga; se sabía y se sabe que un mainframe es capaz de funcionar al 100% de carga de manera estable indefinidamente, pero los nuevos sistemas sufrían una volatilidad enorme sin causas aparentes. 

Afortunadamente, teníamos la solución: añadamos más servidores en paralelo para ser capaces de adaptarnos a variaciones (suena a escalabilidad horizontal, ¿no?).

Con lo cual, se pasó a un escenario en el cual el sistema central ocupaba un armario (bueno, dos para tener redundancia) y el resto de los sistemas ocupaban una planta entera de un edificio llena de racks de servidores que, evidentemente, consumían mucha energía y con unas grandísimas necesidades de refrigeración.

Pero, entonces, llegaron la analítica avanzada y las nubes 

En paralelo, se multiplicó el volumen de datos a gestionar abriendo nuevas posibilidades de negocio (¿os suena Google?). Estos adolecían de falta de potencia de cálculo, sistemas de bases de datos especializados y algoritmos adecuados para procesar este volumen de datos.

Aquí la revolución surgió a dos niveles:

  • Abandono del antaño todopoderoso esquema relacional y aparición de nuevas estructuras de datos más adecuadas.
  • Aparición de nuevos algoritmos matemáticos y de Inteligencia Artificial para el procesamiento de grandísimos volúmenes de datos. 

Ambos aspectos demandan una potencia de cálculo enorme; de hecho, se estima que los algoritmos de IA duplican su necesidad de potencia cada 5 meses. En este esquema, la aparición de las nubes (públicas o privadas) fue la solución perfecta:

  • Hay centros de procesos de datos ultra eficientes distribuidos por todo el mundo.
  • Disponen de una capacidad de procesamiento casi ilimitada contratable a demanda.
  • Permiten contratar servicios de procesamiento analítico de datos como un servicio sin necesidad de ser desarrollados o mantenidos por cada organización.
  • Habilitan sistemas de alta disponibilidad mediante escalabilidad horizontal, replicación continua de datos entre CPD (centros de procesamiento de datos), etc.  

Obviamente, estos sistemas demandan un elevado consumo energético y de refrigeración que se une al de los usuarios y sistemas que siguen residiendo en sus plataformas tradicionales. 

Y llegamos a hoy con un crecimiento exponencial de la potencia energética consumida por los CPD (se estima un 43% los 3 últimos años). Si añadimos el consumo de los usuarios, se puede estimar que las TIC demandan actualmente en torno a un 5%-6% del consumo energético mundial. Esperándose mantener este crecimiento exponencial en los próximos años.

Pero bueno, el coste de la energía era razonablemente asequible y no era un asunto de preocupación para las organizaciones. Excepto por las políticas de responsabilidad corporativa, específicamente en la contaminación derivada de la impresión. Y, de repente, todo ha cambiado: el coste de la energía se ha disparado. Y se une a que el verano de 2022 fue extremadamente caluroso y se multiplicó la necesidad de refrigeración en los CPD (alguno estuvo cerca del colapso).

El surgimiento de las arquitecturas elegantes

De esta forma, lo que hasta entonces no importaba, pasó a convertirse en una prioridad que, además, se alinea perfectamente con las políticas de responsabilidad corporativa de las organizaciones orientadas a colaborar contra el cambio climático. Así, adquiere importancia el concepto de GreenIT: diseño y uso de tecnología orientada a reducir costes y a colaborar contra el cambio climático y con las políticas corporativas. 

Cabe pues preguntar: ¿Y ahora qué? ¿Usamos el lenguaje de programación más eficiente que vemos en benchmarks de internet? ¿Nos basta con llevar las aplicaciones a una nube pública?

Lamentablemente, no es todo tan sencillo. Se trata de un problema con muchas aristas pero que, como siempre, demanda un enfoque de arquitectura empresarial.

Y aquí surge un concepto muy interesante y con un nombre muy bonito: las arquitecturas elegantes, que hacen referencia al diseño y construcción de arquitecturas empresariales orientadas a la eficiencia máxima en el consumo de recursos y, por tanto, a reducir al mínimo la huella ecológica y los costes económicos atribuibles a la tecnología. En pocas palabras, se trata de volver a la cultura de la eficiencia.

Este tema da para varios libros, pero al menos incluyo aquí algunas reflexiones sobre las dimensiones que debe contemplar una arquitectura elegante, en muchos de los cuales un enfoque de nube híbrida puede jugar un papel destacado:

  • Usuarios finales: parece razonable considerarles teniendo en cuenta que el 40% del consumo total de energía, y puede que un porcentaje mayor de la huella de carbono por la contribución de la impresión, es atribuible a ellos. Entre otras acciones, hay que considerar que un PC es como un electrodoméstico que consume más o menos según su antigüedad. Por lo tanto, es recomendable hacer uso de ordenadores eficientes con políticas de gestión energética y de impresión incorporadas en sus maquetas.
  • Aplicaciones: como siempre, son la clave. Si la aplicación no está bien diseñada y construida, es inútil todo lo demás. Y no se trata solo de eliminar las mochilas, se trata de diseñarlas modularmente con seguridad, escalabilidad y aislamiento por diseño. Por no hablar de buenas prácticas, experiencias de usuario optimizados, uso del lenguaje más adecuado y la complejidad y lógica de cómo se programa.
  • Datos operacionales e informacionales: grandes sospechosos de este crecimiento en el consumo energético y la huella de carbono asociada. Es muy recomendable la aplicación de buenas prácticas y optimización continua de los algoritmos analíticos y de IA, patrones de dato congelado y dato vivo, replicaciones, etc. Curiosamente, mientras en otros sectores TI las pruebas de rendimiento y optimización de los algoritmos son un elemento básico, en el caso de los sistemas analíticos son aún escasas las organizaciones donde se aplican este tipo de pruebas.
  • Software y hardware base: suelen presentar una elevada obsolescencia, basados en arquitecturas monolíticas y sobredimensionados en su capacidad. 
  • Centros de Procesos de Datos: no creo que podamos volver a construir fuentes, pero al menos construyámoslos en zonas geográficas que reduzcan la necesidad de refrigeración, sean autosuficientes en la generación y consumo de energía y hagan un uso óptimo de la capacidad y de la compartición de recursos. Y qué decir del Modelo Operativo, incorporando prácticas de automatización máxima: DevOps, Observabilidad, BPO, Chatbots, etc.

Por cierto, el siguiente artículo sí será relativo a modernización de aplicaciones mainframe.

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

El equipo de profesionales de MCPRO se encarga de publicar diariamente la información que interesa al sector profesional TI.

Lo más leído