La Arquitectura de Microservicios

Cuando se emprende la construcción de una casa o edificio es esencial contar con un arquitecto que diseñe la estructura, asegurando un resultado final que cumpla con los objetivos deseados por los inversionistas. Este profesional no solo define la arquitectura, sino que traza los cimientos de la edificación estableciendo, por ejemplo, si será de dos plantas. Este aspecto es fundamental ya que, una vez establecidos estos cimientos no se podrá añadir más altura al edificio en el futuro. Si bien se pueden modificar aberturas y revestimientos para mejorar su estética, la cantidad de plantas queda fija en base a esta planificación inicial.

De igual manera ocurre en el ámbito del software. Un sistema debe ser meticulosamente diseñado para abarcar tanto los requisitos funcionales como los no funcionales. Para lograrlo, se necesita una arquitectura apropiada. De lo contrario, su adaptación futura se vuelve complicada. Es cierto que podemos embellecer la interfaz con un diseño más atractivo y mejorar algunos aspectos visuales. Sin embargo, alcanzar la totalidad de los requisitos no funcionales, como procesar una carga significativamente mayor de transacciones por segundo, mantener la funcionalidad offline o lograr una escalabilidad automática en momentos de alta demanda, resultará un desafío.

Desde sus inicios en la década de 1960, los ingenieros de software han buscado abordar la complejidad de los grandes sistemas. Inicialmente, recurrieron a la 'modularidad y ocultación de información', luego a la 'separación de preocupaciones', y más adelante a la 'arquitectura orientada en servicios', siempre guiados por la premisa 'divide y vencerás'. Sin embargo, en las últimas décadas, estos enfoques ya no han sido suficientes para enfrentar las complejidades de las aplicaciones a escala web. Como solución emergente, ha surgido un enfoque innovador: la arquitectura de microservicios. Este nuevo paradigma representa una evolución del 'divide y vencerás', dividiendo el sistema 'verticalmente' en subsistemas según los requisitos funcionales o comerciales. Esto permite su implementación de forma independiente, comunicándose entre sí a través de la red sin depender del lenguaje de programación, ya sea de manera síncrona (REST, GraphQL, gRPC) o asíncrona a través de mensajería.

En esta arquitectura, la aplicación se descompone en procesos separados, cada uno conteniendo múltiples módulos internos. Cada microservicio opera de forma independiente y se comunica con sus pares mediante llamadas a través de la red.

Entre sus ventajas, destacamos la facilidad para escalar, ya sea de forma horizontal o vertical, así como su capacidad para realizar modernizaciones incrementales. Además, se integra de manera sencilla en la infraestructura moderna de la nube.

Otras ventajas notables son la testabilidad, facilitada por su naturaleza de servicio que permite la creación de casos específicos para pruebas, y la interoperabilidad, al emplear estándares abiertos y ligeros para la comunicación, permitiendo su combinación con cualquier aplicación o componente.

Esta arquitectura también posibilita combinar microservicios desarrollados con diferentes tecnologías, incluso con bases de datos distintas, otorgando una mayor flexibilidad según los requisitos de cada servicio de negocio. En algunos casos, permite aprovechar la experiencia y conocimientos de distintos equipos de desarrollo, especialmente en sistemas extensos.

No obstante, no es apropiado aplicar este paradigma a cualquier tipo de aplicación. Así como no adquiriríamos un camión para ir al supermercado, tampoco siempre justifica la implementación de esta arquitectura. Generalmente, se adapta mejor a las siguientes situaciones:

●       Cuando es necesario un escalado significativo.

●       Cuando se requiere utilizar diversas plataformas.

●       En sistemas de gran envergadura que puedan involucrar más de un equipo de desarrollo.

●       Si buscamos agilidad en el desarrollo para implementar cada componente de forma independiente.

En general, las aplicaciones empresariales a gran escala se benefician de este tipo de arquitectura.

Al igual que un arquitecto que diseña un edificio traza sus planos para definir su estructura, los arquitectos de software estructuran el software a un nivel superior utilizando patrones y abstracciones para brindar claridad en la implementación de los sistemas. En este caso, nos referimos a patrones como soluciones generales y reutilizables para problemas comunes al estructurar un software en un contexto determinado.

Cuando se emplea el paradigma de microservicios suele aplicarse una serie, no necesariamente estricta, de patrones entre los cuales destacan:

 ●       API Gateway

●       Database per Microservice

●       Event Sourcing

●       Asynchronous Request Response

●       Command Query Responsibility Segregation (CQRS)

●       Saga

●       Backends for Frontends (BFF)

●       Strangler

●       Circuit Breaker

●       Externalized Configuration

Pronto profundizaremos en cada uno.

Agradecemos por este artículo a Jorge Daniel Lemes.