¿Cuál es el futuro de Enterprise Service Bus (ESB)?

Me encanta esta pregunta, ya que está muy cerca de mi corazón.

El ESB fue una gran idea Todavía tengo que ver uno con el que todos estuvieran perfectamente contentos. Tienden a ser mal utilizados, o abusados. Muchos han descubierto que se caen en ciertos casos de uso a gran escala y solo trabajan con barandas que los protegen del trabajo excesivo.

Mi teoría es que no nos hemos dado cuenta de lo que realmente queremos que sea un ESB y cómo usarlo. Creo que la nube y algunas de las nuevas tecnologías de Big Data nos darán la oportunidad de redefinir qué es un ESB y algunos de los patrones de diseño sobre cómo hacer las cosas. Tal vez estemos bien con solo llamarlo ESB 2.0. Algunas personas tendrán un mal sabor en la boca que necesitarán un nuevo nombre.

No estoy seguro de cómo lanzar lo que creo que queremos sin enviar a algunas personas a la histeria, pero estoy tratando de resolver esto ahora mismo.

El nombre que estoy usando es Gobernado de Gestión de Eventos. Para mí esto también podría ser ESB 2.0.

Algunas de las cosas que quiero:

  • Una lista enlazada distribuida.
  • Sistema de mensajería.
  • Un almacén de datos a largo plazo donde:
    • Los artículos son inmutables.
    • Los artículos solo avanzan en el tiempo
    • Respuestas consistentes a las consultas basadas en el tiempo
    • Las llaves de los objetos siempre aumentan.
    • Aka – Origen de los datos.
  • Tolerante a los fallos, fácil de agrupar
  • Gobernancia
    • Derechos
    • Orquestación
    • Cheque de salud
    • Revisión de cuentas
  • Fácil acceso a los datos
    • Protocolo simple
    • Reproducción y Auditoría
  • Agnóstico de datos
  • Diseño modular
  • Bajo acoplamiento
  • Cliente paralelo distribuido
  • Ajustable por el costo total de propiedad
    • Diferentes costos de SLA cantidades significativamente diferentes
  • Opciones de integración de clientes simples
    • Suscripción automática basada en la actividad del sistema de archivos.
    • REST / Curl etc
    • Actividad portuaria a nivel de kernel.
    • GUI del cliente

Podría seguir con más elementos y dar detalles sobre cada uno si pensara que valía la pena leerlo. He participado en el diseño e implementación de lo anterior durante años y estoy listo para volver a intentarlo. Me siento muy cerca de entregar lo anterior.

No creo que Enterprise Service Bus vaya a ninguna parte pronto. Aunque a veces se piensa que ESB es una herramienta para conectar sistemas obsoletos y heredados (por definición, los locales), se desarrolló mucho antes de que el término “ESB” realmente llegara, y se usaba simplemente para conectar sistemas, punto. Es solo que apareció cuando aún no había una nube en el horizonte.

Luego vino el iPaaS para reemplazar al ESB en el área en la que era demasiado dinosaurio, para SaaS. Más aún, iPaaS evolucionó rápidamente para que las aplicaciones locales también estuvieran conectadas. En este sentido, puede parecer que el concepto de Enterprise Service Bus está desactualizado .

Sin embargo, el tiempo es conocido por no detenerse , por lo que ahora tenemos ESB ligeros que admiten API, así como plataformas de integración que se conectan a sistemas heredados. Por lo tanto, creo que los ESB clásicos simplemente serán reemplazados por sus versiones más ligeras con las posibilidades de integración de aplicaciones SaaS, como la que proporciona WSO2. No creo que sea reemplazado completamente por otras herramientas de integración más modernas como iPaaS, y eso es por varias razones. En este sentido, el futuro de ESB se ve bastante bien 🙂

Sin embargo, creo que, en un tiempo relativamente cercano, veremos más de “colaboración” entre ESB y otras herramientas de integración, en particular iPaaS, como las que proporciona Mulesoft, Snaplogic o elastic.io. El motivo es que hay algunas cosas en las que iPaaS es simplemente mejor que ESB, especialmente cuando se habla de multitenencia , integración B2B y soporte de proyectos de integración relacionados con IoT o chatbots , para los cuales se encuentran alto rendimiento junto con baja latencia. llave. De hecho, estoy realmente ansioso por ver tales colaboraciones en acción, pero aún está marcado por un cambio bastante lento en las mentes y la cultura.

