Arquitectura de microservicios en Outsystems

Introducción

En los últimos tiempos, la actividad de desarrollo de aplicaciones a medida ha experimentado una corriente muy fuerte dirigida a la implementación de arquitecturas modulares basadas en los denominados microservicios. Esta arquitectura es la respuesta a las aplicaciones monolíticas que por su volumen se vuelven difíciles de gestionar. 

Los beneficios de esta arquitectura son muchos -los veremos a continuación- pero también incorpora grandes retos. Estos retos se podrían resumir en un incremento notable de la complejidad del desarrollo. La implementación de esta arquitectura aplica tanto a nuevos desarrollos como a grandes evolutivos/refactorizaciones.

Un análisis de viabilidad del uso de estas tecnologías es conveniente para cada caso con el objetivo de asegurar que los beneficios compensan el incremento de la complejidad y de, por tanto, el coste de desarrollo. En este punto no profundizaremos más dado que no es el objetivo del presente artículo.

Definición de arquitectura de microservicios

Entrando en la definición de arquitectura de microservicios encontramos diversas definiciones para este tipo de arquitecturas. De hecho existen varios modelos para su implementación aunque con factores comunes.

Empezando por una definición de alto nivel nos encontraríamos que, en una arquitectura de microservicios (MSA), los servicios:

  • Suelen ser procesos que se comunican a través de una red para cumplir un objetivo utilizando protocolos agnósticos de tecnología como HTTP.

  • Se organizan en torno a las capacidades del negocio.

  • Pueden implementarse utilizando diferentes lenguajes de programación, bases de datos, hardware y entorno de software, dependiendo de lo que mejor se adapte.

  • Son de pequeño tamaño, con capacidad de mensajería, limitados por contextos, desarrollados de forma autónoma, desplegables independientemente, descentralizados y construidos y liberados con procesos automatizados.

Una consecuencia (y razón de ser) de seguir este enfoque es que los microservicios individuales pueden escalarse individualmente. Con los microservicios, sólo el microservicio que soporta la función con limitación de recursos necesita ser escalado, proporcionando así beneficios de optimización de recursos y costes.

Este planteamiento presenta una serie de ventajas también a nivel metodológico y organizativo:

  • Se presta a un proceso de desarrollo de software de entrega continua: Un cambio en una pequeña parte de la aplicación sólo requiere reconstruir y volver a desplegar uno o un pequeño número de servicios.

  • Se adhiere a principios como las interfaces de grano fino (para servicios desplegables de forma independiente), el desarrollo orientado al negocio (por ejemplo, el diseño orientado al dominio).

A continuación se muestra un diagrama representativo de una arquitectura a alto nivel de microservicios y otra monolítica tradicional.

Beneficios

Por tanto, los beneficios de utilizar esta arquitectura se podría resumir de la siguiente manera:

  • Modularidad: Esto hace que la aplicación sea más fácil de entender, desarrollar y probar, y que sea más resistente a la erosión de la arquitectura

  • Escalabilidad: Dado que los microservicios se implementan y despliegan de forma independiente, es decir, se ejecutan dentro de procesos independientes, pueden ser supervisados y escalados de forma independiente

  • Integración de sistemas heterogéneos y heredados: los microservicios se consideran un medio viable para modernizar las aplicaciones de software monolíticas existentes tanto completamente como parcialmente/incrementalmente. 

Desarrollo distribuido: paraleliza el desarrollo al permitir que pequeños equipos autónomos desarrollen, desplieguen y escalen sus respectivos servicios de forma independiente.

Inconvenientes

El enfoque de microservicios también presenta una serie de problemáticas asociadas que hay que evaluar:

  • Los servicios forman barreras de información, cada servicio maneja su información y debe intercambiarla con el resto de servicios en caso de ser necesario.

  • Los mensajes entre servicios sobre la misma red tienen un coste mayor en términos de latencia y tiempo de procesamiento de mensajes comparado con un proceso de servidor monolítico. 

  • Las pruebas y el despliegue son más complicados en el modelo de microservicios. 

  • Mover responsabilidades entre servicios es difícil. Puede requerir comunicación entre distintos equipos, reescribir funcionalidades en diferentes lenguajes o cambiar la funcionalidad para que funcione en otra infraestructura. 

  • Contemplar el tamaño de los servicios como el principal mecanismo de estructuración puede llevar a utilizar demasiados servicios cuando una estructura de modularización interna puede llevar a un diseño más simple.

¿Cómo da respuesta Outsystems este tipo de arquitectura?

Con la liberación de la versión 11 de Outsystems (en adelante, OS11) se incorporó un nuevo elemento denominados Servicie Actions que implementan el funcionamiento de microservicios como una evolución natural de la plataforma que hasta el momento únicamente utilizaba Server Actions. El funcionamiento es muy similar con la diferencia que la comunicación en realidad se realiza mediante servicios REST de acuerdo al modelo de microservicios. A partir de esto, Outsystems se encarga de la misma manera de la gestión de la comunicación, actualizaciones de la API, evaluación de consistencia entre servicios y un largo etcétera.

En la imagen se puede ver cómo se crea un microservicio (Service Action en OS11) y cómo se gestionan sus dependencias de forma análoga al funcionamiento de las ya existentes Server Actions. Las Service Actions deben estar ubicadas en Service Modules y Service Applications que son elementos también incorporados en OS11.

