Arquitectura basada en servicios y arquitectura orientada a servicios

Entre el monolito y los microservicios

Gran parte de la conversación del sector plantea una elección entre un monolito y muchos microservicios. En la práctica, una gran parte de los sistemas reales está en un punto intermedio: un puñado de servicios desplegados por separado, cada uno de los cuales cubre toda un área de negocio, que a menudo siguen compartiendo una base de datos. Mark Richards y Neal Ford llamaron a este estilo arquitectura basada en servicios en Fundamentals of Software Architecture y sostienen que es uno de los estilos distribuidos más pragmáticos que existen. Esta sección lo describe, lo contrasta con la arquitectura orientada a servicios (SOA), más antigua y con la que a menudo se confunde, y muestra en qué se diferencian los microservicios de ambas.

Arquitectura basada en servicios: la topología

Un sistema basado en servicios tiene tres partes. Una o varias interfaces de usuario llaman a un conjunto de servicios de dominio desplegados por separado, cada uno de los cuales cubre un área de negocio grande y coherente, como los pedidos o los pagos. Richards y Ford observan que estos sistemas suelen tener entre 4 y 12 servicios de dominio, unos 7 de media. Los servicios suelen compartir una base de datos, y una capa de API opcional (un proxy inverso o un gateway) puede situarse entre las interfaces de usuario y los servicios para encargarse del enrutamiento, la autenticación y la limitación de tasa.

Cada servicio de dominio es de grano grueso: contiene todo lo necesario para su dominio, desde la API hasta la lógica de negocio y el acceso a los datos, y por dentro está estructurado como un pequeño monolito, a menudo en capas o en módulos (Capítulo 5). Un servicio se despliega normalmente como unas pocas instancias detrás de un balanceador de carga.

De ello se derivan dos consecuencias. Primera, la mayoría de los flujos de trabajo de negocio se ejecutan por completo dentro de un servicio, de modo que pueden usar una transacción local corriente de base de datos con garantías ACID completas (Capítulo 0). Segunda, los servicios de dominio rara vez necesitan llamarse entre sí: una solicitud de la interfaz de usuario va al único servicio que es propietario del dominio. Esto mantiene cortas las cadenas síncronas, lo que importa por las razones calculadas en la Sección 6.1.

La base de datos compartida y cómo domarla

Compartir una base de datos es lo que hace que la arquitectura basada en servicios sea barata y sencilla: no hay sincronización de datos entre servicios, no hay consistencia eventual y los informes se hacen con SQL corriente. También es su principal debilidad. Si todos los servicios leen y escriben las mismas tablas, un cambio en las columnas de una tabla puede romper varios servicios, que entonces deben probarse y volver a desplegarse juntos. Se aplica la definición del Capítulo 5: los servicios que comparten una base de datos quedan unidos en un solo cuanto de arquitectura, de modo que comparten un único nivel de disponibilidad y un único ritmo de lanzamiento del esquema.

Los profesionales usan tres técnicas para reducir el acoplamiento. La primera es el particionado lógico: dar a cada servicio su propio esquema (o conjunto de tablas) y prohibirle tocar el de los demás, algo que se hace cumplir con permisos de la base de datos además de por convención. La segunda es mantener las clases de entidad de la base de datos compartida en pequeñas bibliotecas por dominio en lugar de en una gran biblioteca compartida, de modo que un cambio en las tablas de restaurantes solo afecte a los servicios que las usan. La tercera es dar a un servicio su propia base de datos cuando hay una razón de peso, como el alcance de seguridad, un patrón de carga muy distinto o un tipo distinto de almacén de datos. Los equipos que las aplican con constancia descubren que un paso posterior a bases de datos separadas, si alguna vez llega a ser necesario, es mucho más fácil.

La arquitectura orientada a servicios clásica

La arquitectura orientada a servicios es más antigua y más amplia. El término entró en el sector a través de un informe de Gartner de 1996 de Roy Schulte y Yefim Natis, y desde principios de la década de 2000 se convirtió en el modelo dominante de integración empresarial. Su idea central era sensata: exponer las capacidades de negocio como servicios con contratos explícitos y neutrales respecto a la tecnología, de modo que las aplicaciones de una gran organización puedan montarse a partir de ellos en lugar de reconstruirse o integrarse punto a punto.

Sin embargo, lo que la mayoría de las empresas construyó en realidad fue lo que Richards y Ford llaman SOA dirigida por la orquestación. Los servicios se organizaban en capas técnicas: servicios de negocio que describían procesos (hacer un pedido, abrir una cuenta), servicios empresariales compartidos que ofrecían capacidades reutilizables (cliente, precios, factura), y servicios de aplicación y de infraestructura que envolvían los sistemas existentes y las inquietudes técnicas. En el centro estaba un bus de servicios empresarial (ESB): un middleware que enrutaba los mensajes, los transformaba entre formatos, mediaba entre protocolos y, mediante un motor de orquestación, ejecutaba los propios procesos de negocio.

