viernes, 14 de agosto de 2015

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


Siguiendo con esta entrada, les voy a compartir una experiencia de hace algún tiempo como consultor, donde se me presentó un caso que requería un gran desafío para la época en atributos de calidad. El requisito estaba relacionado con desempeño y exigía un manejo de 140 mil transacciones en un día (con un pico de unas pocas horas).

Dicha organización había experimentado con un famoso Appliance que prometía el procesamiento de un alto volumen transaccional. Sin embargo, con el transcurrir de un tiempo luego de la implementación de los respectivos flujos de mediación se llegó a la siguiente conclusión: es más útil como tranca para que la puerta del centro de cómputo no se abra; suena mal, pero fue así y regresaron a la estrategia de servidores de SOCKETS escalables en su infraestructura.

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).