SOA frente a microservicios: ¿cuál es la diferencia?

Si trabaja en el campo de TI o de la computación en la nube, probablemente esté al tanto del debate sobre la arquitectura orientada a servicios (SOA) frente a los microservicios. Después de todo, hoy en día todo el mundo habla de microservicios y aplicaciones ágiles.

A primera vista, los dos enfoques parecen similares y, en cierto modo, lo son. Ambos involucran entornos de nube o nube híbrida para el desarrollo ágil de aplicaciones y despliegue, y ambos pueden escalar para satisfacer la velocidad y las demandas operativas de big data. Ambos dividen las aplicaciones grandes y complejas en componentes pequeños y flexibles que son más fáciles de manejar. Y ambos se diferencian de una arquitectura tradicional y monolítica en que cada servicio tiene su propia responsabilidad.

Sin embargo, a pesar de estas similitudes fundamentales, un análisis más detallado de ambos enfoques revela diferencias importantes.

La arquitectura orientada a servicios (SOA) es un enfoque empresarial para el desarrollo de software de componentes de aplicación que usan componentes de software reutilizables, o servicios. En la arquitectura de software SOA, cada servicio se compone del código y las integraciones de datos necesarios para ejecutar una función empresarial específica, por ejemplo, verificar el crédito de un cliente, iniciar sesión en un sitio web o procesar una aplicación de hipoteca.

Las interfaces de servicio proporcionan un acoplamiento flexible, lo que significa que se pueden invocar con poco o nulo conocimiento de cómo se implementa la integración en segundo plano. Gracias a este acoplamiento flexible y a la forma en que se publican los servicios, los equipos de desarrollo pueden ahorrar tiempo reutilizando componentes en otras aplicaciones de toda la empresa. Esto supone tanto un beneficio como un riesgo. Como resultado del acceso compartido al bus de servicio empresarial (ESB), si surgen problemas, también puede afectar a los demás servicios conectados.

Los datos XML son un ingrediente clave para las soluciones basadas en la arquitectura SOA. Las aplicaciones SOA basadas en XML se pueden utilizar para crear servicios web, por ejemplo.

La SOA surgió a finales de la década de 1990 y representa una etapa importante en la evolución del desarrollo y la integración de aplicaciones. Antes de que la SOA fuera una opción, conectar una aplicación monolítica a datos o funciones en otro sistema requería una compleja integración punto a punto que los desarrolladores tenían que recrear para cada nuevo proyecto de desarrollo. Exponer esas funciones a través de la SOA elimina la necesidad de recrear la integración profunda cada vez.

La SOA ofrece cuatro tipos de servicios diferentes:

1. Servicios funcionales (es decir, servicios empresariales), que son críticos para las aplicaciones empresariales.
2. Servicios empresariales, que sirven para implementar funciones.
3. Servicios de aplicación, que se utilizan para desarrollar y desplegar aplicaciones.
4. Servicios de infraestructura, que son fundamentales para los procesos de backend como la seguridad y la autenticación.

Cada servicio consta de tres componentes:

1. La interfaz, que define cómo un proveedor de servicios ejecuta las solicitudes de un consumidor de servicios.
2. El contrato, que define cómo deben interactuar el proveedor de servicios y el consumidor de servicios.
3. La implementación, que es el código de servicio.

Los servicios de SOA se pueden combinar para crear servicios y aplicaciones de nivel superior.

Al igual que la SOA, las arquitecturas de microservicios se conforman de componentes poco acoplados, reutilizables y especializados que a menudo funcionan independientemente unos de otros. Los microservicios también utilizan un alto grado de cohesión, también conocido como contexto delimitado. El contexto delimitado se refiere a la relación entre un componente y sus datos como una entidad o unidad independiente con pocas dependencias. En lugar de adoptarse en toda la empresa, los microservicios suelen comunicarse a través de interfaces de programación de aplicaciones (API) para crear aplicaciones individuales que realizan una funcionalidad empresarial específica. Este enfoque los hace más ágiles, escalables y resilientes, especialmente para áreas específicas del negocio. Por lo general, Java es el lenguaje de programación elegido para desarrollar microservicios. También se pueden utilizar otros lenguajes de programación, como Golang y Python.

Los microservicios son un enfoque arquitectónico verdaderamente nativo de la nube, que a menudo opera en contenedores, lo que los hace más escalables y portátiles para la creación de servicios independientes. Los equipos pueden utilizar microservicios para actualizar el código más fácilmente, usar diferentes pilas para diferentes componentes y escalar los componentes de forma independiente entre sí. Este enfoque reduce el desperdicio y el costo asociados con tener que escalar aplicaciones porque una sola característica podría estar enfrentando demasiada carga. Debido a su independencia, los microservicios producen servicios que son más tolerantes a fallas que las alternativas.

Vea el siguiente video para obtener más información sobre la arquitectura de microservicios:

La principal diferencia entre ambos enfoques radica en su alcance. En pocas palabras, la arquitectura orientada a servicios (SOA) tiene un alcance empresarial, mientras que la arquitectura de microservicios tiene un alcance de aplicación.

Muchos de los principios básicos de cada enfoque se vuelven incompatibles cuando se descuida esta diferencia. Si acepta la diferencia en el alcance, puede darse cuenta rápidamente de que los dos pueden complementarse entre sí, en lugar de competir.

A continuación, se presentan algunos casos de uso en los que esta distinción cobra relevancia:

En la SOA, la reutilización de las integraciones es el objetivo principal y, a nivel empresarial, es esencial esforzarse por alcanzar cierto nivel de reutilización. La reutilización y el uso compartido de componentes en una SOA aumentan la escalabilidad y la eficiencia.

