Los conceptos de la SOA y la arquitectura de microservicios son similares, por lo que la gente suele confundirlos. La principal característica que los distingue es su alcance: la SOA es un enfoque de arquitectura para toda la empresa, mientras que los microservicios son una estrategia de implementación que utilizan los equipos de desarrollo de aplicaciones.
Además, la comunicación con sus respectivos elementos también es diferente. La SOA utiliza un ESB, y los microservicios se pueden comunicar entre sí sin estado, a través de las API que no dependen de un lenguaje. La independencia de las API también permite que los equipos de desarrollo puedan elegir con qué herramientas desean trabajar. En este sentido, los microservicios pueden ser más adaptables y flexibles.
¿Qué es la arquitectura orientada a los servicios (SOA)?
La SOA integra los elementos del software que se implementan y se mantienen por separado, y permite que se comuniquen entre sí y trabajen en conjunto para formar aplicaciones de software en distintos sistemas.
La SOA expone los servicios utilizando protocolos estándar de red para enviar solicitudes o acceder a los datos (p. ej., SOAP, JSON, ActiveMQ o Apache Thrift), no es necesario que los desarrolladores realicen las integraciones desde cero. De hecho, pueden utilizar los patrones llamados buses de servicios empresariales (ESB) para integrar un elemento centralizado y los sistemas de backend, y ponerlos a disposición de todos como interfaces de servicios. Asimismo, pueden reutilizar las funciones actuales en vez de volver a crearlas.
En otras palabras, piense en la arquitectura orientada a los servicios, la cual estructura las aplicaciones en servicios diferentes y reutilizables que se comunican a través de un bus de servicios empresariales (ESB). En ella, cada servicio se organiza en torno a un proceso empresarial en particular y cumple con un protocolo de comunicación (por ejemplo, SOAP, ActiveMQ o Apache Thrift) para admitir el uso compartido por medio del ESB. Todo el conjunto de servicios que se integra con el bus conforma la aplicación.
Por un lado, esto permite que los servicios se diseñen, se prueben y se optimicen de forma simultánea, sin recurrir a ciclos de desarrollo monolítico. Por otro lado, el ESB representa un punto único de fallas para todo el sistema. En el intento de eliminar la estructura monolítica, se creó una estructura similar que podría bloquear todos los procesos de la empresa.
¿Qué es una arquitectura de microservicios?
Un microservicio es una función principal de la aplicación que se ejecuta de forma independiente de las demás. Sin embargo, la arquitectura basada en ellos no solo abarca las funciones que no están conectadas de forma directa, sino que incluye la restructuración de los equipos de desarrollo y la comunicación entre las funciones con el objetivo de prepararse para las fallas inevitables, la futura necesidad de adaptación y la integración de las funciones nuevas.
La transición de la arquitectura orientada los servicios a los microservicios
Los microservicios pueden establecer una comunicación (por lo general, sin estado) entre sí, por lo que las aplicaciones diseñadas con ellos son más tolerantes a los errores y dependen menos de un único ESB. Esto también permite que los equipos de desarrollo elijan sus propias herramientas, ya que los microservicios pueden comunicarse a través de interfaces de programación de aplicaciones (API) que no dependen de ningún lenguaje.
SOAP vs RESTFul
Fuentes:
https://www.redhat.com/es/topics/cloud-native-apps/what-is-service-oriented-architecture#resumen
https://www.redhat.com/es/topics/microservices/what-are-microservices
https://rootstack.com/es/blog/esb-estructura-soa-diferencias
https://www.uv.mx/personal/ermeneses/files/2020/09/Clase1-Introduccion.pdf
https://www.udemy.com/course/java-web-services/
Comentarios
Publicar un comentario