SOA, o arquitectura orientada a servicios, define una manera de conseguir 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 de arquitectura para facilitar su incorporación a nuevas aplicaciones.  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 negocio completa distinta (por ejemplo, comprobar 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 acoplamiento dinámico, que significa que se las puede llamar sin apenas conocimientos, o incluso sin ningún conocimiento sobre cómo se implementa el servicio por debajo, de forma que se reducen las dependencias entre aplicaciones. 

Esta interfaz es un contrato de servicio entre el proveedor del servicio y el consumidor del servicio. Las aplicaciones que hay tras la interfaz de servicio se pueden escribir en Java, Microsoft .Net, Cobol o cualquier otro lenguaje de programación, suministrarse como aplicaciones de software empaquetadas por un proveedor (por ejemplo, SAP), aplicaciones SaaS (por ejemplo, Salesforce CRM) u obtenerse como aplicaciones de código abierto.  Las interfaces de servicio normalmente se definen con Web Service Definition Language (WSDL), que es una estructura de etiquetas estándar basada en xml (lenguaje de marcado extensible).  

Los servicios se exponen utilizando protocolos de red estándar, como SOAP (protocolo de acceso a objetos simple)/HTTP o Restful HTTP (JSON/HTTP), para enviar solicitudes para leer o modificar datos. El gobierno del servicio controla el ciclo de vida para el desarrollo y, en la etapa adecuada, 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 crear desde cero, pero a menudo se crean exponiendo funciones desde sistemas de registro existentes como interfaces de servicio.

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

Tenga en cuenta que, aunque SOA y la más reciente arquitectura de microservicios comparten muchas palabras en común (como "servicio" y " arquitectura "), solo están vagamente relacionadas y, de hecho, trabajan en ámbitos distintos, como se describe más adelante en este artículo.

Un ESB, o bus de servicio empresarial, es un patrón de arquitectura por medio del cual un componente de software centralizado realiza integraciones entre aplicaciones.  Realiza transformaciones de modelos de datos, maneja conectividad/mensajería, realiza direccionamiento, convierte protocolos de comunicación y gestiona potencialmente la composición de varias solicitudes. El ESB permite que estas integraciones y transformaciones estén disponibles como una interfaz de servicio para que la puedan reutilizar nuevas aplicaciones. El patrón de ESB se implementa normalmente utilizando un ejecutable de integración especialmente diseñado y un conjunto de herramientas que garantizan la mejor productividad posible.

Se puede implementar una SOA sin un ESB, pero sería como tener sólo un montón de servicios.  Cada propietario de aplicaciones tendría que conectarse directamente a cualquier servicio que necesitase y realizar las transformaciones de datos correspondientes para cumplir con los requisitos de cada una de las interfaces de servicio. Esto supone mucho trabajo (incluso aunque las interfaces sean reutilizables) y plantea importantes desafíos de mantenimiento en el futuro, ya que cada conexión es de 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.

Más información sobre los ESB

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

• Mayor agilidad del negocio; comercialización más rápida: la reutilización es clave.  La eficiencia que supone ensamblar aplicaciones a partir de servicios reutilizables, como elementos básicos, en lugar de reescribir y reintegrar con cada nuevo proyecto de desarrollo, permite a los desarrolladores crear aplicaciones mucho más rápidamente en respuesta a las nuevas oportunidades de negocio. El enfoque de arquitectura orientada al servicio admite distintos escenarios para la integración de aplicaciones, la integración de datos y la automatización de estilo de la orquestación de servicios para procesos de negocio o flujos de trabajo.  Esto acelera el diseño de software y el desarrollo de software, ya que permite a los desarrolladores dedicar mucho menos tiempo a la integración y centrarse en desarrollar y mejorar sus aplicaciones. 
  
  
• Capacidad para aprovechar la funcionalidad existente en nuevos mercados: una SOA bien diseñada permite a los desarrolladores aprovechar fácilmente funcionalidad "bloqueada" en un entorno o plataforma informática y ampliarla a nuevos entornos y mercados. 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 ellos mismos a procesos e información previamente accesibles únicamente a través de la interacción directa con los empleados o los business partners de la empresa.
  
  
• Mejora de la colaboración entre negocio y TI: en una SOA, los servicios se pueden definir en términos de negocio (por ejemplo, "generar oferta de seguros" o "calcular ROI de equipamiento de capital"). Esto permite a los analistas de negocio trabajar de forma más efectiva con los desarrolladores en aspectos importantes, como el ámbito de un proceso de negocio definido por un servicio o las implicaciones empresariales 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 todos los sectores. Por ejemplo:

• Delaware Electric recurrió a SOA para integrar sistemas que antes no se comunicaban entre sí, lo que incrementó la eficiencia de desarrollo y ayudó a la organización a mantenerse solvente durante cinco años de congelamiento de las tarifas eléctricas impuesto por el estado.
  
  
• Cisco adoptó SOA para asegurarse de que su experiencia en la realización de pedidos de productos fuera coherente en todos los productos y canales exponiendo los procesos de pedidos como servicios que las divisiones, las adquisiciones y los socios comerciales de Cisco pudieran incorporar a sus sitios web.
  
  
• Independence Blue Cross (IBC), de Filadelfia, implementó una SOA para asegurarse de que los diferentes integrantes 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 el mismo origen 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 aplicación:

• SOA es un estilo de arquitectura de integración y un concepto que abarca toda la empresa. Permite que las aplicaciones existentes se expongan sobre interfaces sin conexión directa, cada una de las cuales corresponde a una función de negocio, que permite a las aplicaciones de una parte de una empresa extendida reutilizar la funcionalidad en otras aplicaciones.
  
  
• La arquitectura de microservicios es un estilo de arquitectura de aplicaciones y un concepto de ámbito de aplicación. Permite descomponer los elementos internos de una sola aplicación en piezas pequeñas que se pueden cambiar, escalar y administrar 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 ganó fuerza con el auge de la virtualización, cloud computing, las prácticas de desarrollo Agile y DevOps. La mayoría de las ventajas de los microservicios en estos contextos surgen del desacoplamiento completo de los componentes, lo que simplifica y mejora lo siguiente:

• Agilidad y productividad de los desarrolladores: los microservicios permiten a los desarrolladores incorporar nuevas tecnologías a una parte de la aplicación sin recuperar el resto de la aplicación. Cualquier componente se puede modificar, probar y desplegar independientemente de los demás, lo que acelera los ciclos de iteración.
  
  
• Escalabilidad: los microservicios pueden aprovechar al máximo la escalabilidad del cloud; 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, el fallo de un microservicio no afecta a los demás. Y cada microservicio puede cumplir sus propios requisitos de disponibilidad sin dejar de lado a los demás componentes o toda la aplicación para requisitos de disponibilidad más amplios.

Para profundizar en las diferencias entre SOA y los microservicios, consulte el artículo "SOA frente a microservicios: ¿en qué se diferencian?"

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. Teniendo en cuenta los principios de microservicios, podemos dividir potencialmente el ESB en una integración más precisa y descentralizada. Esta es una de las premisas principales en las que se basa la integración ágil.