martes, 28 de julio de 2015

En defensa del ESB - SOA con microservicios (Parte I)

Esta entrada la inicie a mediados del 2013 pero nunca la abordé; recuerdo que nació de un comentario en donde se hablaba algo de los microservicios o de un estilo arquitectónico REST como una solución tipo bala de plata. Mis ocupaciones (me había ido al lado oscuro de la fuerza) me enredaron y se quedó ahí, pero bueno, nunca es tarde para volver.

Estas entradas las separaré en dos partes:


Gracias de ante mano por sus comentarios o aportes.

Hablando un poco del viejo patrón ESB

En  muchas iniciativas se discute acerca de la aplicabilidad de un ESB (Enterprise Service Bus) y en que casos se debe usar, en otros se habla de éste como una mala practica, en otros se presenta como la bala de plata que resuelve todos los problemas, en general se dan como aceptados los conceptos de un ESB, pero, ¿se entiende qué es un ESB? ¿los microservicios son la bala de plata esperada y todo debe ser implementado así? ¿SOA está muerto?

Durante mucho tiempo se ha explicado por múltiples fabricantes que un ESB es una herramienta, un producto o una combinación de estos. Ésto, en realidad no es cierto, porque las herramientas son habilitadores, medios, pero no son el patrón en si mismo y en muchos casos se les denomina ESBSystem.
En realidad esto se ha presentado por un discurso comercial que sea fácil de vender, porque si se habla de un ESB como un patrón, quizás exista la necesidad de explicar de parte de un equipo comercial acartonado (o bastante maquillado) la estrategia de su uso; esto evidentemente no es viable aún más cuando el comercial lo único que hace es aprenderse un discurso específico del fabricante (recuerdo la guerra entre equipos comerciales y de arquitectura en un reconocido fabricante por esto).



