SOA vs. microservicios: ¿cuál es la diferencia?

Si trabaja en TI o en el campo del cloud computing, probablemente esté al tanto del debate entre la arquitectura orientada a servicios (SOA) y los microservicios. Después de todo, todo el mundo habla estos días de microservicios y aplicaciones ágiles.

A primera vista, los dos enfoques parecen similares y, en cierto modo, lo son. Ambos implican entornos de nube o nube híbrida para un desarrollo e implementación ágiles de las aplicaciones, y ambos pueden escalarse para cumplir con las exigencias operativas y de velocidad del big data. Ambos dividen las aplicaciones grandes y complejas en componentes pequeños y flexibles con los que es más fácil trabajar. Y ambos difieren de una arquitectura tradicional monolítica en que cada servicio tiene su propia responsabilidad.

Sin embargo, incluso con estos puntos en común clave, un examen más detallado de los dos enfoques revela diferencias importantes.

La arquitectura orientada a servicios (SOA) es un enfoque empresarial para el desarrollo de componentes de aplicación que se benefician de los componentes de software reutilizables o servicios. En la arquitectura de software SOA, cada servicio está compuesto por el código y las integraciones de datos necesarios para ejecutar una función empresarial específica: por ejemplo, comprobar el crédito de un cliente, acceder a un sitio web o procesar una solicitud de hipoteca

Las interfaces de servicio proporcionan un acoplamiento dinámico, lo que significa que pueden ser llamadas con poco o ningún conocimiento de cómo se implementa la integración por debajo. Gracias a este acoplamiento dinámico y a la forma en que se publican los servicios, los equipos de desarrollo pueden ahorrar tiempo reutilizando componentes en otras aplicaciones de la empresa. Esto supone tanto un beneficio como un riesgo. Como resultado del acceso compartido al bus de servicios empresariales (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 pueden utilizarse 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 de otro sistema requería una compleja integración punto a punto que los desarrolladores tenían que volver a crear para cada nuevo proyecto de desarrollo. Exponer esas funciones a través de SOA elimina la necesidad de recrear la integración profunda cada vez.

SOA proporciona 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 e implementar aplicaciones.
4. Servicios de infraestructura, que son fundamentales para 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 y el consumidor del servicio.
3. La implementación, que es el código de servicio.

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

Al igual que la SOA, las arquitecturas de microservicios se componen de componentes especializados, reutilizables y poco acoplados que suelen funcionar de forma independiente unos de otros. Los microservicios también usan un alto grado de cohesión, también conocido como contexto delimitado. El contexto limitado se refiere a la relación entre un componente y sus datos como una entidad o unidad autónoma con pocas dependencias. En lugar de adoptarse en toda la empresa, los microservicios suelen comunicarse a través de interfaz 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 en áreas específicas de la empresa. Normalmente, Java es el lenguaje de programación elegido para desarrollar microservicios. También se pueden usar otros lenguajes de programación, como Golang y Python.

Los microservicios son un verdadero enfoque arquitectónico nativo de la nube, que a menudo funcionan 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, utilizar pilas diferentes para componentes distintos y escalar los componentes independientemente unos de otros. Este planteamiento reduce el despilfarro y el coste que supone tener que escalar aplicaciones porque una única característica puede estar soportando demasiada carga. Debido a su independencia, los microservicios producen servicios que son más tolerantes a fallos que las alternativas.

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

La principal distinción entre ambos enfoques se reduce al 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 de alcance, puede darse cuenta rápidamente de que los dos pueden complementarse entre sí, en lugar de competir.

Estos son algunos casos de uso en los que entra en juego esta distinción:

En la SOA, la reutilización de las integraciones es el objetivo principal y, a nivel empresarial, es esencial esforzarse por conseguir algún nivel de reutilización. La reutilización y el uso compartido de componentes en una arquitectura SOA aumentan la escalabilidad y la eficacia.

En la arquitectura de microservicios, la creación de un componente de microservicio que se reutiliza en tiempo de ejecución en toda una aplicación da como resultado 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 de la SOA están disponibles en toda la empresa mediante protocolos predominantemente sincrónicos, como las API RESTful.

Sin embargo, dentro de una aplicación de microservicios, las llamadas síncronas introducen dependencias en tiempo real, lo que se traduce en una pérdida de resiliencia. Estas dependencias también pueden causar latencia, lo que afecta al rendimiento. Dentro de una aplicación de microservicios, se prefieren los patrones de interacción basados en la comunicación asíncrona, como el abastecimiento de eventos, en el que se utiliza un modelo de publicación/suscríbase para permitir que un componente de microservicios se mantenga actualizado sobre los cambios que se producen 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 alteren los datos de forma sincrónica directamente en su fuente primaria, 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 asegurar su independencia de otros microservicios (y de hecho de otras aplicaciones) incluso si esto significa cierta duplicación de datos en otros sistemas. Por supuesto, esta duplicación añade 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 SOA, cada servicio debe compartir un mecanismo de comunicación común que se denomina bus de servicios empresariales (ESB). La SOA gestiona y coordina los servicios que presta a través de la ESB. Sin embargo, el ESB puede convertirse en un punto único de fallo para toda la empresa, y si un solo servicio se ralentiza, todo el sistema puede verse afectado.
• Interoperabilidad: para simplificar las cosas, los microservicios utilizan protocolos de mensajería ligeros, como HTTP/REST (transferencias de estado representacional) y JMS (servicio de mensajería de Java). 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 de los servicios: las arquitecturas de microservicios se componen de servicios altamente especializados, cada uno de los cuales está diseñado para hacer una cosa muy bien. Por otro lado, los servicios que componen las SOA pueden ser desde pequeños servicios especializados hasta servicios para toda la empresa.
• Rapidez: 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 uso compartido 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 gobierno de datos en todos los servicios. La naturaleza independiente de los microservicios no permite un gobierno 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: la SOA y los microservicios también difieren en términos de cómo se asignan los recursos de almacenamiento. La arquitectura SOA suele incluir una única capa de almacenamiento de datos que comparten todos los servicios de una aplicación determinada, mientras que los microservicios dedicarán un servidor o base de datos para el almacenamiento de datos para cualquier servicio que lo necesite.

Para algunas organizaciones, la arquitectura SOA es un trampolín para reemplazar el monolito, proporcionando un entorno más flexible y ágil. Los servicios 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 comerciales dentro de su ámbito. DevOps se puede utilizar para ayudar a una organización a pasar de la arquitectura SOA a microservicios para abordar necesidades específicas.

Los estilos arquitectónicos tienen sus ventajas, así que ¿cómo puede determinar cuál funciona mejor para sus propósitos? En general, depende del tamaño y la diversidad de su entorno de aplicaciones.

Tanto SOA como los microservicios pueden utilizar la automatización para acelerar los procesos empresariales. Los entornos más grandes y diversos tienden a inclinarse por la arquitectura orientada a los 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 la SOA vs. el debate sobre los microservicios es mucho más complicado, y eso es cierto. Hay mucho más de lo que parece. Para una explicación técnica más detallada de estos matices, le animamos a que profundice en los artículos de SOA y microservicios de Learn Hub, que proporcionan una gran cantidad de información. Sin embargo, desde una perspectiva empresarial, el alcance es la distinción crucial.

• ¿Qué son los microservicios?
• ¿Qué es SOA (arquitectura orientada a servicios)?
• Agile vs. Waterfall

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