Desde hace un tiempo viene ganando popularidad esto de los microservicios.

Cada vez son más las reuniones donde arquitectos de software plantean su intención de ir hacia una arquitectura basada en microservicios.

Los beneficios del «brochure» son claros, construyo una aplicación como un puzzle de unidades independientes que se comunican por medio de APIS, eventualmente en tecnologías distintas, hago el despliegue de esos microservicios de forma independiente y evito tener que hacer una instalación monolítica de todo mi sistema cuando el usuario me dice que hay que agregar un nuevo campo en la base de datos.

Entonces microservicios va de la mano con continuos integration y continuos delivery. Tener automatizado el llevar una aplicación a producción está bueno pero cuando tu aplicación son 300 aplicaciones deja de ser una buena idea para ser una necesidad.

Entonces los microservicios están buenos, pero no son gratis, alguien tiene que gestionar todo eso, hacer puebas de integración y todos los desafíos de un sistema distribuido.

Entonces, cómo se relacionan esto de los microservicios y las herramientas low-code?

Bueno, esta es mi visión personal del tema y seguro que tiene sus detractores inclusive dentro del seno de los low-code, pero me hago cargo.

Cuando pensamos en la arquitectura de un sistema, pensamos en programador que en su eclipse o editor favorito elabora código y luego expone para que otros sistemas consuman, sean humanos o no.

En ese sentido debe seguir unas reglas especificas pensadas en la futura integración, en otras palabras, me tengo que enfocar en cosas que no hacen al problema sino a la implementación. Punto para el low-code que te dice, enfocate en el problema a resolver.

Lo otro es que el microservicio es un sistema, y la definición de que tan «chico» es super subjetiva. A ver quién se anima a decir que es es chico en términos de software.

En ese sentido, lo que pasa ahí dentro es lo mismo que pasa en la construcción de cualquier sistema, donde puedo elegir hacerlo a mano o con herramientas lowcode.

En resumen, microservicios tiene cosas buenas y cosas malas, como todo en esta vida.

SI vamos por este lado, podemos hacer esos microservicios con herramientas low-code, porque al final son sistemas, pero estamos perdiendo la visión global de toda la solución que tiene la herramienta low-code si somos más monolíticos a cambio de poder hacer deploys más rápidos.

Ejemplo

En GeneXus construimos un sistema como una sucesión de aproximaciones y solemos hacer una demo de un sistema de la facturación, si bien mis compañeros están aburridos de la misma, a mi me encanta porque muestra una de las cosas más poderosa que tiene la herramienta.

Construimos una factura en la visión del usuario, sin pensar en base de datos o módulos. Tomamos esa visión papel/pantalla que tiene el usuario y la copiamos a la pantalla. GeneXus crea a partir de ahí la base de datos y los programas.

A medida que avanzamos le vamos aportando más conocimiento al sistema y GeneXus va creando estructuras para ir modelando ese sistema, pero siempre bajo la premisa que entiende el modelo de conocimiento global que sustenta ese programa.

Puedo el día mañana sacar el módulo de clientes hacia un servicio, pero en contrapartida GeneXus deja de entender lo que es un cliente, como resolver consultas a la base de datos de forma automática y parte del valor que nos aporta.

Como siempre, hay que poner en la balanza nuestro dolor para ver qué conviene más, lo que tenemos que estar seguros es que no tenemos que tomar decisiones basado en modas tecnológicas.

La entrada Microservicios y low-code se publicó primero en Construyendo Software.