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

La arquitectura orientada a servicios (SOA) es un enfoque empresarial para el desarrollo de

software que aprovecha los componentes o servicios de software reutilizables. Cada servicio
consta del código y las integraciones de datos necesarios para ejecutar una función comercial
específica, por ejemplo, verificar el crédito de un cliente, iniciar sesión en un sitio web o procesar
una solicitud de hipoteca.

Las interfaces de servicio proporcionan un acoplamiento flexible, lo que significa que se pueden
llamar con poco o ningún conocimiento de cómo se implementa la integración debajo. Debido a
este acoplamiento flexible y la forma en que se publican los servicios, los desarrolladores pueden
ahorrar tiempo al reutilizar componentes en otras aplicaciones en toda la empresa.

SOA surgió a fines 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 SOA fuera una opción, conectar una
aplicación a los datos o la funcionalidad de 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 SOA elimina la necesidad de recrear la integración profunda
cada vez.

¿Qué son los microservicios?

las arquitecturas de microservicios están formadas por componentes especializados,

reutilizables y poco acoplados. Sin embargo, en lugar de ser adoptados en toda la empresa, los
microservicios generalmente se usan para construir aplicaciones individuales de una manera que
las hace más ágiles, escalables y resistentes.

Los microservicios son un verdadero enfoque arquitectónico nativo de la nube y, al usarlos, los
equipos pueden actualizar el código más fácilmente, usar diferentes pilas para diferentes
componentes y escalar el componente de forma independiente, reduciendo el desperdicio y el
costo asociado con tener que escalar aplicaciones completas porque es posible que una sola
función se enfrente a demasiada carga.

La principal diferencia entre SOA y microservicios: alcance

La principal distinción entre los dos 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 potencialmente complementarse entre sí, en lugar de competir.

A continuación, se muestran algunos casos en los que entra en juego esta distinción:

Reutilizacion

En SOA, la reutilización de integraciones es el objetivo principal y, a nivel empresarial, es esencial

esforzarse por lograr cierto nivel de reutilización.

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 genera dependencias que reducen la
agilidad y la resiliencia. Los componentes de microservicios generalmente prefieren reutilizar el
código por copia y aceptar la duplicación de datos para ayudar a mejorar el desacoplamiento.

Llamadas sincrónicas

Los servicios reutilizables en SOA están disponibles en toda la empresa utilizando protocolos
predominantemente síncronos como las API RESTful .

Sin embargo, dentro de una aplicación de microservicio, las llamadas síncronas introducen
dependencias en tiempo real, lo que resulta en una pérdida de resistencia. También puede 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 origen 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 se producen en los datos de otro
componente.

Duplicación de datos

Un objetivo claro de la prestación de servicios en una SOA es que todas las aplicaciones obtengan
y realicen cambios en los datos de forma síncrona directamente en su fuente principal, lo que
reduce la necesidad de mantener patrones complejos de sincronización de datos.
En las aplicaciones de microservicios, cada microservicio idealmente tiene acceso local a todos los
datos que necesita para garantizar 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 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.

Otras diferencias clave entre SOA y 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 denominado bus
de servicio empresarial (ESB) . 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: con el fin de simplificar las cosas, los microservicios utilizan protocolos de
mensajería ligeros como HTTP / REST.

Las SOA están más abiertas a protocolos de mensajería heterogéneos.

Granularidad del servicio: las arquitecturas de microservicios se componen de servicios altamente

especializados, cada uno de los cuales está diseñado para hacer una cosa muy bien.

Los servicios que componen las SOA, por otro lado, 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, lo que minimiza el intercambio
a favor de la duplicación.

SOA frente a microservicios: ¿cuál es mejor para usted?

Ambos enfoques tienen sus ventajas, entonces, ¿cómo puede determinar cuál funcionará mejor
para sus propósitos? En general, depende de qué tan grande y diverso sea el entorno de su
aplicación. Los entornos más grandes y diversos se prestan más a 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 servicio empresarial (ESB). Los entornos más pequeños, incluidas
las aplicaciones web y móviles, no requieren una capa de comunicación tan sólida y son más
fáciles de desarrollar utilizando una arquitectura de microservicios.

MICROSERVICIOS

Conclusión
A mi modo de ver, Microservicios es una implementación concreta de
los principios que dieron lugar a SOA. Ojo, no me refiero a la
implementación que se hizo normalmente de SOA (basado en Bus) en
los últimos años, me refiero a sus principios que siguen siendo
igualmente válidos si hablamos de Microservicios.
Dicho de otro modo, no todo SOA es Microservicios, pero todo
Microservicios es SOA.

En los sistemas SOA, de manera análoga a algunos sistemas mecánicos que