Dos ideas más completaban el cuadro. Un modelo de datos canónico definía una única representación de cada entidad de negocio para toda la empresa (un Customer, un Order), y cada mensaje se traducía a ella y desde ella en el bus. Y una familia de estándares de servicios web, normalmente llamada WS-*, definía cómo los servicios se describían y se llamaban entre sí: SOAP para los mensajes, WSDL para las descripciones de interfaces, UDDI para los registros, WS-Security, WS-ReliableMessaging y WS-AtomicTransaction para las cualidades, y WS-BPEL (versión 2.0 aprobada por OASIS en 2007) para las definiciones de procesos ejecutables.

Por qué la SOA clásica cayó en desuso

A finales de la década de 2000, muchos programas de SOA habían decepcionado. Anne Thomas Manes, de Burton Group, captó el ambiente en una entrada muy leída de enero de 2009 titulada SOA is Dead; Long Live Services: la etiqueta se había vuelto tóxica, pero la idea de los servicios sobrevivió. Merece la pena conocer las razones, porque cada una es una trampa en la que las arquitecturas modernas pueden volver a caer.

La reutilización creó acoplamiento. Un servicio empresarial compartido de Customer usado por cuarenta aplicaciones no podía cambiar sin el acuerdo de cuarenta consumidores; la reutilización, el objetivo principal, convirtió cada cambio en una negociación. El bus se convirtió en el cuello de botella. Poner la lógica de enrutamiento, de transformación y de procesos en un ESB central, normalmente propiedad de un único equipo de integración, significaba que casi cualquier cambio de negocio necesitaba a ese equipo, y el bus se convirtió en un único punto de fallo y de retraso. El modelo canónico era demasiado grande. Una única definición de Customer que satisfaga a ventas, facturación, soporte y logística o es enorme o es errónea para la mayoría de ellos; los contextos delimitados del Capítulo 5 explican por qué un término significa legítimamente cosas distintas en distintas partes de un negocio. Los estándares eran pesados. Las especificaciones WS-* eran complejas, las herramientas eran caras y las transacciones distribuidas entre servicios resultaron frágiles. El particionamiento técnico significaba que una funcionalidad sencilla atravesaba varias capas de servicios propiedad de grupos distintos.

Las lecciones duraderas son aquellas sobre las que se construyeron los microservicios: contratos de servicio explícitos, servicios cuyos propietarios son las personas que los construyen, la lógica en los servicios y no en el middleware, y los datos propiedad de un único servicio en lugar de compartidos por toda la empresa.

En qué se diferencian los microservicios

Los microservicios, que se tratan a fondo en la sección siguiente, conservan la idea de la SOA de servicios con contratos explícitos e invierten la mayoría de sus decisiones de implementación. James Lewis y Martin Fowler resumieron una de esas inversiones como smart endpoints and dumb pipes (extremos inteligentes y tuberías tontas): la red solo transporta mensajes, y toda la lógica vive en los servicios. Los servicios se organizan en torno a capacidades de negocio en lugar de capas técnicas, la reutilización queda deliberadamente por detrás de la independencia, cada servicio es propietario de sus datos y la gobernanza está descentralizada.

Comparados con la arquitectura basada en servicios, los microservicios son de grano más fino, mucho más numerosos e insisten en tener datos separados. Eso compra más independencia, un escalado más selectivo y más aislamiento de fallos, y cuesta mucho más en operación, consistencia y coordinación. La arquitectura basada en servicios puede verse como el punto del espectro en el que llega la mayor parte de los beneficios de despliegue y de equipos por una fracción del costo.

Cuándo la arquitectura basada en servicios es el término medio pragmático

Elígela cuando el sistema tenga unos pocos dominios de negocio claros, cuando entre dos y quizá ocho equipos necesiten lanzar de forma independiente, cuando la mayoría de los flujos de trabajo se queden de forma natural dentro de un dominio y cuando la consistencia fuerte dentro de un dominio sea valiosa. También es un paso de migración excelente para salir de un monolito: dividir un monolito bien modularizado en un puñado de servicios de dominio es mucho menos arriesgado que saltar a cincuenta microservicios, y a menudo el resultado es lo bastante bueno como para quedarse ahí.

Evítala, o planifica ir más allá, cuando partes de un dominio necesiten una escalabilidad o una disponibilidad muy distintas (pertenecen a cuantos separados), cuando decenas de equipos necesiten autonomía, cuando la base de datos compartida se haya convertido en el cuello de botella de las escrituras, o cuando los servicios de dominio se llamen constantemente entre sí para completar solicitudes corrientes, lo que es señal de que los límites están mal.