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

SOA elimina tareas del desarrollador de aplicaciones que previamente volvió a desarrollar o duplicó funciones existentes o tuvo que saber cómo conectarse o proporcionar interoperabilidad con funciones existentes.

Cada servicio de una SOA incorpora el código y los datos necesarios para ejecutar una función empresarial completa y discreta (por ejemplo, comprobar el crédito de un cliente, calcular el pago mensual de un préstamo o procesar una aplicación de hipoteca). Las interfaces de servicio proporcionan un acoplamiento flexible. Esto significa que se pueden llamar con poco o ningún conocimiento de cómo se implementa el servicio subyacente, lo que reduce las dependencias entre aplicaciones.

Esta interfaz es un contrato de servicio entre el proveedor de servicios y el consumidor de servicios. Las aplicaciones detrás de la interfaz de servicio pueden escribirse 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 se definen con frecuencia mediante el lenguaje de definición de servicios web (WSDL), que es una estructura de etiquetas estándar basada en xml (lenguaje de marcado extensible).

Los servicios se exponen mediante el uso de protocolos de red estándar, como el protocolo simple de acceso a objetos (SOAP)/HTTP o Restful HTTP (JSON/HTTP), para enviar solicitudes para leer o cambiar datos. La gobernanza 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 comerciales.

Estos servicios se pueden crear desde cero, pero a menudo se crean exponiendo funciones de sistemas herredados de registro como interfaces de servicio.

De esta manera, 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 fines de la década de 1990, conectar una aplicación a datos o funciones alojados en otro sistema requería una integración compleja 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 los servicios SOA permitió al desarrollador simplemente reutilizar la capacidad existente y conectarse a través de la arquitectura SOA ESB (ver más abajo).

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 vagamente relacionadas y, de hecho, operan en diferentes ámbitos, como se analiza más adelante en este artículo.

Un ESB, o bus de servicio empresarial, es un patrón arquitectónico mediante el cual un componente de software centralizado realiza integraciones entre aplicaciones. Realiza transformaciones de modelos de datos, maneja conectividad y mensajería, realiza enrutamiento, convierte protocolos de comunicación y gestiona potencialmente la composición de múltiples solicitudes.

El ESB puede hacer que estas integraciones y transformaciones estén disponibles como interfaz de servicio para su reutilización por nuevas aplicaciones. El patrón ESB generalmente se implementa mediante el uso de un tiempo de ejecución de integración y un conjunto de herramientas especialmente diseñados que ayudan a garantizar la mejor productividad posible.

Es posible implementar una SOA sin un ESB, pero esto sería equivalente a tener un montón de servicios. Cada propietario de la aplicación tendría que conectarse directamente con cualquier servicio que necesite y realizar las transformaciones de datos necesarias para satisfacer cada una de las interfaces de servicio.

Esto es mucho trabajo (incluso si las interfaces son reutilizables) y crea un desafío de mantenimiento significativo en el futuro, ya que cada conexión es punto a punto. De hecho, los ESB finalmente se consideraron un elemento de facto de cualquier implementación de SOA que los dos términos a veces se utilizan como sinónimos, creando confusión.

En comparación con las arquitecturas que la precedieron, SOA ofreció beneficios significativos a la empresa:

• Mayor agilidad empresarial; tiempo de comercialización más rápido: 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, permite a los desarrolladores crear aplicaciones mucho más rápido en respuesta a nuevas oportunidades de negocio.
  El enfoque arquitectónico orientado a servicios 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 procesos de negocio o flujos de trabajo. Esto acelera el diseño y el desarrollo de software al permitir a los desarrolladores dedicar mucho menos tiempo a la integración y más tiempo a centrarse en entregar y mejorar sus aplicaciones.
• Capacidad para utilizar funciones heredadas/existentes en nuevos mercados: una SOA bien diseñada permite a los desarrolladores tomar fácilmente funciones "bloqueadas" en una plataforma o entorno informático y extenderlas a nuevos entornos y mercados. Por ejemplo, muchas empresas han utilizado SOA para exponer funciones de sistemas financieros basados en mainframe a nuevas aplicaciones web. Esto permite a sus clientes acceder a procesos e información a los que antes solo se podía acceder a través de la interacción directa con los empleados o asociados de negocios de la empresa.
• Colaboración mejorada entre el negocio y TI: en una SOA, los servicios se pueden definir en términos comerciales (por ejemplo, "generar cotización de seguros" o "calcular el retorno de la inversión (ROI) de equipamiento"). Esto permite a los analistas de negocio trabajar de manera más eficaz con los desarrolladores en insights importantes, como el alcance de un proceso de negocio definido mediante el uso de servicios o las implicaciones comerciales de cambiar un proceso, que pueden conducir a un mejor resultado.

En 2010, las implementaciones de SOA iban a toda marcha en empresas líderes de prácticamente todas las industrias. Por ejemplo:

Delaware Electric recurrió a SOA para integrar sistemas que antes no se comunicaban entre sí, lo que resultó en eficiencias de desarrollo que ayudaron a la organización a mantenerse solvente durante una congelación de cinco años exigida por el estado en las tarifas eléctricas.

Cisco adoptó SOA para asegurarse de que su Experiencia de pedido de productos fuera coherente en todos los productos y canales al exponer los procesos de pedido como servicios que las divisiones, adquisiciones y asociados de negocios de Cisco podrían incorporar a sus sitios web.

Independence Blue Cross (IBC) de Filadelfia implementó una SOA para ayudar a garantizar que los diferentes componentes que se ocupan de los datos de los pacientes—agentes de atención al cliente de IBC, consultorios médicos, usuarios del sitio web de IBC—estuvieran trabajando con la misma fuente de datos (una ‘única fuente de verdad’).

Los expertos han llenado miles de páginas impresas y digitales comparando SOA y microservicios, y definiendo las sutilezas de su relación entre sí. A los efectos de este artículo, las principales diferencias entre los dos son el acoplamiento de los componentes y el ámbito de uso:

SOA es un estilo arquitectónico de integración y un concepto para 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 empresarial que permite que las aplicaciones en una parte de una empresa extendida reutilicen funciones en otras aplicaciones.

La arquitectura de microservicios es un estilo arquitectónico de aplicación y un concepto de ámbito de aplicación. Permite dividir los componentes internos de una sola aplicación en pequeñas partes que se pueden cambiar, escalar y administrar de forma independiente. No define cómo las aplicaciones se comunican entre sí, por lo que volvemos al ámbito empresarial de las interfaces de servicio proporcionadas por SOA.

Los microservicios surgieron y ganaron fuerza con el aumento de la virtualización, la computación en la nube, las prácticas de desarrollo ágil 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 lo siguiente:

• 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 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 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: nuevamente, gracias al desacoplamiento, la falla de un microservicio no afecta a los demás. Y cada microservicio puede funcionar según sus propios requisitos de disponibilidad sin poner en juego los otros componentes o toda la aplicación a los mayores requisitos de disponibilidad comunes.

Para profundizar en las diferencias entre SOA y microservicios,consulte SOA versus Microservices: What's the difference?

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 ESB fuertemente centralizado y su equipo centralizado asociado de especialistas en integración pueden convertirse en un cuello de botella. Tomando prestados los principios de los microservicios, podemos dividir el ESB en una integración más detallada y descentralizada. Esta es una de las premisas centrales detrás de la integración ágil.