poseen poleas y correas, el conjunto depende también del funcionamiento de
ciertas piezas centrales, pero ante la falla de alguna de ellas el sistema, en
general, puede seguir operando con cierta funcionalidad disminuida.

En el caso de microservicios, lo representamos como un conjunto de células,

donde cada célula cumple una función específica, interactúa con otras,
aunque por otro lado, posee la autonomía suficiente para actuar por sí sola. Ante
la falla de algunas de ellas, existen, en general, otras células que pueden
reemplazarlas.

ESB (BUS DE SERVICIO EMPRESARIAL)

En esta guía, obtenga más información sobre ESB (un componente esencial de SOA), los beneficios
que ofrece y cómo se relaciona con la arquitectura de microservicios.

¿Qué es un ESB (bus de servicio empresarial)?

Un ESB, o bus de servicio empresarial, es un patrón mediante el cual un componente de software

centralizado realiza integraciones con sistemas backend (y traducciones de modelos de datos,
conectividad profunda, enrutamiento y solicitudes) y hace que esas integraciones y traducciones
estén disponibles como interfaces de servicio para su reutilización por parte de nuevos usuarios.
aplicaciones. El patrón ESB generalmente se implementa mediante un tiempo de ejecución de
integración y un conjunto de herramientas especialmente diseñados que garantizan la mejor
productividad posible.

ESB y SOA
Un ESB es un componente esencial de SOA, o arquitectura orientada a servicios, una arquitectura
que surgió a fines de la década de 1990. SOA define una forma de hacer que los componentes de
software sean reutilizables a través de interfaces de servicio. Estas interfaces utilizan estándares
de comunicación comunes de tal manera que se pueden incorporar rápidamente en nuevas
aplicaciones sin tener que realizar una integración profunda cada vez.

Cada servicio en una SOA incorpora el código y las integraciones de datos necesarios para ejecutar
una función comercial completa y discreta (por ejemplo, verificar el crédito de un cliente, calcular
el pago mensual de un préstamo o procesar una solicitud de hipoteca). Las interfaces de servicio
proporcionan un acoplamiento flexible, lo que significa que se pueden llamar con poco o ningún
conocimiento de cómo se implementa la integración debajo. Los servicios se exponen mediante
protocolos de red estándar , como SOAP (protocolo simple de acceso a objetos) / HTTP o JSON /
HTTP, para enviar solicitudes para leer o cambiar datos. Los servicios se publican de una manera
que permite a los desarrolladores encontrarlos rápidamente y reutilizarlos para ensamblar nuevas
aplicaciones.

Estos servicios se pueden construir desde cero, pero a menudo se crean exponiendo funciones de
sistemas heredados de registro como interfaces de servicio. Aquí es donde surge la necesidad de
un ESB. Los sistemas heredados y los sistemas de registro suelen utilizar protocolos antiguos y
formatos de datos patentados que deben traducirse e integrarse para que funcionen con los
protocolos de red SOA. Un ESB realiza estas traducciones e integraciones sobre la marcha. Podría
implementar una SOA sin un ESB, pero los propietarios de las aplicaciones tendrían que encontrar
su propia forma única de exponer las interfaces de servicio, lo que supone mucho trabajo (incluso
si las interfaces finalmente se pueden volver a utilizar) y crea un importante desafío de
mantenimiento en el futuro. .

Para obtener más información sobre SOA y el papel de un ESB dentro de él, consulte "
Introducción a SOA (Arquitectura orientada a servicios) ".

Beneficios

En teoría, un ESB centralizado ofrece el potencial de estandarizar, y simplificar drásticamente, la

comunicación y la integración de servicios en toda la empresa. Los costos de hardware y software
se pueden compartir, el aprovisionamiento de los servidores solo debe realizarse una vez, y se
puede asignar la tarea (y, si es necesario, capacitar) a un solo equipo de especialistas para
desarrollar y mantener las integraciones.

Los desarrolladores pueden usar un solo protocolo para 'hablar' con el ESB y emitir comandos que
dirijan las interacciones entre los servicios y dejar que el ESB traduzca los comandos, enrute los
mensajes y transforme los datos según sea necesario para ejecutar los comandos. Esto permitiría
a los desarrolladores dedicar mucho menos tiempo a la integración y mucho más a configurar y
mejorar sus aplicaciones. Y la capacidad de reutilizar estas integraciones de un proyecto a otro
ofrecía el potencial de obtener ganancias y ahorros de productividad aún mayores en el futuro.
Pero mientras que los ESB se implementaron con éxito en muchas organizaciones, en muchas
otras organizaciones el ESB llegó a ser visto como el cuello de botella en la implementación de
SOA. Hacer cambios o mejoras en una integración a menudo desestabilizaba a otras. Las
actualizaciones del middleware de ESB a menudo afectaron a las integraciones existentes. Debido
a que el ESB se administraba de forma centralizada, los equipos de aplicaciones pronto se
encontraron esperando en fila para sus integraciones. A medida que crecía el volumen de
integraciones, la implementación de alta disponibilidad y recuperación ante desastres para los
servidores ESB se volvió más costosa. Y como un proyecto entre empresas, el ESB resultó difícil
de financiar, lo que hizo que estos desafíos técnicos fueran mucho más difíciles de resolver.

