Un patrón arquitectónico constituye una solución repetible y consistente a un problema común dentro de un contexto de uso específico. En esencia, un patrón de arquitectura establece cómo se deben organizar los bloques funcionales y su interacción para lograr un resultado determinado.
Aunque comparten similitudes con los patrones de diseño de software, los patrones arquitectónicos tienen un alcance más amplio. Mientras que los patrones de diseño se centran en aspectos específicos del código fuente para resolver problemas más acotados, los patrones arquitectónicos abordan desafíos de mayor envergadura.
Existen diversos tipos de patrones arquitectónicos, cada uno destinado a abordar problemáticas particulares. A continuación, intentaré mostraros cómo discernir entre ambos patrones y, sobre todo, cómo utilizar un par de conceptos que veo muchas veces mezclados con SOA perteneciendo a Microservicios y viceversa.
Arquitectura Orientada a Servicios (SOA)
La Arquitectura Orientada a Servicios (SOA) es uno de esos patrones de arquitectura que se usan un montón en las empresas. Básicamente, SOA promueve el uso de servicios para hacer cosas chéveres en el mundo empresarial. ¿Qué significa eso? Pues, que SOA es como un elemento de la integración empresarial que conecta diferentes sistemas súper diferentes para hacer tareas de negocios.
En SOA, los servicios hablan entre ellos sin importarles mucho el protocolo que usen. Pueden utilizar REST, SOAP, AMQP y otros, como les dé la gana. La clave está en que comparten información a través de una plataforma común llamada Enterprise Service Bus (ESB). Esta cosa facilita la comunicación sin importar el protocolo, es como el traductor multilingüe de los servicios.
Con SOA, los servicios se juntan y trabajan en equipo, sin importar sus diferencias. Es como armar un equipo de piezas empresariales que salvan el día integrando sistemas heterogéneos (la diversidad extrapolada al mundo de los servicios).
Un ESB es como el jefe de integración de software. Se encarga de conectar diferentes aplicaciones y hacer que se entiendan entre sí. Su trabajo principal es transformar datos, manejar la conexión, los mensajes y la dirección de las solicitudes. Además, puede combinar varias solicitudes si es necesario. El ESB es genial porque permite una comunicación sin problemas sin importar los protocolos que se usen. También ayuda a implementar procesos empresariales complejos y asegurarse de que los datos se transformen y validen correctamente al integrar diferentes servicios.
SOA se enfoca en la empresa en general, porque los servicios están dirigidos a toda la empresa. Hay cinco tipos de servicios importantes en SOA son:
Servicios empresariales
Que se diseñan en torno a las funcionalidades que una organización debe realizar para llevar a cabo sus operaciones empresariales. Estos servicios son de grano grueso y no muy fino.
Imagínate que estás pensando en qué servicios ofrece tu empresa. Puedes descubrirlo respondiendo a esta pregunta: «¿A qué nos dedicamos?». Por ejemplo, si tienes una empresa de comida a domicilio, puedes decir: «Nos dedicamos a entregar deliciosas comidas en casa». O si tienes una tienda en línea, puedes decir: «Estamos en el negocio de vender ropa y accesorios en Internet».
Ahora, para respaldar esos negocios, necesitarás crear ciertos servicios en tu arquitectura. Por ejemplo, puedes tener un servicio para procesar pedidos en línea, pero no puedes decir que estás en el negocio de procesar pedidos en línea, ¿verdad? Los servicios que realmente identifican tu negocio se llaman «servicios empresariales» en una arquitectura SOA.
Imaginemos una arquitectura SOA para un banco. Podemos tener servicios empresariales como «Servicio de Préstamos Personales», «Servicio de Tarjetas de Crédito», «Servicio Bancario» y «Servicio de Préstamos Hipotecarios». Estos son los servicios que realmente representan tu negocio y son clave en una SOA.
Servicios de la empresa
En una arquitectura SOA, los servicios que se usan en toda la empresa se llaman servicios de empresa. Veámoslo con ejemplos sencillos: imagina que necesitas autenticar usuarios. En lugar de tener varias aplicaciones haciendo la misma tarea de autenticación, es mejor tener un único servicio de autenticación para toda la empresa. Así ahorras tiempo y esfuerzo, ¡y evitas reinventar la rueda en cada aplicación!
Otro ejemplo es la gestión de la información de los clientes. En un banco, no quieres mantener la información del cliente de manera diferente en diferentes sistemas, como préstamos hipotecarios, préstamos personales y la banca central. Sería un lío. Lo mejor es tener un servicio compartido que se encargue de mantener la información del cliente en un solo lugar y que todos los servicios de la empresa utilicen. Estos servicios de empresa suelen ser administrados por un grupo de arquitectos empresariales o servicios compartidos.
Servicios de la aplicación
Son más específicos y se aplican a cada nivel de una aplicación concreta. Estos servicios son propiedad de los equipos de aplicación dentro de un área de negocio. Piensa en tareas como abrir una cuenta empresarial, verificar el saldo de una tarjeta de crédito o generar un extracto de la tarjeta. Estos servicios de aplicación tienen un propósito muy concreto y están diseñados para hacer algo específico dentro del contexto de una aplicación.
En una arquitectura SOA bancaria, por ejemplo, agregar datos de una vivienda para una solicitud de préstamo hipotecario. es un servicio muy específico y se clasifica como un servicio a nivel de aplicación.
Servicios de infraestructura
Servicios que sostienen todo
Imagínate que hay servicios que no hacen cosas directamente para la aplicación o para las tareas específicas, pero juegan un papel muy importante en el fondo. Estos servicios son como el apoyo técnico que proporciona funciones a nivel de plataforma. Son súper útiles porque pueden ser utilizados tanto por los servicios empresariales como por los servicios de aplicación.
Por ejemplo, el servicio de registro es clave en cualquier aplicación. Por eso entra en la categoría de servicios a nivel de plataforma o infraestructura. Cualquier servicio empresarial o de aplicación puede usarlo para sus necesidades de registro. Otro ejemplo es el servicio de auditoría de datos. No es algo que un servicio de aplicación necesite directamente en su función principal, pero las entidades gubernamentales o las organizaciones de cumplimiento interno pueden requerirlo. Así que, un servicio de auditoría se convierte en parte de los servicios de infraestructura y puede ser llamado por los servicios de aplicación cuando sea necesario.
Estos servicios de infraestructura son como los cimientos sólidos que sostienen todo el edificio de tu arquitectura. ¡Sin ellos, todo sería un desastre!
El ESB
El maestro de ceremonias
Imagina que en el corazón de nuestra arquitectura bancaria hay un ESB. ¿Qué es eso? Bueno, es como el organizador principal de todo el proceso. Se encarga de coordinar y dirigir el flujo de trabajo, traducir los datos, cambiar los formatos de los mensajes y asegurarse de que todo se transmita sin problemas sin importar qué protocolo se esté usando. Es como un traductor y un director de orquesta al mismo tiempo.
Puedes tener una arquitectura SOA sin un ESB, pero en ese caso los servicios dependen directamente unos de otros y están muy entrelazados (lo peor de este mundo). No hay esa capa de abstracción que el ESB proporciona. Claro, la SOA no es tan fácil de implementar ni de probar, pero tiene una ventaja: ¡es muy escalable! Sin embargo, hay un pequeño inconveniente: el costo. Para tener un ESB, generalmente se necesita utilizar software de terceros, y a veces no se necesitan todas las funciones que ofrece el ESB. Además, hay que tener en cuenta que el ESB puede convertirse en un punto de fallo si algo sale mal.
En resumen, el ESB es como el director de toda la orquesta, pero puede tener sus desafíos y riesgos. Sin embargo, con una buena planificación y gestión, puede ser una pieza clave en una arquitectura SOA exitosa.
Existen varias opciones de ESB comerciales en el mercado. Algunos de los ESB más populares y ampliamente utilizados son:
-
MuleSoft Anypoint Platform.
- Apache ServiceMix.
-
Oracle Service Bus.
-
Red Hat Fuse.
patrón de arquitectura de microservicios
El enfoque de los «microservicios».
La arquitectura de microservicios es un patrón que se centra en el uso de servicios más pequeños y específicos en lugar de servicios grandes y generales. Imagina que una aplicación se divide en partes más pequeñas y cada una de ellas cumple una función específica. Estos componentes más pequeños se llaman microservicios.
En contraste con la arquitectura SOA, los microservicios son autónomos y se ejecutan en su propio proceso. Cada microservicio realiza una tarea de negocio en un contexto definido y se conecta con otros microservicios de manera sincrónica o asíncrona, según sea necesario.
A diferencia de SOA, no se utiliza un bus de mensajes en la arquitectura de microservicios. Cada microservicio tiene su propio protocolo de comunicación, por lo que quien utiliza el servicio necesita conocer cómo interactuar con él.
Cada microservicio se despliega y funciona de forma independiente, y están diseñados en torno a dominios de datos específicos. Se exponen a través de interfaces de programación de aplicaciones (API) para permitir la comunicación con otros microservicios, ya sea de manera sincrónica o a través de eventos de forma asíncrona.
En resumen, se trata de dividir una aplicación en partes más pequeñas y especializadas, lo que facilita la escalabilidad y la flexibilidad en el desarrollo y mantenimiento de sistemas de software.
Cada servicio hace una cosa específica para el negocio y tiene su propio espacio de trabajo. Los servicios se comunican entre sí y con otras aplicaciones a través de una capa llamada API. La idea es dividir la funcionalidad en partes pequeñas y autónomas para que puedan desarrollarse individualmente sin afectar a los demás. Esto hace que la arquitectura sea ágil y escalable.
Un beneficio es que al tener servicios separados, las pruebas se vuelven más sencillas. Cada servicio tiene su propia API, lo que permite probarlo de forma independiente para asegurarse de que funciona correctamente y responde correctamente.
Sin embargo, hay algunos aspectos negativos a considerar. Por ejemplo, la comunicación entre servicios a través de la red puede causar retrasos y afectar al rendimiento. Además, cada servicio debe estar preparado para lidiar con problemas de red, como la pérdida de paquetes o respuestas desordenadas. También puede haber cierta complejidad adicional al trabajar con microservicios, especialmente al tratar de deshacerse de una aplicación monolítica.
A menudo veo una confusion enorme con la definición de Servicios Empresariales intentando aplicarse en Microservicios. Son dos conceptos relacionados pero diferentes en el ámbito de la arquitectura de software. La principal diferencia entre los business services y los microservicios radica en su enfoque y nivel de abstracción. Los business services representan la lógica de negocio de una organización, mientras que los microservicios son unidades de implementación y despliegue más pequeñas que se enfocan en una única función dentro de una aplicación más grande. Los microservicios pueden implementar uno o varios business services, dependiendo de la estructura y necesidades del sistema. Por tanto mucho cuidado a la hora de hacer una representación en un diagrama (no llames blanco al negro y negro al blanco, cada uno tiene su propia definición).
Arquitectura basada en servicios
Ya que teneis claro los otros dos patrones, os voy a liar un poco con este de regalo.
Se trata de una arquitectura distribuida que se apoya en el concepto de servicios. que ya has visto en la arquitectura de microservicios y SOA. Son parecidos, pero con una diferencia importante: los servicios en la arquitectura de microservicios son muy pequeños, mientras que en SOA son más grandes y se comunican a través de un middleware de mensajería. Este patrón de arquitectura combina lo mejor de ambos mundos para resolver problemas complejos y encontrar un equilibrio entre los dos.
Cuando intentas «romper el monolito» y convertirlo en microservicios, te das cuenta de que separar la funcionalidad y definir las responsabilidades de cada servicio puede ser bastante complicado. En una verdadera arquitectura de microservicios, no hay acceso directo a la base de datos de otro servicio. Decidir dónde deben residir los datos y cuánta duplicación de datos estás dispuesto a aceptar puede resultar abrumador. Cada microservicio tiene su propia base de datos, lo que hace que agregar y acceder a los datos desde diferentes servicios sea todo un desafío.
Además, al diseñar un microservicio, es importante incorporar los principios de DevOps desde el principio. Al principio, puede ser difícil implementar una canalización automatizada, pero a medida que tienes 20 o más microservicios que necesitan gestionarse, verás que vale la pena.
Implementar una arquitectura de microservicios desde cero no es una tarea fácil. Requiere reescribir toda la aplicación y definir los patrones de comunicación y orquestación. Por otro lado, SOA se enfoca más en el nivel empresarial y requiere un bus de mensajería, lo que agrega costos y complejidad adicionales a la arquitectura. Por lo tanto, necesitamos encontrar un punto intermedio para pasar de una arquitectura monolítica a una de microservicios, y ahí es donde SOA entra en juego.
En los patrones de arquitectura basados en servicios, los servicios son más grandes y se centran en el dominio de la aplicación en lugar de un propósito específico. En esta arquitectura, los servicios comparten la misma base de datos y se comunican entre sí de manera protocolizada, por lo que no necesitamos un ESB como middleware. Dividimos la aplicación en partes de funcionalidad relacionada para crear estos servicios. La granularidad de los servicios se considera más amplia y contienen varios módulos que tienen sentido dentro del alcance de la transacción de la aplicación, evitando la sobrecarga de orquestación de servicios que encontramos en la arquitectura de microservicios.
La arquitectura basada en servicios se enfoca en extraer la funcionalidad relacionada de una aplicación en servicios para que cada servicio pueda realizar transacciones independientes sin necesidad de transacciones distribuidas, orquestación o coreografía entre ellos. Puedes crear estos servicios alrededor de las funcionalidades complejas de tu aplicación. Estos servicios se llaman macroservicios o servicios de aplicación, ya que abarcan una parte completa de la aplicación, a diferencia de los microservicios que se enfocan en un único propósito. Este estilo de arquitectura crea un acoplamiento más estrecho entre los componentes dentro de un servicio, pero muchas organizaciones lo utilizan como un paso intermedio hacia una arquitectura completa basada en microservicios.
En esta arquitectura, todos los servicios acceden a la misma base de datos, lo que significa que cualquier problema o tiempo de inactividad de la base de datos puede afectar a toda la aplicación. La comunicación entre los servicios se realiza de forma consciente del protocolo y los servicios comparten contratos. Cualquier cambio en estos contratos puede afectar a los demás servicios. Como no hay un middleware entre los servicios, es más sencillo y fácil de implementar. Algunas variantes de esta arquitectura pueden incluir un centro de integración ligero entre los servicios, que ayuda en la traducción y orquestación de servicios.
Por ejemplo, un e-commer tiene varios módulos para llevar a cabo sus funciones de negocio, por lo que dividirlo en una arquitectura de microservicios requerirá un esfuerzo significativo y creará una sobrecarga adicional en la configuración de pipelines automatizados y en la división de cada módulo en un único servicio de contexto delimitado y centrado en características. Así pues, la funcionalidad se divide en porciones: las funciones relacionadas con los pedidos las gestiona el servicio de gestión de pedidos, las funciones relacionadas con los proveedores las lleva a cabo el servicio de gestión de proveedores y todas las funciones relacionadas con los clientes las separa el servicio de gestión de clientes. Sin embargo, todos estos servicios acceden a la misma base de datos, y la comunicación entre ellos se realiza a través de API basadas en REST (por ejemplo).
En una arquitectura basada en servicios, la interfaz de usuario de la aplicación se despliega como un servicio independiente. Se comunica con otros servicios a través de sus API, al igual que en una arquitectura de microservicios. La diferencia radica en que estos servicios tienen una responsabilidad más amplia y no se centran en un único propósito.
En comparación con una arquitectura de microservicios, una arquitectura basada en servicios tiene menos servicios, lo que simplifica las cosas y no requiere despliegues automatizados desde el primer día. Esto facilita un poco el despliegue de estos servicios, ya que no son tantos, y con el tiempo puedes establecer tus propias rutinas de lanzamiento. Además, esta arquitectura tiene un mejor rendimiento, ya que no tienes que comunicarte con varios servicios para realizar una sola función empresarial. También es más económica que SOA, ya que no necesitas un bus de mensajería pesado para implementarla. Sin embargo, desarrollar estos servicios puede ser un poco más difícil, ya que contienen toda la funcionalidad de una función empresarial compleja, lo que requiere un buen entendimiento por parte del equipo de desarrollo y plantea desafíos a la hora de realizar lanzamientos frecuentes.
En resumen
La arquitectura de Microservicios se basa en componentes pequeños y especializados, mientras que la SOA se centra en servicios empresariales y la integración de sistemas más grandes. Es importante tener en cuenta las diferencias y no confundir los conceptos en el ámbito de la arquitectura de software.
| SOA | Microservicios | |
| Definición | Un enfoque arquitectónico que se basa en servicios empresariales para construir aplicaciones más grandes. | Un enfoque arquitectónico que divide una aplicación en componentes pequeños, autónomos y bien definidos llamados microservicios. |
| Tamaño del componente | Los servicios son más grandes y generalmente representan funcionalidades empresariales completas. | Los microservicios son pequeños y se centran en una funcionalidad específica del negocio. |
| Acoplamiento | Existe un acoplamiento más fuerte entre los servicios, lo que significa que los cambios en un servicio pueden afectar a otros servicios. | Hay un acoplamiento débil entre los microservicios, lo que permite realizar cambios en un microservicio sin afectar a los demás. |
| Escalabilidad | La escalabilidad se realiza a través de la replicación de servicios completos, lo que puede resultar costoso. | La escalabilidad se logra mediante la replicación de microservicios individuales, lo que permite un uso más eficiente de los recursos. |
| Mantenimiento | El mantenimiento de servicios puede ser más complejo debido al acoplamiento y la dependencia entre ellos. | El mantenimiento de microservicios es más sencillo, ya que se pueden actualizar e implementar de forma independiente. |
| Tecnología | SOA no está vinculado a una tecnología o protocolo específico. | Los microservicios generalmente se basan en tecnologías como contenedores, Docker y protocolos como HTTP/REST. |
| Enfoque organizacional | SOA se centra en la reutilización de servicios a nivel empresarial y puede requerir una coordinación y planificación centralizada. | Los microservicios promueven la descentralización y la autonomía de los equipos de desarrollo, lo que permite una mayor agilidad. |
