La arquitectura orientada a servicios, conocida como SOA por sus siglas en inglés (Service-Oriented Architecture), es una forma de diseñar y organizar aplicaciones de software para que sean más flexibles, reutilizables y fáciles de mantener. Puede compararse con construir una casa con piezas prefabricadas, en lugar de fabricar cada habitación desde cero, se utilizan módulos ya terminados que pueden ensamblarse de diferentes maneras según las necesidades. En el desarrollo de software ocurre algo parecido. SOA propone dividir una aplicación en servicios independientes, cada uno especializado en realizar una tarea concreta, que pueden combinarse para formar aplicaciones más complejas.
Cuando una persona pide comida a domicilio mediante una aplicación, intervienen varios participantes que trabajan de forma independiente. El restaurante prepara el pedido, la plataforma coordina la solicitud y el repartidor realiza la entrega. Aunque cada uno cumple una función distinta, todos colaboran para ofrecer una experiencia única al usuario. De manera similar, en una arquitectura SOA cada servicio realiza una función específica del negocio, como validar la identidad de un cliente, procesar un pago, consultar el inventario o generar una factura. Estos servicios se comunican entre sí mediante interfaces y protocolos estandarizados, lo que les permite trabajar de forma coordinada sin depender de cómo fueron desarrollados internamente.
Cada servicio funciona como una “caja negra”: los demás sistemas conocen qué tarea realiza y cómo solicitarla, pero no necesitan conocer su funcionamiento interno. Gracias a ello, un servicio puede estar programado en un lenguaje diferente, ejecutarse en otro servidor o incluso pertenecer a otra organización, y aun así integrarse sin dificultades con el resto del sistema. Esta capacidad de colaboración se conoce como interoperabilidad y está estrechamente relacionada con otro principio fundamental de SOA: el acoplamiento débil o loose coupling. Este principio busca que los servicios dependan lo menos posible unos de otros, facilitando su sustitución, actualización o reutilización.
La arquitectura SOA comenzó a consolidarse a finales de la década de 1990 y alcanzó una gran popularidad durante los años 2000. En esa época, muchas organizaciones dependían de sistemas antiguos, que eran esenciales para el funcionamiento del negocio, pero resultaban difíciles de integrar con nuevas aplicaciones. SOA surgió como una estrategia para resolver este problema, proponiendo una arquitectura donde los servicios se diseñan pensando en las necesidades globales de la organización y no únicamente en un proyecto específico. En numerosas implementaciones, la comunicación entre servicios se apoyaba en un bus de servicios empresariales (ESB, Enterprise Service Bus), cuya función consistía en enrutar mensajes, transformar datos y coordinar la interacción entre aplicaciones. Aunque el ESB facilitó la integración de sistemas muy diversos, también llegó a convertirse en el componente más complejo de muchas arquitecturas. Cuando su diseño no era adecuado o se concentraban demasiadas responsabilidades en él, podía transformarse en un cuello de botella e incluso en un punto crítico cuya indisponibilidad afectaba a múltiples servicios.
Durante el periodo de mayor adopción, aproximadamente entre 2005 y 2012, muchas empresas implementaron iniciativas basadas en SOA para integrar sus sistemas heredados sin tener que reemplazarlos por completo. Este enfoque permitió reutilizar aplicaciones ya existentes, reducir el costo de desarrollar nuevas soluciones y facilitar el intercambio de información entre departamentos y plataformas que anteriormente funcionaban de manera aislada.
Un banco ofrece un buen ejemplo de este enfoque. Al abrir una cuenta, la aplicación puede utilizar un servicio para verificar la identidad del cliente, otro para evaluar su historial crediticio, uno más para crear la cuenta y otro para enviar un correo electrónico de bienvenida. Cada uno de estos servicios funciona de manera independiente, por lo que, si cambian las reglas para evaluar el crédito debido a una nueva regulación, únicamente será necesario actualizar ese servicio, sin modificar el resto del sistema. Esta independencia permite introducir nuevas funcionalidades con mayor rapidez, reducir costos de desarrollo y simplificar el mantenimiento de las aplicaciones.
Entre las principales ventajas de SOA destacan la reutilización de servicios, la escalabilidad y la facilidad de mantenimiento. Al aprovechar componentes ya existentes, las organizaciones reducen el tiempo y los recursos necesarios para desarrollar nuevas aplicaciones. Además, cuando ocurre un problema, este suele quedar limitado al servicio afectado, disminuyendo el impacto sobre el resto del sistema. SOA también favorece la colaboración entre equipos de desarrollo, ya que cada grupo puede especializarse en la creación y mejora de determinados servicios que posteriormente serán utilizados por otras aplicaciones. Desde el punto de vista del negocio, esta arquitectura facilita la integración con nuevos socios comerciales, la incorporación de nuevas plataformas y la adaptación de los sistemas a las cambiantes necesidades del mercado.
Sin embargo, en 2009, la analista Anne Thomas Manes, del entonces Burton Group, generó un intenso debate al publicar el artículo “SOA ha muerto, larga vida a los servicios” (SOA is dead, long live services), donde argumentaba que muchas implementaciones se habían vuelto excesivamente complejas, costosas y cargadas de procesos burocráticos. Su crítica no significaba que los principios de SOA hubieran dejado de ser útiles, sino que muchas organizaciones habían convertido la arquitectura en un conjunto de procedimientos difíciles de administrar, alejándose de su propósito original de simplificar la integración de sistemas.
Los resultados de las primeras grandes implementaciones reflejaron estos desafíos. Una proporción considerable de los grandes proyectos de SOA no alcanzó el retorno de inversión esperado. Las causas más frecuentes fueron la falta de una adecuada gobernanza, la complejidad de las integraciones, los elevados costos de infraestructura y la dificultad para coordinar el desarrollo de numerosos servicios compartidos entre distintas áreas de una organización.
Uno de los problemas más curiosos observados durante la adopción de SOA fue la aparición del llamado “monolito distribuido”. Paradójicamente, algunas organizaciones intentaron dividir sus aplicaciones en numerosos servicios independientes, pero estos terminaron dependiendo tanto unos de otros que el fallo de un solo servicio podía afectar a todo el sistema. En lugar de obtener una arquitectura flexible, se creó un entorno distribuido cuya complejidad hacía que cualquier cambio o interrupción tuviera consecuencias en cadena.
Otro aspecto característico de aquella época fue el uso generalizado del protocolo simple de acceso a objetos (SOAP, Simple Object Access Protocol), basado en XML. Aunque ofrecía un conjunto muy amplio de funcionalidades relacionadas con seguridad, confiabilidad y transacciones, también generaba mensajes considerablemente más grandes que los datos útiles que transportaban. En muchas aplicaciones, las cabeceras y la información adicional ocupaban más espacio que el propio contenido del mensaje, lo que incrementaba el consumo de ancho de banda y el tiempo de procesamiento, especialmente en sistemas con un gran volumen de transacciones.
A pesar de estas limitaciones y obstáculos, grandes instituciones financieras, compañías de seguros, empresas de telecomunicaciones y organismos gubernamentales han utilizado arquitecturas basadas en SOA para procesar enormes volúmenes de operaciones diarias con niveles de disponibilidad extremadamente altos, cercanos al denominado “cinco nueves” (99.999%), un estándar ampliamente utilizado para describir sistemas con una muy alta confiabilidad.
SOA dejó una huella profunda en la ingeniería de software. Muchos de los principios que hoy caracterizan a las arquitecturas de microservicios, como el desacoplamiento, la reutilización de componentes, la interoperabilidad y la comunicación mediante interfaces bien definidas, tienen su origen en SOA. No obstante, los microservicios suelen ser más pequeños y están diseñados para desarrollarse, desplegarse y escalar de manera independiente, características especialmente adecuadas para los entornos de computación en la nube.
La arquitectura orientada a servicios marcó un cambio importante en la forma de desarrollar software al promover la creación de componentes reutilizables, interoperables e independientes. Sus principios permitieron integrar sistemas complejos, reducir costos de mantenimiento y aumentar la capacidad de adaptación de las organizaciones frente a nuevos desafíos tecnológicos y de negocio. Hoy muchas aplicaciones utilizan arquitecturas de microservicios, pero los fundamentos de SOA continúan vigentes.
Referencias:
- What Is SOA (Service-Oriented Architecture)?
- What is Service-Oriented Architecture (SOA)? | IBM
- SOA vs. Microservices: What’s the Difference? | IBM
- ¿Qué es AOS? – Explicación sobre la arquitectura orientada a servicios – AWS
- SOA frente a microservicios: diferencia entre estilos arquitectónicos – AWS
- Iaas, Paas, Saas: What’s the difference? | IBM