En última instancia, los desafíos de mantener, actualizar y escalar un ESB centralizado resultaron
ser tan abrumadores y costosos que el ESB a menudo retrasó las ganancias de productividad que
él y la SOA estaban destinados a producir, frustrando a los equipos de la línea de negocios que
anticipaban un mayor ritmo de trabajo. innovación.

Para profundizar en el ascenso y la caída de la ESB, lea " El destino de la ESB ".

ESB frente a microservicios

La arquitectura de microservicios permite dividir los componentes internos de una sola aplicación
en pequeñas partes que se pueden cambiar, escalar y administrar de forma independiente. Los
microservicios surgieron y ganaron fuerza con el auge de la virtualización , la computación en la
nube , las prácticas de desarrollo ágil y DevOps . En estos contextos, los microservicios ofrecen lo
siguiente:

Se mejoró la agilidad y la productividad del desarrollador al permitir que los desarrolladores

incorporen nuevas tecnologías en una parte de una aplicación sin tocar o "ponerse al día" con el
resto de la aplicación.

Escalabilidad más simple y rentable al permitir que cualquier componente se escale

independientemente de los demás, para obtener la respuesta más rápida posible a las demandas
de la carga de trabajo y el uso más eficiente de los recursos informáticos.

Mayor resiliencia, porque la falla de un componente no afecta a los demás, y cada microservicio
puede funcionar según sus propios requisitos de disponibilidad sin apostar los otros componentes
a un requisito de 'mayor disponibilidad común'.

La misma granularidad que los microservicios aportan al diseño de aplicaciones se puede llevar a la
integración, con beneficios similares. Esta es la idea detrás de la integración ágil , que divide el ESB
en componentes de integración descentralizados y detallados, sin interdependencias, que los
equipos de aplicaciones individuales pueden poseer y administrar por sí mismos.

Para profundizar en todo lo relacionado con los microservicios, consulte " Microservicios: una guía
completa ", " SOA frente a microservicios: ¿cuál es la diferencia? " Y vea el video de Dan Bettinger,
"¿Qué son los microservicios?":

VIDEO

ESB e IBM Cloud

A medida que su empresa cambia su infraestructura de TI hacia un enfoque de nube híbrida , es
muy probable que transforme una variedad de cargas de trabajo, incluidas las basadas en patrones
SOA y ESB, en modelos de implementación más ligeros y flexibles.

Estas transformaciones son solo una parte de la modernización de las aplicaciones, ya que la
demanda de mejores experiencias del cliente y más aplicaciones impactan en las operaciones
comerciales y de TI. Cuando se trata de satisfacer tales demandas, también ayuda un movimiento
hacia una mayor automatización. Idealmente, comenzaría con proyectos pequeños y de éxito
medible, que luego puede escalar y optimizar para otros procesos y en otras partes de su
organización.

Al trabajar con IBM, tendrá acceso a las capacidades de automatización impulsadas por la
inteligencia artificial , incluidos los flujos de trabajo prediseñados, para ayudar a acelerar la
innovación al hacer que cada proceso sea más inteligente.

Da el siguiente paso:

Vea cómo puede aprovechar, ampliar y modernizar sus inversiones en middleware con IBM Cloud
Pak for Integration, una solución de integración híbrida que proporciona un ciclo de vida
automatizado y de ciclo cerrado en múltiples estilos de integración empresarial.

Descubra cómo puede conectar todas sus aplicaciones y datos a través de múltiples nubes
públicas y privadas para experiencias personalizadas del cliente al ver las soluciones de integración
de IBM Cloud .

Obtenga la IBM Application Modernization Field Guide para aprender cómo acelerar la
modernización, mejorar la productividad del desarrollador y mejorar la eficiencia operativa y la
estandarización.

Realice nuestra evaluación de madurez de integración para evaluar su nivel de madurez de

integración en dimensiones críticas y descubra las acciones que puede tomar para pasar al
siguiente nivel.

Descargue nuestra guía de integración ágil , que explora las ventajas de un enfoque basado en
contenedores, descentralizado y alineado con microservicios para integrar soluciones.

Lea acerca de los cinco "imprescindibles" para el éxito de la automatización (el enlace se
encuentra fuera de IBM) en este informe de investigación de HFS.

Empiece hoy mismo con una cuenta de IBM Cloud .