Cómo las Arquitecturas de Microservicios están impulsando la Transformación Digital
Fernando Merino Blanco
Silvia Lusarreta Ruiz
INTRODUCCIÓN
Se ha hablado del potencial de la IIoT (Industrial Internet of Things) como herramienta de transformación digital para las empresas del sector de la Energía [1], y se ha esbozado la arquitectura de implementación de la IIoT en sus aspectos más generales según el siguiente esquema:
En la arquitectura del IIoT normalmente se consideran tres niveles:
- Nivel de campo (edge), situado junto a los activos físicos
- Nivel de plataforma (nube o cloud), virtual, deslocalizado.
- Nivel de empresa, aplicaciones corporativas, interacción con usuarios.
Este artículo, se focaliza sobre el nivel de plataforma (o nivel intermedio), sobre el que se intentarán aclarar algunos de sus conceptos fundamentales. El motivo para dedicar este monográfico a la arquitectura de las plataformas IIoT proviene directamente de la experiencia de Minsait. Si bien los otros dos niveles (campo y empresa) han supuesto cambios sustanciales respecto del tratamiento de la información que se venía haciendo anteriormente, resulta relativamente directo explicar las novedades introducidas, quizá porque se trata de dos ámbitos más tangibles en los que, en general, la mayoría de los interlocutores tiene algún grado de experiencia.
Sin embargo, ya sea por ser el nivel plataforma más abstracto o también por la increíble velocidad de los cambios tecnológicos que se registran en este campo, resulta mucho más complicada su exposición y la confusión que, en general, se percibe es muy superior a la percibida en los otros dos niveles. Por tanto, el objetivo del artículo será aclarar algunos de los conceptos básicos y exponer de forma razonada las soluciones que se han venido adoptando a un público que no tiene por qué ser necesariamente especialista en el área de las Tecnologías de la Información.
Como normalmente ocurre en estos casos, navegamos en un maremágnum de términos que, si no son comprendidos al menos en esencia, suponen una barrera de entrada importante.
El resto de la exposición se dedica en exclusiva a intentar desvelar de forma sencilla la mayoría de los términos anteriores y servir de esta forma como una primera introducción al mundo de las plataformas digitales.
DOS TENDENCIA (CASI) INDEPENDIENTES
En la evolución del software hacia las plataformas digitales hay dos vectores de evolución que podríamos considerar perpendiculares:
- Localización de la capacidad de computación
- Arquitectura de las aplicaciones
En esencia se trata de dos tendencias independientes que, en ocasiones, se confunden. Se analizan a continuación por separado.
Localización de la capacidad de computación
Conceptualmente la localización de las máquinas sobre las que reside la computación no ofrece grandes dificultades: o se encuentran localizadas en las instalaciones del cliente o remotamente en las instalaciones del proveedor del servicio. El modelo tradicional ha sido disponer de las máquinas en local si bien la oferta de servicios de computación remotos (en la nube) ha ido mejorando y ampliando su oferta y en este momento se ve ya como una práctica habitual en la industria.
No obstante, hay una terminología al respecto que es necesario explicar:
- On-premise (local): Modelo tradicional con la infraestructura (servidores, equipamiento de conexión) en local. Requiere mantenimiento y servicios adicionales (aire acondicionado, etc.)
- On-cloud (en la nube): La infraestructura se localiza remotamente y el acceso a la misma tiene lugar a través de Internet. Esta opción admite varias variantes:
- IaaS (Infrastructure as a Service o Infraestructura como Servicio): proporciona los servicios de infraestructura (servidores, equipamiento de conexión) en la nube, en forma física o virtualizados (es el caso más frecuente). Una máquina virtual es un programa que se comporta como un ordenador (invitado) y funciona dentro de otro ordenador (anfitrión). Es como ejecutar un ordenador (invitado) dentro de otro ordenador (anfitrión). Dentro de un anfitrión y dependiendo de la capacidad pueden coexistir varios invitados, cada uno de ellos con su sistema operativo y sus propios programas, de forma independiente y sin interferirse. Este hecho se facilita por la flexibilidad en la especificación de recursos que se tiene en el momento de crear las máquinas virtuales (en términos de CPU y almacenamiento de disco, fundamentalmente). Normalmente, los servicios cloud ofrecen a los clientes únicamente máquinas virtuales que, finalmente, acaban siendo ejecutadas en servidores reales que son completamente transparentes. Ejemplo: El servicio de alquiler de máquinas de Azure, AWS o Google Cloud.
- PaaS (Platform as a Service o Plataforma como Servicio): Adicionalmente al nivel IaaS, el nivel PaaS proporciona servicios software (sistema operativo, bases de datos, herramientas de desarrollo…) para que el usuario pueda desarrollar sus propias herramientas. También puede proporcionar servicios software adicionales (colas de mensajes, etc.). Ejemplo: La plataforma IIoT GE-Predix
- SaaS (Software as a Service o Software como Servicio): En este caso el proveedor da el servicio completo sobre el software al usuario y las actualizaciones/evoluciones son completamente transparentes para éste. Ejemplo: El servicio de correo electrónico Gmail de Google.
En el caso de los servicios en la nube se aprecia como las diversas variantes se diferencian en el nivel de servicios que presta el proveedor, desde el mínimo (IaaS) hasta el máximo (SaaS).
Arquitectura de las aplicaciones
Los cambios que se están registrando no tienen que ver únicamente con la localización de los servicios de computación si son locales o remotos. Una transformación más profunda se ha venido gestando y está siendo ampliamente utilizada en el actual contexto: la arquitectura de microservicios.
Un microservicio es un proceso autocontenido que proporciona una función de negocio única. Diferentes microservicios trabajan en paralelo para constituir un sistema más grande. Los microservicios no se crean en capas como algunas de las arquitecturas tradicionales de sistemas, sino que se crean en torno a funciones de negocio. Los microservicios se comunican entre sí a través de los mensajes que intercambian, de modo que el conjunto resulta menos acoplado y es más fácil de parcelar. No es sencillo entender las contribuciones que suponen todos estos cambios si no se tiene en la cabeza cuál es el origen de todo esto. Es necesario recapitular cómo se ha llegado hasta aquí…
En los inicios de la ingeniería del software, si alguien quería desarrollar una aplicación informática, era necesario codificar en algún lenguaje de programación y después compilarlo para llevarlo al ordenador.
En proyectos grandes, el código se estructuraba modularmente para facilitar el desarrollo y el mantenimiento. Los módulos son trozos más pequeñas del código que se focalizan en funcionalidades individuales. Estos módulos, además, podían ser reutilizables y ser empleados en otros proyectos. En cualquier caso, se sigue hablando de una única aplicación (un único ejecutable), lo que también se conoce como una aplicación monolítica.
En el siguiente capítulo de la historia, las aplicaciones pasan de estar instaladas en la máquina del usuario a estar instaladas en un servidor remoto centralizado (aplicaciones web). Los usuarios se comunican con los servidores web usando un navegador e intercambiando ficheros HTML. El usuario no necesita en su ordenador otra aplicación que no sea el navegador para interaccionar con el servidor web. Pero no ha habido ningún cambio en la estructura de la aplicación.
Desde su aparición, las aplicaciones web han ido incrementando enormemente su funcionalidad y capacidades lo que ha supuesto un crecimiento también de su complejidad (motores de búsqueda, e-commerce, vídeo on-line, etc.). Esta gran complejidad supone un alto coste a la hora de mantener o evolucionar estas aplicaciones, que siguen siendo aplicaciones monolíticas (al final hay un único ejecutable).
Por ejemplo, si se quiere modificar una pequeña parte de un módulo en una aplicación monolítica, es necesario volver a verificar el funcionamiento de toda la aplicación en su conjunto, pues al tratarse de un único ejecutable, no se puede estar 100% seguro de que otras partes de la aplicación no hayan sido afectadas por un potencial error.
Otro punto conflictivo con las aplicaciones monolíticas tiene que ver con su escalabilidad en función de la demanda que reciban. En una aplicación de comercio electrónico, por ejemplo, cuando se producen puntas de demanda (por ejemplo, en rebajas) se puede incrementar el número de servidores en la nube para atenderlas (escalado). Pero si se analiza más detalladamente, se ve que no todas las funciones van a ser requeridas en la misma medida y, en aplicaciones monolíticas, al efectuarse el escalado sobre el número de servidores el resultado es un incremento, exactamente en el mismo factor, para todas las funciones de negocio, estén estresadas o no. Claramente esto supone una pérdida de eficiencia.
En algún momento surgió una nueva idea: por qué no dividir la aplicación global en varias mini-aplicaciones (microservicios) e instalar cada una de ellas en un servidor diferente. Los servidores se comunicarán entre ellos mediante mensajes y el conjunto se comportará funcionalmente como la antigua super-aplicación monolítica.
Se puede ver que esta nueva arquitectura resuelve, entre otros, los dos problemas detectados anteriormente:
- La modificación de una pequeña parte del código sólo afecta ya a un ejecutable que reside en un servidor independiente, con lo que es mucho más manejable, por ejemplo, a efectos de validación o implantación
- El problema de la escalabilidad se puede resolver sin más que escalar aquellos servidores que soporten las mini-aplicaciones que estén más demandadas sin afectar a las que tienen menor carga.
¿Cómo se implementa esta arquitectura de microservicios de forma práctica? Una primera opción sería implementar cada uno de estos servicios sobre un servidor físico en la nube. Claramente esta opción no va a ser óptima, porque es posible que muchos de los microservicios sean pequeños y no necesiten ni mucho menos ni la CPU ni el almacenamiento en disco que un servidor suele ofrecer. Un paso lógico para mejorar la situación sería utilizar la tecnología de máquinas virtuales. Sobre los servidores físicos en la nube es posible crear varias máquinas virtuales y dotar a cada una de ellas de los recursos (CPU, disco) más adecuados para el microservicio que van a albergar. Obviamente, con esta capacidad de graduar los recursos se tiene una situación en la que el aprovechamiento de la infraestructura es mucho mejor. No obstante, la implementación en máquinas virtuales aún admite posibilidades de optimización. Sólo hay que recordar que cada máquina virtual, aun cuando comparte recursos físicos con otras máquinas virtuales, sigue necesitando disponer de un sistema operativo en exclusiva pues, a todos los efectos, se comporta como una máquina física.
Hay un desarrollo tecnológico que ha tenido lugar precisamente para atacar a esta problemática. Se trata de la tecnología de contenedores, que está teniendo actualmente una gran aceptación y se aplica cada vez en más campos. Sin entrar en demasiadas precisiones, se puede definir un contenedor como una máquina virtual que no tiene un sistema operativo propio, sino que utiliza el sistema operativo del anfitrión para las funciones que necesita. Esto supone una gran ventaja en términos de aprovechamiento de los recursos, pues para un microservicio pequeño (y deberían ser siempre lo más pequeños y simples posible) sólo se va a necesitar tener un contenedor muy reducido que puede acabar consumiendo unos recursos muy inferiores a los que necesitaría todo un sistema operativo. Los contenedores se gestionan, a su vez, desde una plataforma de gestión de contenedores donde también es posible monitorizar su consumo de recursos o controlar su escalado.
La división en mini-aplicaciones descrita anteriormente es lo que se conoce como arquitectura de microservicios y presenta una gran cantidad de ventajas, algunas de las cuales ya se han mencionado:
- Independencia de lenguaje: Cada microservicio puede ser programado en un lenguaje diferente en función del tipo de funciones o las librerías disponibles.
- Ciclos cortos de desarrollo/evolución: Dado que los microservicios se dedican a una única función de negocio es posible trabajar en ellos con agilidad y reemplazarlos por nuevas versiones cuando están disponibles sin necesidad de entrar en complejos procesos de implementación.
- Aislamiento de fallos: Los fallos en alguno de los microservicios que integran una aplicación no tienen por qué hacer caer la funcionalidad completa como pasaría en el caso de aplicaciones monolíticas. En este sentido, se aumenta la robustez de las aplicaciones.
- Escalabilidad: Posibilidad de escalar únicamente aquéllos servicios que estén más comprometidos.
Por otro lado, también presentan algunas desventajas:
- Mayor complejidad arquitectural (decenas o centenares de microservicios), lo que obliga a una mayor planificación inicial en términos de las funciones asignadas a cada microservicio y a las relaciones entre ellos.
- Mayor complejidad en las relaciones entre microservicios. Es necesario anticipar cómo se van a comunicar los microservicios entre sí.
- Incorporación de las aplicaciones ya existentes en la nueva arquitectura1. En este punto se plantea la disyuntiva de si las aplicaciones existentes se deben migrar a la arquitectura de microservicios (lo que supone un rediseño total) o de alguna manera es posible integrarlas en la forma en la que ya existen.
En este momento, la gran mayoría de las compañías con interés en la IIoT han diseñado o están diseñando su propia arquitectura de microservicios que sea capaz de cubrir el nivel plataforma. Algunas de ellas son más generalistas y otras están más orientadas al mundo IIoT específicamente.
IIoT en una arquitectura de microservicios
Para finalizar, se van a analizar con más detalle cuáles son los servicios típicos que proporciona una plataforma IIoT tomando como ejemplo la arquitectura de una aplicación desarrollada en el entorno Onesait, de Minsait.
Esta arquitectura está específicamente diseñada para recibir un flujo de datos (por ejemplo, información sobre el funcionamiento de diferentes equipos en un entorno industrial: presiones, temperaturas, vibraciones, caudales, etc.), almacenarlos, procesarlos con diferentes algoritmias que analizan la información con diferentes aproximaciones (análisis predictivos, eficiencia energética, estimaciones sobre el estado de salud de los equipos, etc.) y, finalmente, presentar los resultados a los usuarios. Los principales microservicios que están implicados en este tipo de aplicaciones son:
- Base de datos de series temporales, donde se almacenan las señales que van llegando de campo con su marca de tiempo (timestamp) correspondiente. Puede llegar a ser una base de datos muy voluminosa.
- Base de datos de activos, donde se almacenan en forma jerárquica los activos presentes en las instalaciones, sus características fundamentales y la parametrización de los modelos asociados
- Workers, dedicados a la ejecución de la algoritmia utilizando la parametrización de los modelos y los datos temporales correspondientes a cada activo. Son fundamentalmente los microservicios que se escalan en función de la carga que se registre en cada momento
- Gestor de tareas/colas, se trata de la cola de ejecución de tareas que gestiona la ejecución de los diferentes workers y registra la finalización de las ejecuciones, sea correcta o en fallo.
- Base de datos de alertas-notificaciones, donde se almacenan las alertas/notificaciones que se generan como consecuencia de la ejecución de los diferentes algoritmos
- API Gateway, donde se gestionan las peticiones o llamadas a base de datos procedentes de las interfases de usuario
- Interfases de monitorización y configuración, empleadas por los usuarios con los objetivos de monitorizar los activos objeto de seguimiento o administrar los activos y sus modelos asociados, respectivamente
- Ciberseguridad, dirigido a asegurar la seguridad de todo el conjunto, tanto en accesos como en permisos de ejecución y acceso de los diferentes microservicios
En la arquitectura de esta aplicación desarrollada en Onesait se ha empleado la tecnología de contenedores con el objeto de optimizar los recursos empleados y favorecer la flexibilidad. Un criterio claro de diseño ha sido la compatibilidad con las diferentes alternativas de proveedores de nube existentes en este momento (Azure, AWS, etc.) o los que puedan aparecer en el futuro próximo. Los servicios comerciales que se emplean en Onesait (PostgreSQL, TimeScale, redis, etc.) están disponibles en las arquitecturas actuales o pueden ser fácilmente sustituidos en el futuro si aparecen nuevas opciones con funcionalidades similares. Como ejemplo de la flexibilidad conseguida, la plataforma se puede implementar sobre máquinas físicas on- premise y la configuración es exactamente la misma que se implementa en la nube y se puede migrar indistintamente de una localización a otra. Es necesario subrayar la importancia que se atribuye a la flexibilidad, en un entorno tecnológico que evoluciona a una velocidad altísima y en el que las soluciones tecnológicas nacen con un tiempo de caducidad en torno a los 18-24 meses. En estas condiciones no es aconsejable ligarse de una forma demasiado rígida a ninguna tecnología. La opción de Indra ha sido diseñar una estructura lógica basada en la arquitectura de microservicios y unas interfases entre microservicios que faciliten la conexión no traumática a nuevas tecnologías a medida que vayan estando disponibles.
CONCLUSIONES
En este artículo se ha pretendido explicar, de forma sencilla, la importancia del nivel plataforma en la consecución de los objetivos asociados a la IIoT. Se trata de un asunto de un alto contenido tecnológico pero que es necesario entender, al menos a alto nivel, para poder tomar las decisiones necesarias en cuanto a la implementación de las soluciones. La situación adquiere una mayor complicación si se tiene en cuenta que el entorno tecnológico no sólo es complejo, sino extraordinariamente dinámico y resulta difícil estar al día de la evolución tecnológica aun para los especialistas.
Indra-Minsait es una compañía española dedicada, en gran parte, a la transformación digital de las empresas y que tiene una larga tradición en las áreas de Energía e Industria. La línea de productos en torno a Onesait está en la vanguardia tecnológica en relación con las aplicaciones IIoT y es un facilitador fundamental para el cumplimiento de los objetivos de digitalización de aquellas compañías que deseen avanzar en esta dirección.
REFERENCIAS
- Merino Blanco, Fernando. “Nuevas tecnologías aplicadas al mantenimiento”. 15as Jornadas Técnicas sobre el Mantenimiento en el Sector de la Energía. Oviedo 25-26 octubre 2017.
- The Industrial Internet of Things Volume G1: Reference Architecture, Industrial Internet Consortium, 2017