La anterior figura muestra a un "ESB"; esto en realidad es una imagen clásica de venta en la cual se aprecia una plataforma o herramienta que se convierte en un cuello de botella entre aplicaciones y por supuesto entre consumidores (requesters) y proveedores. Ante esta imagen de "arquitectura" de un ESB, muchas organizaciones han diseñado soluciones orientadas a servicios creyendo en que han implementado su enfoque con todos sus principios (basta con comprar la herramienta), pero en realidad lo que han construido es aplicaciones monolíticas en una plataforma común con las siguientes características:

  • Cuello de botella: si se cae un servicio o la plataforma se cae por completo el "ESB". Todos los mensajes pasan por dicha plataforma.
  • Escalabilidad: es claro que escalar una única plataforma con este modelo se realiza instalandola N veces junto a todos los componentes de software construidos a través de modelos horizontales o verticales; aplicaciones monolíticas.
  • Gestión de SLAs entre consumidores y entre proveedores: esto rara vez se implementa ocasionando que los hilos de los procesos que se ejecuten creen contenciones bien sea entre los consumidores o con el proveedor del servicio, como puede ser una base de datos. Si algo falla todo se cae o se inicia un proceso de degradación de nuestro famoso "ESB".
  • Soporte de una única plataforma para albergar múltiples servicios: recuerdo charlas interesantes sobre esto, en donde se vendía la idea de que para eso es el "bus"; es simple, es para soportar todos los servicios que se tengan. Esto en realidad no es tan cierto, porque cómo se podría administrar requisitos no funcionales de desempeño, uso de recurso de cómputo en general si todos usan la misma plataforma y en donde seguramente no faltará el desarrollador que implemente componentes con un bajo desempeño, o el reuso de servicios de parte de otros consumidores sin un control de transacciones por segundo, etc.
  • El ESB como un todo incluyendo stateless y stateful: esto lo he visto cientos de veces en plataformas IBM, Oracle, TIBCO, Server JEE, IIS, etc., entre otras, en donde se implementan orquestaciones en el "ESB" porque  para eso es. Esto agrava el problema teniendo en cuenta que a parte de ser una plataforma que alberga múltiples servicios convirtiéndose en un cuello de botella debe procesar estados conversacionales de larga duración así no tengan persistencia (Short-running) , olvidándose que los servicios por definición son stateless.
  • Implementación de "ESBSystem" sobre un contenedor JEE o un IIS: esto por si solo se enfoca en un modelo monolítico de cuello de botella en donde los componentes se ejecutan sobre una aplicación que a su vez corren sobre un servidor de aplicaciones y una máquina virtual. En realidad se ve un todo, y poca gestión de atributos de calidad y se duda de la separación de contenedores por la complejidad de su administración o por el eterno problema de licenciamiento; aquí, un servicio no es un proceso autónomo independiente o un grupo de servicios separado por dominio o un modelo de inventario lógico definido a conveniencia por cohesión o por principios SOLID o de empaquetamiento.
  • Servicios Web, WSDLs: esto quizás es lo más común y está relacionado con la difusión de que los servicios son iguales a servicios Web; en realidad es una idea que se quedó como cierta pero no lo es. Los servicios son abstracciones que exponen funcionalidades cohesivas y desacopladas a consumidores a través de un modelo de dominio neutral; es un concepto lógico simplemente que permite alinear áreas de negocio con capacidades técnicas, y que pueden implementarse en tramas sobre HTTP, CORBA, XML con sockets o a través de simples mensajes JSON sobre el protocolo que se escoja. Esto quiere decir que los servicios no son componentes de software ejecutables sino representaciones funcionales que pueden ser implementadas en la tecnología que se prefiera o con el formato de mensajería que cumpla por ejemplo con protocolos canónicos o esquemas canónicos.
  • ESB y componentes para la implementación de SOA: esto se basa en la estrategia que han tenido los fabricantes que venden licencias asignando responsabilidades específicas a productos de software para implementar una arquitectura orientada a servicios. Esto en realidad es una buena estrategia comercial, pero no una definición de arquitectura como tal, porque sería tan simple como comprar las cajas y listo; recuerdo a muchas organizaciones con un montón de cajas guardadas en anaqueles esperando ser usadas para algún propósito (es primero la gallina que el huevo; la herramienta sobre la solución de arquitectura) sin tener en cuenta modelos operacionales, proyectos de software o requisitos funcionales y no funcionales básicos.
En realidad la lista es bien larga, pero creo que la idea se entiende. Ahora bien, creo que lo que he tratado de mostrar desde mi punto de vista es en realidad la putrefacción del concepto de SOA, ESB, entre otros.


Ahora, si dijéramos que SOA es un modelo de arquitectura que se enfoca en cuatro frentes de trabajo: negocio, arquitectura, desarrollo y operación, podríamos encontrarnos con lo siguiente:

  • SOA desde el negocio: alguien de negocio ve por lo general a SOA como un modelo que permite a los procesos de negocio consumir servicios que son provistos por el área de TI; esto se conoce como alineación.
  • SOA desde un enfoque de arquitectura: un estilo de arquitectura que requiere proveedores de servicios, consumidores y mecanismos de descripción para descubrir y ejecutar las funcionalidades provistas. Se habla de componentes de servicio con bajo acoplamiento, bien definidos, interoperables y flexibles para el reuso, sin olvidar a los principios de la orientación a servicios. Además, se incluyen modelos de gobierno y de control de aspectos no funcionales.
  • SOA desde un modelo de desarrollo: desde este punto de vista se habla de tecnologías a utilizarse, protocolos, mensajes, formatos entre otros a través de la estandarización en una Organización.
  • SOA desde un modelo de operación: una arquitectura que permite a áreas de operaciones implementar mecanismos de monitoreo APM  para determinar el uso del recurso de cómputo de cada componente de servicio implementado por cada uno de los dominios o modelo de inventario para establecer políticas de fondeo ($) o de control de atributos de calidad.
