SOA, o arquitectura orientada a servicios, define una manera de hacer que los componentes de software sean reutilizables a través de interfaces de servicio. Los servicios utilizan estándares de interfaz comunes y un patrón arquitectónico para que puedan incorporarse rápidamente a aplicaciones nuevas. De este modo, se evitan determinadas tareas al desarrollador de aplicaciones, que antes debía volver a desarrollar o duplicar la funcionalidad existente o tenía que saber cómo conectar o proporcionar interoperatividad con las funciones existentes.

Cada servicio de una SOA incorpora el código y las integraciones de datos necesarias para ejecutar una  función de negocios completa y discreta (por ejemplo, comprobar el crédito de un cliente, calcular un pago de préstamo mensual o procesar una solicitud de hipoteca). Las interfaces de servicio proporcionan acoplamiento suelto, lo que significa que se pueden invocar con poco o ningún conocimiento de cómo el servicio se implementa de manera subyacente, reduciendo las dependencias entre aplicaciones. 

Esta interfaz es un contrato de servicios entre el proveedor de servicios y el consumidor de servicios. Las aplicaciones detrás de la interfaz de servicios se pueden escribir en Java, Microsoft .Net, Cobol o en cualquier otro lenguaje de programación, suministrado como aplicaciones de software empaquetadas por un proveedor (por ejemplo, SAP), aplicaciones SaaS (por ejemplo, Salesforce CRM) u obtenidas como aplicaciones de código abierto. Las interfaces de servicio se definen con frecuencia utilizando un Lenguaje de Descripción de Servicios Web (WSDL), que es una estructura de etiqueta estándar basada en xml (lenguaje de marcado extensible).  

Los servicios se exponen utilizando protocolos de red estándar, como SOAP (protocolo simple de acceso a objetos)/HTTP o Restful HTTP (JSON/HTTP), para enviar solicitudes para leer o cambiar datos. La gestión del servicio controla el ciclo de vida para el desarrollo y, en la etapa que corresponde, los servicios se publican en un registro que permite a los desarrolladores encontrarlos rápidamente y reutilizarlos para ensamblar nuevas aplicaciones o procesos de negocio.

Estos servicios se pueden desarrollar desde cero, pero es común que se creen exponiendo funciones de sistemas heredados de registro como interfaces de servicio.

De este modo, en las últimas décadas, la SOA representa una etapa importante en la evolución del desarrollo de aplicaciones y la integración. Antes de que surgiese la SOA a fines de la década de 1990, la conexión de una aplicación a datos o funcionalidad alojada en otro sistema requería una compleja integración punto a punto, integración que los desarrolladores tenían que recrear, en parte o en su totalidad, para cada nuevo proyecto de desarrollo. Exponer esas funciones a través de servicios de SOA permitía al desarrollador simplemente reutilizar la capacidad existente y conectarse a través de la arquitectura SOA ESB (consulte a continuación).

Tenga en cuenta que aunque la SOA y la arquitectura de microservicios más reciente comparten muchas palabras en común (es decir, "servicio" y "arquitectura"), solo están relacionadas de manera vaga y, de hecho, operan en diferentes ámbitos, como se explica más adelante en este artículo.

Un ESB, o bus de servicios empresariales, es un patrón arquitectónico mediante el cual un componente de software realiza integraciones entre aplicaciones.  Realiza transformaciones de modelos de datos, se encarga de la conectividad/mensajería, realiza enrutamiento, convierte protocolos de comunicacion y potencialmente gestiona la composición de múltiples solicitudes. Los ESB pueden encargarse de estas integraciones y transformaciones disponibles como interfaces de servicio para su reutilización por nuevas aplicaciones. El patrón ESB generalmente se implementa en un entorno de ejecución de integración especialmente diseñado y un conjunto de herramientas que garantizan la mejor productividad posible.

Es posible implementar una SOA sin un ESB, pero esto equivaldría a tener un montón de servicios.  Cada propietario de la aplicación debería conectarse directamente a cualquier servicio que necesite y realizar las transformaciones de datos necesarias para cumplir con cada una de las interfaces de servicio. Esto es mucho trabajo (incluso si las interfaces son reutilizables) y crea importantes desafíos de mantenimiento en el futuro, ya que cada conexión es punto a punto.  De hecho, con el tiempo, los ESB llegaron a ser considerados un elemento tan propio de cualquier implementación de SOA que los dos términos se utilizan a veces como sinónimos, lo que genera confusión.

Lea más acerca de ESB

En comparación con las arquitecturas que le precedieron, SOA ofrece importantes ventajas a la empresa:

• Mayor agilidad empresarial, comercialización más rápida: la reutilización es clave. La eficiencia de ensamblar aplicaciones a partir de servicios reutilizables, es decir bloques de construcción, en lugar de reescribir y reintegrar con cada nuevo proyecto de desarrollo, permiten a los desarrolladores crear aplicaciones con mucha mayor rapidez en respuesta a nuevas oportunidades comerciales. El enfoque arquitectónico orientado al servicio admite escenarios para la integración de aplicaciones, la integración de datos y la automatización del estilo de orquestación de servicios de los procesos de negocio o flujos de trabajo. Esto acelera el diseño de software y el desarrollo de software al permitir que los desarrolladores dediquen mucho menos tiempo a la integración y mucho más tiempo a la entrega y mejora de sus aplicaciones. 
  
  
• Capacidad para aprovechar la funcionalidad heredada en nuevos mercados: una SOA bien lograda permite a los desarrolladores adoptar fácilmente una funcionalidad "bloqueada" en una plataforma o entorno informático y llevarla a entornos y mercados nuevos. Por ejemplo, muchas empresas han utilizado SOA para exponer la funcionalidad de los sistemas financieros basados ​​en mainframe a nuevas aplicaciones web, lo que permite a sus clientes acceder a procesos e información que antes solo eran accesibles a través de la interacción directa con los empleados o business partners de la empresa.
  
  
• Mejora en la colaboración entre la empresa y la TI: en una SOA, los servicios se pueden definir en términos comerciales (por ejemplo, "generar oferta de seguros" o "calcular ROI de equipamiento de capital"). Esto permite a los analistas de negocio trabajar más eficazmente con los desarrolladores en aspectos importantes, como el ámbito de un proceso de negocio definido por servicios o las implicaciones para los negocios de cambiar un proceso, lo que puede generar mejores resultados.

En 2010, las implementaciones de SOA estaban en plena expansión entre las empresas líderes en prácticamente todas las industrias. Por ejemplo:

• Delaware Electric recurrió a SOA para integrar sistemas que anteriormente no se comunicaban entre sí, lo que resultó en eficiencias de desarrollo que ayudaron a la organización a mantenerse solvente durante un congelamiento de tarifas eléctricas de cinco años exigido por el estado.
  
  
• Cisco adoptó SOA para asegurarse de que su experiencia de pedido de productos fuera consistente en todos los productos y canales al exponer los procesos de pedido como servicios que las divisiones, adquisiciones y business partners de Cisco podrían incorporar en sus sitios web.
  
  
• Independence Blue Cross (IBC) de Filadelfia implementó una  SOA  para asegurar que los diferentes componentes que se ocupan de los datos de los pacientes (los agentes del servicio al cliente de IBC, las consultas de los médicos y los usuarios del sitio web de IBC) estuvieran trabajando con la misma fuente de datos (una "única fuente de verdad").

Los expertos han escrito miles de páginas de literatura impresa y digital comparando SOA y microservicios y definiendo las sutilezas de la relación entre estos dos conceptos. A efectos del presente artículo, las principales diferencias entre ambos son el acoplamiento de componentes y el ámbito de uso:

• SOA es un estilo arquitectónico de integración y un concepto que se aplica a toda la empresa. Permite que las aplicaciones existentes se expongan a través de interfaces débilmente acopladas, cada una de las cuales corresponde a una función de negocios, lo que permite que las aplicaciones en una parte de una empresa extendida reutilicen la funcionalidad en otras aplicaciones.
  
  
• La arquitectura de microservicios es una aplicación de estilo arquitectónico y un concepto de aplicación. Permite que los datos internos de una sola aplicación se dividan en partes pequeñas que se pueden cambiar, escalar y gestionar de forma independiente. No define cómo se comunican entre sí las aplicaciones. Para ello, volvemos al ámbito empresarial de las interfaces de servicio proporcionadas por SOA.

La arquitectura de microservicios surgió y cobró fuerza con el auge de la virtualización, la computación en la nube, las prácticas de desarrollo de Agile y DevOps. La mayoría de las ventajas de los microservicios en estos contextos surgen del desacoplamiento de los componentes, lo que simplifica y mejora los siguientes aspectos:

• Agilidad y productividad del desarrollador: los microservicios permiten a los desarrolladores incorporar nuevas tecnologías a una parte de la aplicación sin afectar al resto de la aplicación. Cualquier componente se puede modificar, probar e implementar independientemente de los demás, lo que acelera los ciclos de iteración.
  
  
• Escalabilidad: los microservicios pueden aprovechar al máximo la escalabilidad de la nube. Cualquier componente se puede escalar independientemente de los demás para obtener la respuesta más rápida posible a las demandas de carga de trabajo y el uso más eficiente de los recursos informáticos.
  
  
• Resiliencia: de nuevo, gracias al desacoplamiento, la falla de un microservicio no afecta a los demás. Y cada microservicio puede cumplir sus propios requisitos de disponibilidad sin dejar de lado los demás componentes o toda la aplicación a los mayores requisitos de disponibilidad común.

Para profundizar en las diferencias entre SOA y los microservicios, consulte "SOA frente a microservicios: ¿cuál es la diferencia?"

De la misma manera que la arquitectura de microservicios tiene el potencial de aportar mejoras en agilidad, escalabilidad y resiliencia al diseño de aplicaciones, estas mismas técnicas también se pueden aplicar a la integración. Esto es importante porque, con el tiempo, el patrón de ESB fuertemente centralizado y su equipo de especialistas en integración centralizado y asociado pueden provocar un cuello de botella. Tomando en cuenta los principios de microservicios, podemos potencialmente dividir el ESB en una integración más precisa y descentralizada. Esta es una de las premisas fundamentales detrás de integración ágil.