Cómo gestiona OS los beneficios del uso de microservicios

A continuación exponemos cómo implementa y gestiona la plataforma OS los beneficios y características de los microservicios aportando mecanismos facilitadores y aceleradores para ello.

Modularidad: Diseño y planificación de la arquitectura 

Uno de los principales problemas de la implementación de arquitecturas de microservicios es que habitualmente existe escasa planificación inicial en cuanto al diseño y acotación de cada microservicio lo que habitualmente implica refactorización durante el proceso de desarrollo para reubicar y modificar la arquitectura.

En este sentido, OS promueve con mucho énfasis el diseño de aplicaciones modulares aportando una metodología propia basada en capas denominada Architecture Canvas que permite hacer una correcta planificación de la solución desde el inicio. Además aporta herramientas de soporte y monitorización (Architecture Dashboard, Discovery, etc.) y mucha documentación para formación de los diferentes perfiles del equipo de desarrollo (Arquitectos, Tech Leads, Desarrolladores, UX, etc) tanto para el diseño de la arquitectura como para la implementación de la misma. Estas herramientas permiten visualizar los microservicios ver la relación entre ellos, identificar buenas y malas prácticas en la comunicación y en su estructura y componentes, entre otras cosas.

Escalabilidad

Debido a su naturaleza poco acoplada, el uso de Service Actions permite manejar carga adicional escalando su servicio a través del despliegue de contenedores. Las peticiones al servicio se distribuirán entonces entre los distintos contenedores. Indicar que el despliegue en contenedores está actualmente limitado a Clientes y Partners del Early Access Program de OS.

Integración: Análisis de impacto y consistencia

Las Service Action combinan las ventajas de los métodos de la API REST, que están poco acoplados (loosely-coupled), con las capacidades de entrega rápida de aplicaciones (RAD) de las Server Actions, que están muy acopladas (tightly-coupled), esto es:

  • Capacidad de búsqueda: Cuando se publica un módulo con una Service Action, la Service Action pasa a estar inmediatamente disponible para los consumidores en el catálogo interno de elementos reutilizables accesible a través de la ventana de Gestión de Dependencias. 

  • Análisis de impacto: OutSystems calcula el impacto de cambiar la firma de una Service Action y lo muestra en la ventana de Gestionar Dependencias. Esto le ayuda a decidir si necesita crear una nueva versión de su servicio o si los cambios en su servicio no tienen impacto en los consumidores.

  • Tipificación fuerte: Al igual que las Server Actions, las Service Actions son elementos lógicos fuertemente tipados. Puedes utilizar entidades y estructuras en las firmas de las Service Actions.

  • Seguridad: Las Service Actions sólo son accesibles desde el mismo entorno. OutSystems pasa el contexto de autenticación de la sesión del cliente al hacer la llamada a una Service Action (UserId y TenantId).

  • Manejo de excepciones: Las excepciones de usuario y las excepciones de comunicación lanzadas por una Service Action pueden ser capturadas en los módulos consumidores.

  • Gobierno de acceso: Las Service Actions siguen el mismo modelo de gobierno que cualquier otro elemento reutilizable definido por los permisos en LifeTime.

Qué ventajas aporta OS frente a los inconvenientes del uso de microservicios

De los inconvenientes indicados, algunos son intrínsecos a la propia arquitectura, sin embargo otros son paliados en gran medida gracias al modelo de OS. Estos son:

  1. Gestión de despliegues y Pruebas

Debido al análisis constante de la consistencia de las aplicaciones en OS se consigue tener entornos de desarrollo estables y consistentes casi en todo momento. Esto facilita -junto con otras funcionalidades- la posibilidad de realización de despliegues con un solo click mediante la función 1-Click Publish.

Además para los despliegues entre entornos también existe una herramienta de gestión del ciclo de vida de aplicaciones denominada LifeTime que evalúa la consistencia del despliegue garantizando el funcionamiento de la aplicación en el entorno destino

  1. Mover funcionalidad entre microservicios

El modelo de Outsystems basado en desarrollo visual también facilita la refactorización y permite mover elementos de un sitio a otro de forma fácil mediante copiado y pegado, en muchos casos. Además el sistema evalúa en todo momento el impacto y la consistencia mediante mecanismos de Inteligencia Artificial (AI). En concreto con la funcionalidad TrueChange.

Destacar que también existe una herramienta que facilita esta labor denominada Refactor disponible en la Forge de OS ampliamente documentada.

Conclusión

Con el análisis realizado vemos que mediante OS se pueden implementar aplicaciones basadas en microservicios planteando además diversas ventajas a la hora de gestionar los retos asociados a su uso a lo largo de todo el ciclo de vida de desarrollo, esto es:

  • Diseño de la arquitectura

  • Implementación de la solución

  • Despliegues y pruebas

  • Mantenibilidad

Por otro lado, es necesario indicar que, si bien la aplicación desarrollada puede cumplir actualmente con los estándares de desarrollo de este tipo de arquitecturas, actualmente la implementación de la escalabilidad, a nivel de infraestructura, mediante contenedores, se encuentra en revisión en el programa Early Access Program por lo que no está disponible oficialmente a la fecha de la publicación de este artículo.