Ahora bien, ¿qué es un ESB?. Les propongo algunas características claves que he recopilado:
  • El ESB como patrón lógico, no es una herramienta (s). Es el diseño de una solución a la medida y con las capacidades a alcanzar. No olvidemos que dentro de los principios de SOA está la diversificación de vendedores  y tecnologías y arquitectura agnóstica.
  • No es un cuello de botella en una infraestructura común que se instala y se configura una sola vez. Si algo se cae colapsa una Organización como único punto de fallo.
  • Es una solución orientada a aspectos  de conectividad que proporciona capacidades en runtime. Quiere esto decir que permite re-configuración dinámica de aspectos no funcionales.
  • En una Organización existen múltiples ESBs separados por unidades de negocio o por responsabilidades transaccionales. Pueden ser autónomos y sostenibles en un modelo de fondeo ($) que habilite capacidades de negocio.
  • Se podría implementar SOA con micro-servicios; Umhhhhh, si. De hecho, muchas arquitecturas que conozco implementan aplicaciones autónomas a través de procesos separados sobre un sistema operativo que levantan múltiples hebras (threads). En otros casos la separación se implementa por dominios o modelos de inventarios para facilitar la operación y administración de grupos de servicios desplegados teniendo en cuenta cohesión y principios de empaquetamiento
  • Soporta múltiples estilos de comunicación. No siempre es posible manejar peticiones sincrónicas y en procesos de negocio complejos se requieren muchas veces modelos asíncronos.
  • Una arquitectura de referencia SOA puede soportar múltiples protocolos de exposición. Ejemplo: HTTP, SMS, sockets TCP, SOAP, etc. Claro está que la interoperabilidad debiera ser un elemento clave, pero resulta que no siempre es posible hablar en estándares y en organizaciones complejas todavía existen Mainframes, o desde consumidores limitados incluso HTTP utilizando tramas son mensajes muy grandes, así que no todo es Web, ni síncrono, y sobre esto no hay balas de plata.
  • Se fundamenta en el  manejo de eventos. De cara a los consumidores el estilo de comunicación puede variar, pero entre componentes se pueden utilizar eventos.
  • Soporta invocaciones stateless. ¿Será que se soporta procesamiento batch para millones de registros al mismo tiempo?
Desde los lineamientos del OpenGroup SOA RA se muestra lo que es un ESB, como una asignación de responsabilidades lógico y no como una plataforma o una herramienta del tipo ESBSystem.

  

En la perspectiva de SOAPatterns el ESB se describe a este como una capa de intermediación.

Para cerrar esta entrada, lo que pretendo mostrar es que no todas las soluciones son Web (no todo es front-end) y que una arquitectura orientada a servicios es más que los servicios Web, que un ESB es un patrón y no una herramienta, que no todo puede ser autónomo, no todo es sincrónico, no todo es HTTP, no hay balas de plata y para esto cito este artículo de microservicios de Martin Fowler, y si fuese así que fácil sería todo.

De los microservicios podríamos decir que es la definición de una SOA bien hecha, bien diseñada. Pero, no siempre es posible implementarlos porque pueden existir restricciones operacionales, políticas o de presupuesto para soportar múltiples contenedores que garanticen la autonomía de cada servicio.

En la siguiente entrada pretendo describir un poco como sería la definición de una SOA con elementos de microservicios que garanticen autonomía, escalamientos, mantenimiento, fiabilidad, despliegue continuo, eliminación en lo posible de sistemas monolíticos a través de dominios o inventarios o para algunos casos claves la construcción literal de servicios autónomos estructurados para que sean totalmente independientes para garantizar un desempeño y fiabilidad consecuente con un modelo de negocio.

Ver parte II

4 comentarios:

  1. Muchas gracias por estos aportes. De acuerdo con la descomposición que causan los afanes comerciales, inculcando definiciones erróneas y al final perjudicando al cliente. Ahora con más entusiasmo para masticar todo eso de micro-servicios.

    ResponderEliminar