En la arquitectura de microservicios, la creación de un componente de microservicios que se reutiliza en tiempo de ejecución en toda una aplicación produce dependencias que reducen la agilidad y la resiliencia. Los componentes de microservicios generalmente prefieren reutilizar el código copiando y aceptando la duplicación de datos para ayudar a mejorar el desacoplamiento.

Los servicios reutilizables en la SOA están disponibles en toda la empresa mediante el uso predominante de protocolos sincrónicos como las API RESTful.

Sin embargo, dentro de una aplicación de microservicios, las llamadas sincrónicas introducen dependencias en tiempo real, lo que provoca una pérdida de resiliencia. Estas dependencias también pueden causar latencia, lo que afecta el rendimiento. Dentro de una aplicación de microservicios, se prefieren los patrones de interacción basados en la comunicación asincrónica, como el abastecimiento de eventos, en el que se utiliza un modelo de publicación/suscripción para permitir que un componente de microservicios se mantenga actualizado sobre los cambios que ocurren en los datos de otro componente.

Un objetivo claro de la prestación de servicios en una SOA es que todas las aplicaciones obtengan y modifiquen datos de forma sincrónica directamente en su fuente principal, lo que reduce la necesidad de mantener patrones complejos de sincronización de datos.

En las aplicaciones de microservicios, lo ideal es que cada microservicio tenga acceso local a todos los datos que necesita para garantizar su independencia de otros microservicios (y, de hecho, de otras aplicaciones), incluso si esto implica cierta duplicación de datos en otros sistemas. Por supuesto, esta duplicación agrega complejidad, por lo que debe equilibrarse con las ganancias en agilidad y rendimiento, pero esto se acepta como una realidad del diseño de microservicios.

• Comunicación: en una arquitectura de microservicios, cada servicio se desarrolla de forma independiente, con su propio protocolo de comunicación. Con la SOA, cada servicio debe compartir un mecanismo de comunicación común denominado bus de servicios empresariales (ESB). La SOA gestiona y coordina los servicios que ofrece a través del ESB. Sin embargo, el ESB puede convertirse en un único punto de falla para toda la empresa, y si un solo servicio se ralentiza, todo el sistema puede verse afectado.
• Interoperabilidad: en aras de simplificar las cosas, los microservicios utilizan protocolos de mensajería ligeros como HTTP/REST (Representational State Transfers) y JMS (Java Messaging Service). Las SOA están más abiertas a protocolos de mensajería heterogéneos como SOAP (Simple Object Access Protocol), AMQP (Advanced Messaging Queuing Protocol) y MSMQ (Microsoft Messaging Queuing).
• Granularidad del servicio: las arquitecturas de microservicios se componen de servicios altamente especializados, cada uno de los cuales está diseñado para realizar una tarea concreta de manera óptima. Por otro lado, los servicios que componen las SOA pueden abarcar desde servicios pequeños y especializados hasta servicios para toda la empresa.
• Velocidad: al aprovechar las ventajas de compartir una arquitectura común, las SOA simplifican el desarrollo y la resolución de problemas. Sin embargo, esto también tiende a hacer que las SOA funcionen más lentamente que las arquitecturas de microservicios, que minimizan el intercambio en favor de la duplicación.
• Gobernanza: la naturaleza de la SOA, que implica recursos compartidos, permite la implementación de estándares comunes de gobernanza de datos en todos los servicios. La naturaleza independiente de los microservicios no permite una gobernanza de datos coherente. Esto proporciona una mayor flexibilidad para cada servicio, lo que puede fomentar una mayor colaboración en toda la organización.
• Almacenamiento de información: la SOA y los microservicios también difieren en términos de cómo se asignan los recursos de almacenamiento de información. La SOA suele incluir una única capa de almacenamiento de datos que comparten todos los servicios de una aplicación determinada, mientras que los microservicios dedican un servidor o una base de datos al almacenamiento de datos para cualquier servicio que lo necesite.

Para algunas organizaciones, la SOA es un trampolín para reemplazar el monolito, proporcionando un entorno más flexible y ágil. Los servicios de SOA se pueden desarrollar y utilizar en un entorno grande, pero no abordan las necesidades específicas de las empresas individuales que desean abordar los procesos del negocio dentro de su ámbito. DevOps se puede utilizar para ayudar a una organización a hacer la transición de la SOA a los microservicios para dirigirse a necesidades específicas.

Los estilos arquitectónicos tienen sus ventajas, así que, ¿cómo puede determinar cuál es el más adecuado para sus propósitos? En general, depende de cuán grande y diverso sea su entorno de aplicaciones.

Tanto la SOA como los microservicios pueden utilizar la automatización para acelerar los procesos empresariales. Los entornos más grandes y diversos tienden a inclinarse hacia la arquitectura orientada a servicios (SOA), que admite la integración entre aplicaciones heterogéneas y protocolos de mensajería a través de un bus de servicios empresariales (ESB). Los entornos más pequeños, incluidas las aplicaciones web y móviles, no requieren una capa de comunicación tan robusta y son más fáciles de desarrollar utilizando una arquitectura de microservicios.

Algunos señalarán que el debate de la SOA frente a los microservicios es mucho más complicado, y eso es cierto. Hay mucho más detrás de esto. Para obtener una explicación técnica más detallada de estos matices, le recomendamos que consulte los artículos del Centro de aprendizaje sobre SOA y microservicios, que proporcionan una gran cantidad de información detallada. Sin embargo, desde una perspectiva empresarial, el alcance es la distinción crucial.

• ¿Qué son los microservicios?
• ¿Qué es SOA (arquitectura orientada a servicios)?
• Metodologías ágiles frente a metodologías en cascada

Para obtener más información sobre cómo crear aplicaciones ágiles, descargue su copia gratuita del ebook Applications Architecture.