Arquitectura orientada a servicios vs arquitectura de microservicios: comparando SOA con MSA

En informática, un servicio se refiere a una unidad individual o colectiva de software que realiza tareas repetitivas y redundantes. En la era de la computación en la nube, las aplicaciones son compuestas por un conjunto de servicios que en conjunto realizan diversas funciones para apoyar la funcionalidad general de la aplicación. En este artículo, exploramos la Arquitectura de Microservicios (MSA) y la Arquitectura Orientada a Servicios (SOA) como dos arquitecturas basadas en servicios comunes: cómo ambas dependen de los servicios como componente principal y cómo difieren en cuanto a características de servicio. Veamos un poco.

¿Qué es una arquitectura orientada a servicios (SOA)?

Una arquitectura orientada a servicios sigue un diseño de múltiples servicios autónomos, discretos y repetibles que se son usados colectivamente para formar una malla de servicios de las funcionalidades de una aplicación de forma holística. Esto permite que un marco de componentes de aplicación interactúe y ofrezca servicios con otros componentes aprovechando una interfaz de servicio (protocolo de comunicación).

Principios de diseño de la SOA

Los principios de una Arquitectura Orientada a Servicios pueden diferir según tu caso utiliza. Aquí son algunos principios comunes que segregan los servicios para formar una SOA:

• Abstracción
• Reutilizabilidad
• Granularidad
• Contrato estandarizado
• Autonomía
• Apatridia
• Descubrimiento

Características de SOA

Un caso fundamental utiliza de una SOA están permitir te construir una aplicación utilizando múltiples servicios distintos de forma colectiva, donde cada servicio consiste en una lógica de negocio o aplicación única. Aparte de eso, algunas características comunes de la SOA incluyen:

• Arquitectura de "compartir tanto como sea posible"
• Importancia en la reutilización de funcionalidades empresariales
• Gobernanza común y estándares
• Bus de servicio empresarial (ESB) para comunicación
• Protocolos de mensajes múltiples
• Plataforma común para todos los servicios desplegados en ella
• Multihilo con más sobrecarga para gestionar E/S
• Máxima reutilización del servicio de aplicaciones
• Es más probable que utilicen bases de datos relacionales tradicionales
• No es preferible en un modelo DevOps

¿Qué es una arquitectura de microservicios (MSA)?

Una arquitectura de microservicios, conocida a menudo como microservicios, sigue un patrón SOA dividiendo una sola aplicación en múltiples servicios independientes y débilmente acoplados pero que funcionan entre sí. A menudo considerados el caso perfecto de utiliza de la contenedorización, los microservicios son bastante habituales para que las organizaciones desplieguen cada uno de estos microservicios en contenedores separados. Esto permite un marco eficiente de múltiples servicios que son flexibles, portátiles y independientes de la plataforma, permitiendo que cada servicio tenga diferentes sistemas operativos y bases de datos mientras se ejecuta en su propio proceso.

Características de MSA

• Arquitectura de "compartir lo menos posible"
• Importancia en el concepto de contexto acotado
• Gobernanza relajada, con más enfoque en las personas
• Colaboración eficiente y libertad a la hora de elegir la plataforma y las tecnologías
• Sistema de mensajería sencillo y menos elaborado
• Protocolos ligeros como HTTP/REST y AMQP
• De un solo hilo, normalmente con la utiliza de funciones de bucle de eventos para el manejo de E/S sin bloqueo
• Los contenedores funcionan muy bien en MSA y se son considerados perfectos para un modelo DevOps
• Más centrado en el desacoplamiento
• Utiliza bases de datos modernas no relacionales

Microservicios vs SOA: diferencias clave

Veamos las diferencias clave entre SOA y MSA.

Coordinación

La SOA requiere coordinación con varios grupos para Crea solicitudes empresariales. Al contrario, en un MSA están poca o ninguna coordinación entre los servicios. En caso de que se están necesaria coordinación entre los propietarios de servicios, se está realizada a través de pequeños equipos de desarrollo de aplicaciones, y los servicios pueden desarrollarse, probarse y desplegarse rápidamente.

Granularidad del servicio

El prefijo "micro" en microservicios se refiere a la granularidad de sus componentes internos. Los componentes de servicio dentro de MSA suelen son servicios de propósito único que hacen una cosa muy bien. Los servicios en SOA suelen incluir mucha más funcionalidad empresarial y a menudo son implementados como subsistemas completos.

