La arquitectura de servicios es un enfoque de diseño de software que resuelve un problema con una serie de servicios autónomos.

Analogía

Una analogía razonable para la arquitectura de servicios es una organización como un banco. El banco divide el trabajo en una variedad de servicios, como servicio al cliente, servicios de TI y servicios de gestión de recursos humanos. Cada servicio es independiente y se puede implementar en diferentes oficinas. A los clientes de cada servicio se les ofrece un contrato que establece lo que se puede esperar del servicio. Por ejemplo, la gestión de recursos humanos puede ayudar a un equipo a contratar personal nuevo con un formulario que el equipo completa para iniciar el proceso. La estructura de servicio de la empresa desglosa el complejo problema de operar un banco en pequeños trozos de funcionalidad de administración.

Servicios

Los servicios son unidades de software que realizar una función. Se utilizan para dividir problemas complejos en una serie de problemas más simples. Los servicios también están diseñados para ser implementados por separado. Esta es una gran ventaja, ya que le permite construir sistemas altamente escalables y resilientes.

Resiliencia

Resilience es un término para el software que es confiable en condiciones del mundo real que incluye varias tensiones y fracasos. La arquitectura de servicios es una técnica útil para construir sistemas que continúan funcionando cuando las cosas fallan. Esto se hace mediante la arquitectura de los servicios para que sean autónomos de modo que no dependan entre sí. Los servicios se pueden implementar en la infraestructura de la nube y escalar hacia arriba y hacia abajo según sea necesario. Cuando una instancia falla, los servicios son lo suficientemente inteligentes como para detectar esto y automáticamente busque una instancia que funcione.

Servicios frente a componentes

Los servicios y componentes son dos formas diferentes de dividir el trabajo en partes manejables y reutilizables. La diferencia es que los servicios se pueden implementar por sí mismos. Los componentes se implementan con otra cosa y, por lo tanto, no son autónomos. Los servicios se pueden construir a partir de componentes. Asimismo, los componentes pueden utilizar servicios.

Arquitectura orientada a servicios (SOA)

La arquitectura orientada a servicios fue un término temprano para la arquitectura de servicios que fue adoptado y comercializado por muchos grandes proveedores de TI que lo utilizaron para vender plataformas SOA y middleware. Esta fue una gran moda de tecnología de la información alrededor de 2005 que vio muchas implementaciones de arriba hacia abajo que implicaron comprar un montón de software y luego rediseñar los sistemas existentes para encajar en un paradigma SOA. Gran parte de esta actividad perdió por completo el punto de SOA y los fracasos de los proyectos eran comunes. La confusión llovió mientras los expertos en TI promovían o criticaban SOA, a menudo haciendo que las cosas parecieran lo más complejas posibles.

Microservicios

Todo el pensamiento grande y las tonterías que rodeó a SOA en la cima de su popularidad no impidió que los arquitectos expertos usaran sus ideas centrales de manera efectiva y liviana que produjera sistemas y aplicaciones confiables, escalables, manejables y rentables. Esto se convirtió en una nueva cultura de diseño de software conocida como microservicios que se organiza en torno a un conjunto de principios para el diseño de servicios.

Ejemplo

Una empresa de telecomunicaciones diseña un sistema de facturación como una serie de servicios desplegables por separado. Cada servicio se considera un producto independiente que puede ser desarrollado, mantenido y gestionado por diferentes personas. Los servicios se implementan en la nube y se acoplan de manera flexible. Cuando falla una instancia de servicio, los otros servicios cambian automáticamente a una instancia que todavía está funcionando. Aunque el problema de la facturación de las telecomunicaciones es extremadamente complejo, ningún servicio único en la arquitectura es tan complejo que cada uno sea relativamente barato de desarrollar y administrar. Los servicios son esencialmente autoorganizados. Cada uno publica una API para los demás servicios. Cada uno sabe lo que necesita de los otros servicios y es lo suficientemente inteligente como para enrutar instancias fallidas para encontrar servicios que respondan. En otras palabras, la arquitectura no tiene controlador central o middleware.

Descripción general: arquitectura de servicio
Tipo
Definición	Un enfoque de diseño de software que resuelve un problema con una serie de servicios autónomos.
Conceptos relacionados