( Descargo de responsabilidad: trabajo con elastic.io | Integration Platform como un servicio y, por lo tanto, no tengo ningún interés personal con respecto a las empresas mencionadas anteriormente)

Enterprise Service Bus fue la columna vertebral de la integración corporativa y la mensajería. Dado que el sector de TI está creciendo a pasos agigantados en términos de movilidad empresarial, también debe hacerlo el concepto para cumplir con los crecientes requisitos.

En el futuro, la forma más evolucionada de ESB se hará cargo, también conocida como microservicios. Hace años, cuando los vendedores de software ofrecían Enterprise Application Integration (EAI), el recurso común que utilizaban era ESB. Actuó como un agente de distribución con el middleware como su hub central. Hoy en día, los proveedores a los que les resulta difícil vender un middleware de integración central, por la única razón de que no es flexible para distribuir, por ejemplo, la compartición y la distribución a través de la computación en la nube.

Con una gran cantidad de proveedores que venden una plataforma de entrega de servicios, el futuro podría dar más impulso a la plataforma de microservicios. Pero, todavía hay un área gris cuando se trata de resolver problemas de integración con el uso de patrones de integración empresarial.

Estoy de acuerdo con el sentimiento a continuación, pero más que eso, creo que habrá oportunidades en torno a la abstracción y la separación de diferentes piezas del ESB.

Ya lo hemos visto con el auge del Big Data en general. Con la excepción de las organizaciones que se basan en Big Data como su principal medio para generar ingresos, la agregación y el procesamiento de esos datos se han extraído del núcleo de datos corporativos y se han exportado a la nube (ya sea pública o privada, dependiendo de la nivel de datos propietarios o privados dentro de ella).

Dado que el siguiente paso lógico para la mayoría de las organizaciones es la reintegración de esos datos en bases de datos estructuradas más tradicionalmente, el procesamiento posterior (o incluso la reintegración en grandes clústeres de Oracle o derivados de código abierto como MySQL / MariaDB) puede ser una oportunidad para la mentalidad más tradicional de “propiedad y hospedaje en estas cuatro paredes” para ser desafiada. Si luego se puede abstraer el procesamiento, entonces todo lo que queda es la salida y el consumo de ambos procesos. Será interesante cómo comenzamos a tratar de forma rutinaria con los datos que pueden fácilmente llegar a los cientos de terabytes.

Un bus de servicio empresarial (ESB) es una arquitectura de software para middleware que proporciona servicios fundamentales para arquitecturas más complejas. Por ejemplo, un ESB incorpora las características necesarias para implementar una arquitectura orientada a servicios (SOA). En un sentido general, se puede considerar a un ESB como un mecanismo que gestiona el acceso a las aplicaciones y servicios (especialmente las versiones heredadas) para presentar una interfaz única, simple y consistente para los usuarios finales a través del lado del cliente basado en web o formularios. frente termina.

Conozca más en: Cloud Computing Sales – Udemy

Escuché a un par de muchachos que ya hablan sobre cómo la nube impactará la centralización que el ESB estaba impulsando, uno de los neologismos es “Microservicios” que significa “exactamente lo opuesto a un ESB”.

En cualquier caso, el principal problema de ESB no es la descentralización de los servicios, sino la oposición dentro de las partes heredadas de la compañía para adoptar tecnologías realmente estándar.

ESB triunfará donde las personas tengan el poder y el ingenio para evitar que el software cerrado heredado llene todas las integraciones con estructuras de datos propietarias.

Simplemente se tratará de manejar big data con mayor procesamiento y mediación. El rol principal de ESB no diferiría del escenario actual, pero será una implementación más basada en reglas. Si está buscando más para saber cómo funciona ESB con big data, debe probar el Bus de Servicio Empresarial WSO2 – Solo ESB de Código Abierto 100%. Y cómo utilizar Big Data con él. Plataforma de análisis de Big Data WSO2

Hay demasiadas herramientas modernas de IPAAS que ahora reemplazan al ESB. Mira todos los cambios y las pilas modernas.