Compartición de componentes

La SOA mejora el intercambio de componentes, mientras que la MSA intenta minimizar la compartición mediante el "contexto acotado". Un contexto acotado se refiere al acoplamiento de un componente y sus datos como una unidad única con dependencias mínimas. Como la SOA depende de múltiples servicios para satisfacer una solicitud empresarial, los sistemas construidos sobre SOA probablemente son más lentos que la MSA.

Middleware vs capa API

El middleware de mensajería en SOA ofrece una serie de capacidades adicionales que no se encuentran en MSA, incluyendo:

• Mediación y enrutamiento
• Mejora de mensajes
• Transformación de mensajes y protocolos

MSA tiene una capa API entre los servicios y los consumidores de servicios.

Servicios remotos

Las arquitecturas SOA se basan en la mensajería (AMQP, MSMQ) y SOAP como protocolos principales de acceso remoto. La mayoría de los MSA se basan en dos protocolos—REST y mensajería simple (JMS, MSMQ)—y el protocolo que se encuentra en MSA están generalmente homogéneo. Interoperabilidad heterogénea SOA promueve la propagación de múltiples protocolos heterogéneos a través de su componente middleware de mensajería. MSA intenta simplificar el patrón arquitectónico reduciendo el número de opciones de integración.

• Si te quieres integrar varios sistemas usando diferentes protocolos en un entorno heterogéneo, te necesario considera SOA.
• Si todos tus servicios pudieran exponerse y acceder a través del mismo protocolo de acceso remoto, entonces MSA están una mejor opción.

Desacoplamiento de contratos

El desacoplamiento contractual es el santo grial de la abstracción. Ofrece el mayor grado de desacoplamiento entre servicios y consumidores. Es una de las capacidades fundamentales que ofrece SOA, pero MSA no soporta el desacoplamiento por contrato.

¿Qué arquitectura elegir?

Aquí son algunas consideraciones clave a la hora de elegir cualquiera de los patrones:

• SOA está mejor adaptada a entornos de aplicaciones empresariales grandes y complejos que requieren integración con muchas aplicaciones heterogéneas. Sin embargo, las aplicaciones basadas en flujos de trabajo que tienen un flujo de procesamiento bien definido son algo difíciles de implementar usando patrones SOA. Las aplicaciones pequeñas tampoco son adecuadas para SOA, ya que no necesitan un componente middleware de mensajería.
• El patrón MSA está muy adecuado para sistemas web más pequeños y bien particionados. La falta de middleware de mensajería está uno de los factores clave que Haz que MSA no sea adecuado para entornos complejos.
• Control vs orquestación. Al desarrollar una aplicación desde cero, usar MSA se está considerado una opción pragmática, ya que ofrece un mayor control como desarrollador. Por otro lado, si el objetivo es orquestar procesos de negocio, la SOA se está considerada inactiva porque proporciona el marco adecuado.
• Organizaciones en fase inicial frente a organizaciones más maduras. Las empresas que son en sus primeras etapas pueden considerar la MSA como una opción ideal. A medida que el negocio crece, las organizaciones pueden necesitar capacidades como la transformación compleja de solicitudes e integración heterogénea de sistemas. En tales situaciones, las organizaciones suelen recurrir al patrón SOA para reemplazar a MSA.

Tanto SOA como MSA siguen un patrón idéntico de servicios en diferentes capas de una empresa. La existencia de MSA se debe al éxito del patrón SOA y, por ello, a menudo se está referido como un subconjunto de SOA. Mientras que tanto los microservicios como una arquitectura orientada a servicios funcionan enteramente dividiendo una aplicación en múltiples servicios, un MSA desagrega servicios a nivel de aplicación, mientras que un SOA lo hace a nivel empresarial.

Lecturas relacionadas

• BMC DevOps Blog
• Microservicios vs Nanoservicios: Opciones de Marco de Ponderación
• Microservicios vs Serverless: ¿Cuál es la diferencia?
• Desafíos de los microservicios y cuándo evitarlos
• Kubernetes vs Docker Swarm: Comparando herramientas de orquestación de contenedores
• El estado actual de los contenedores: Resumen del informe

Imágenes originales de referencia:

Estas publicaciones son mías y no representan necesariamente la posición, estrategias u opinión de BMC.