Cuando hablamos de SOA (Arquitectura Orientada a Servicios), MSA (Arquitectura Orientada a Microservicios) y Microfrontend (Similar a MSA pero en la capa de presentación), nos referimos a arquitecturas que implementan cierta infraestructura física distribuida con el fin de optimizar recursos y escalar los sistemas de información a niveles que soporten alta concurrencia.
Arquitectura Orientada a Servicios (SOA)
Como seguramente ya se sobreentendió en la definición anterior, SOA es una arquitectura que se implementa en el backend, de tal manera que funcionalidades de manejo lógico de la aplicación estarán expuestos mediante tecnologías como SOAP o REST (Protocolo y estilo de comunicación, respectivamente, mediante una implementación de web service), para su consumo por aplicaciones externas.
La característica de SOA es que un backend podrá estar disponible para su uso por diversas aplicaciones externas, ya sean entornos de escritorio, web, móvil o incluso otros backend's.
Otro punto importante que mencionar es que si bien SOA busca un nivel de interoperabilidad alto, aún es un monolito en el backend, lo que puede repercutir negativamente en el consumo de recursos cuando se trata de sistemas de alta concurrencia.
Seguidamente mostramos un ejemplo de una SOA donde existen 3 servicios generales: una de chat, otra del core del negocio y finalmente otra de servicios de la compañía:
Si se observa la representación gráfica anterior, veremos que existen 3 servicios que si bien pueden estar en equipos físicos diferentes, componen globalmente propósitos propios, a su vez, estos pueden servir a diversos clientes web (claro que esto vemos en este ejemplo, pero pueden ser aplicaciones móviles o de escritorio), entonces, SOA busca justamente esto, conglomerar servicios, pero, exponerlos a diversos clientes.
Arquitectura en Micro Servicios (MSA)
Esta no es más que una evolución de SOA, siendo que lo que se buscaba era soportar mayor concurrencia, y, por ende, se tomaron los servicios para convertirlo en servicios más pequeños (es más un aspecto de paradigma que otra cosa), sin embargo, se mantuvo la idea de interoperabilidad y demás. Sin más, veamos un ejemplo de forma gráfica:
¿No se parece al diagrama anterio, cierto? bien, entonces, expliquémoslo brevemente, ya que no es más que la extensión de lo anterior.
S1, S2, ..., S8 no son más que servicios pequeños, imaginemos el "Chat service" de la imagen de más arriba, los S1, S2 y demás, no serían más que un desgloce del Chat service en servicios más pequeños para llevarlos cada uno a un servidor físico independiente, los que podría ser por ejemplo:
S1: Servicio de envío de mensajes.
S2: Servicio de visualización de historial de mensajes.
S3: Servicio de filtro de mensajes
y así para cada caso. Quizás un poco exagerado la divisón de servicios a este nivel, pero sería algo como esto.
Si hablamos en un contexto de un sistema de ventas, los microservicios podrían ser: compras, ventas, facturación, clientes, devoluciones, reportes y así sucesivamente; siendo que cada caso sería un proyecto de software independiente, pero interconectado mediante servicios y tokens, además de ser servicios pequeños de un servicio más grande que sería el sistema de ventas. Entonces, la pregunta sería ¿cómo dividimos estos microservicios a partir del servicio global del negocio? pues, la respuesta es que no existe una una definción clara, el criterio simplemente es agrupar por lógicas pequeñas de negocio, que tengan importancia de unos pequeños casos de negocio y que a su vez puedan desacoplarse sin repercutir negativamente en otros componentes.
Ahora, pensando un poco, ¿qué problemas puede darnos un mal desacoplamiento de microservicios? pues, la respuesta sería una falla transaccional en las operaciones, que por ejemoplo una persistencia de datos, dependa de microservicios separados que deban ser transaccionales, pero al estar en proyectos independientes, se rompe esta cohesión y existen riesgos de inconsistencia de datos, por tanto, es importante separar cuidadosamente cada microservicio, acorde a la dependeican de flujos lógicos.
Arquitectura Microfrontend
Esta arqutiectura es inspirada en los microservicios, es decir, aplicar la filosofía de MSA, pero en la parte frontal de la aplicación, esto proporcionaría mayor escalabilidad y un alto desacoplamiento, explicado todo lo anterior, creo que esto se entendería más rápido, mediante un gráfico, entonces, veámoslo:
Observemos cuidadosamente la imagen anterior, es parecido a lo presentado en la SOA, pero no, la diferencia está en la parte derecha, los micro-frontend 1, 2 y demás; estos serían proyectos independientes, pero que conformarían una única aplicación frontal, por ejemplo, si vemos más arriba el gráfico de la SOA, todos estos microfrontend, podrían ser proyectos independientes de lo que sería el proyecto macro codideep.com.
¿Difícil de entenderlo? pues no, solo demos imaginar un poco el paradigma planteado y tratar de implementarlo en la práctica.
CONCLUSIÓN
Lo explicado en este post serían paradigmas, arquitecturas y técnicas más avanzadas de lo tradicional, sin embargo, es imperativo conocerlo para usarlos cuando el contexto lo amerite, y, claramente sería cuando existe una concurrencia muy alta en uno o varios sistemas de información que vayamos a desarrollar.
SAO, MSA y Microfrontend, van muy de la mano, la implementación requiere una amplia experiencia en arquitectura de software, pero si por lo pronto no se tiene la experiencia suficiente, se recomienda tratar de entenderlo y manejarlo a nivel conceptual, y claro, con un poco de práctica, verán que esto es más sencillo de lo que parece.
¿Dónde practicamos? pues, cada quien en sus proyecto, sin embargo, las dudas siempre serán antedidas en este blog, además, se recomienda no saltarse lo previo, entender primero, patrones como MVC y DDD, y aplicar estas 2 en SOA y MSA, ahora, Microfrontend, se puede aplicar desde los niveles más bajos, generando desacoplamiento y mayor escalabilidad.
Como recomendación, no uses un ferrari para hacer taxi; es decir, no inviertas tiempo en implementar una arquitectura muy grande, para una simple página web o una aplicación muy pequeña, cada cosa en su contexto y necesidad, caso contrario, solo generarás sobreingeniería y la ventaja se convertirá en desventaja y la inversión en gasto.
- Debes estar logueado para realizar comentarios