Arquitecturas reactivas, claves para la transformación digital

El reto es sencillo de plantear e infinitamente complejo de resolver. “Para mí, la transformación digital no es más que un enorme abismo que existe entre el nivel digital de los usuarios y el de las compañías que les ofrecen servicios.” Con esta peculiar definición arrancó Mario Renau en la escuela Datahack de Madrid en una sesión sobre cómo los programadores deben cambiar su manera de pensar en esta nueva revolución industrial, la cual se alimenta precisamente de unos internautas con unos deseos muy concretos: servicios fáciles de usar y que funcionan las 24 horas del día sin margen de error.

El gran desafío al que se enfrentan los programadores es cambiar su manera de pensar. Renau —actualmente arquitecto digital especializado en internet de las cosas (IoT) de la compañía ferroviaria francesa Alstom, pero con una gran experiencia previa en ‘big data’ para banca— fue constante en repetir un mantra: “La tecnología no es lo que importa”. Lo que importan son, precisamente, los deseos de esos usuarios que quieren servicios cómodos y fiables que además han de estar preparados para escalarse; esto es, soportar un enorme número de clientes simultáneos conectándose desde cualquier dispositivo.

Esta filosofía se conoce en el argot como arquitecturas reactivas. Es decir, cómo se organiza el ‘software’ que gestiona esos servicios que se le ofrecen al usuario. Todo empieza por lo primero que ve el usuario, el interfaz de un ‘app’ o de una web. De ahí tienen que partir las preguntas claves que definirán el resto del ‘software’ a diseñar. “Juega un papel clave porque ayuda a entender cómo hay que hacer esta parcelación de una manera muy coherente, de sentido común. Se parte de qué nos pide el usuario y cómo necesita interactuar con esa información”, asevera Renau.

La diferencia entre las arquitecturas reactivas y lo que había antes, conocido como sistemas monolíticos, es enorme en concepto y en ejecución. Lo normal para una gran empresa en el pasado era que su arquitectura informática estuviera diseñada como un silo, aislada del exterior y diseñada para funcionar a la vez como un organismo muy complejo. Los distintos equipos de programadores a cargo de cada órgano de este gran programa trabajaban simultáneamente, lo que producía que un fallo o retraso en el conjunto los detuviera a todos a la vez.

La arquitectura reactiva jubila este concepto al intentar cumplir con estas metas: dar un servicio al mayor número de usuarios posible y que este nunca se caiga. Esto forzó la invención de microservicios que actúan en paralelo, pero sin depender unos de otros, y que actualizan su información en una suerte de diario de bitácora que permite llevar un registro de todos los cambios según se hacen. Estos sistemas evitan el gran problema para el usuario del siglo XXI y es el dejar de recibir un servicio cuando ocurre un fallo, porque siempre se pueden activar otros microservicios que no dependan de aquel que no puede operar momentáneamente. “Pensad en cuántas veces se os ha caído Netflix u os ha fallado Amazon. Simplemente, no pasa. O no pasa casi nunca”, recordó Renau.

En esta línea, BBVA también trabaja con arquitectura reactiva para proporcionar al cliente la mejor experiencia de usuario posible. Su estrategia se basa en cuatro pilares fundamentales: arquitectura orientada a eventos, de modo que permita reaccionar en tiempo real ante cualquier imprevisto; arquitectura escalable, permitiendo la compartición de recursos para un uso óptimo y compartido; ‘responsive’, conceptualizada para que el diseño de los componentes gráficos se adapte al dispositivo de los clientes y arquitectura tolerante a fallos, centrada en la automatización de los procesos.

Y efectivamente, el mayor reto al que se enfrentan este tipo de construcciones digitales nace precisamente de una de sus fortalezas. El operar de manera independiente lleva consigo una mayor vulnerabilidad a los fallos.

Renau destacó en este punto cómo aborda este problema Netflix con su ‘simian army’ (literalmente, ejército simiesco), una serie de programas automatizados con un solo fin: provocar el caos en la arquitectura reactiva de Netflix . En el post de la compañía que explica la evolución y necesidad de esta herramienta: “La nube va sobre la redundancia y la resistencia al fallo. Como ningún componente puede asegurar estar funcional el 100%, hay que diseñar la arquitectura en la nube de tal manera que los componentes puedan fallar sin afectar la disponibilidad del sistema. Pero diseñar una arquitectura tolerante al fallo no es suficiente. Tenemos que testear constantemente nuestra habilidad para sobrevivir a estos fallos”.  Netflix persigue así esa meta soñada: el servicio que a ojos del usuario no falla jamás porque interiormente se bombardea a sí mismo de fallos.