Actualmente llevo varios años trabajando con sistemas distribuidos y arquitecturas orientadas a eventos, desde el malentendido SOA (o su versión refurbished como son los Microservices), hasta Event Sourcing (indirectamente enlazado con CQRS).

Muchos de los conceptos vinculados con eventos como inmutabilidad, perpetuidad, idempotencia… son igualmente validos para realizar stream processing o flujo continuo de eventos. Si a esto le sumamos el proceso por lotes o batch processing, entramos en el terreno de lo que muchos llaman Big Data.

Big Data

Cuando pensamos en big data lo primero que nos viene a la cabeza es Hadoop para ejecutar procesos por lotes. Tenemos que pensar que Hadoop ofrece una gran capacidad para procesar una cantidad indecente de datos, pero a costa de una alta latencia en la respuesta. Aunque esta latencia puede ser de sobras aceptable para muchos casos de uso, no lo es para otros que tienen la necesidad de procesar una gran cantidad de datos en tiempo (casi) real.

Ahí es donde entra en juego lo que muchos llaman lambda architecture (Nathan Marz, ex-twitter).

Ver Más

El modelo de actores se caracteriza por establecer un modelo de computación basado en el Reactive Manifesto que nos permite construir:

• Sistemas altamente concurrentes
• Sistemas escalables tanto horizontalmente como verticalmente
• Sistemas fiables y tolerantes a errores

Para empezar vamos a ver como se define un actor ya que tenemos 3 formas distintas dependiendo de nuestras necesidades. Los actores en Akka.net hacen un uso extensivo de pattern matching para seleccionar cómo se van a gestionar los mensajes dependiendo de su tipo o valor.

Ver Más

El próximo viernes 27 Febrero voy a estar en la dotNetSpain Conference hablando sobre Complex Event Processing, Inmutabilidad y Proyecciones con EventStore.

Aquí os dejo el detalle de la charla:

En esta sesión veremos cómo tomar decisiones a partir del procesamiento y correlación de eventos, la importancia de la inmutabilidad y aplicar proyecciones de datos desde .NET.

Almacenando nuestros datos como una serie de eventos inmutables en Event Store veremos cómo aplicar proyecciones capaces de reaccionar a eventos, procesarlos mediante CEP (Complex Event Processing) y generar nuevos eventos cuando ocurran combinaciones de ellos.

Veremos también como aplicar Temporal queries, algo que tiende a ser complejo en SQL por el número de subconsultas, y finalmente como generar índices de eventos. Todo esto desde las diferentes APIs de las que disponemos en .NET

Nos vemos ahí!!

Mañana voy a estar con SecondNug dando una charla de arquitectura distribuida con SOA, DDD y CQRS con NServiceBus.

En esta charla hablaremos del diseño estratégico con DDD su relación con SOA y veremos un ejemplo de como modelar lógica de dominio mediante las Sagas en NServiceBus.

A continuación podéis ver el enlace de registro:

Webcast

El próximo 26 de Noviembre (Barcelona) y 10 de Diciembre (Madrid) voy a realizar un máster de 4 días sobre arquitectura distribuida, en el que se van a tratar temas como:

• Domain Driven Design / SOA
• CQRS
• Mensajería con NServiceBus.

Es un curso creado por Udi Dahan y que se va a realizar por primera vez en España después de varios años de éxito en Londres y USA.

Para ver temario, fechas y precios, podéis consultar la siguiente web: http://masterad.techdencias.net

Colaboran:

Aparte de este blog que continuaré actualizando, he creado otro en inglés que podéis encontrar en:

http://www.serrate.net

Donde hablaré de temas como: SOA, DDD, NoSQL, BigData y todo lo que vaya descubriendo y pueda ser de interés.

Nos leemos!!

El próximo jueves 26 de Abril a las 16h se realizará un evento en Madrid sobre Sistemas distribuidos con NServiceBus.

El enlace de registro para el evento en Madrid es: http://nservicebusiasamad.eventbrite.com

El jueves 3 de Mayo a las 16h se repetirá el evento en Barcelona añadiendo un track sobre arquitectura SOA con RabbitMQ y WebSockets de la mano de Braulio Megías.

El enlace de registro para el evento en Barcelona es: http://messagingiasabcn.eventbrite.com

Descripción del evento

En este evento presentaremos las particularidades de los Enterprise Service Bus (ESB) en comparación con las arquitecturas tipo Broker. En concreto, nos centraremos en las características de NServiceBus y cómo puede ayudarnos a diseñar sistemas distribuidos SOA de forma robusta, fiable y escalable.

Finalmente veremos de forma teórica y práctica los patrones de mensajería que incluye NServiceBus: Store & Forward, Request/Reply y Publish/Subscribe.

En las últimas entradas estamos repasando las novedades de NServiceBus 3.0 que ya está en la Release Candidate 2. En esta entrada veremos una funcionalidad que ya existía en versiones anteriores pero que se ha rehecho completamente.

Distributor nos permite balancear la carga entre varios nodos a partir de un nodo maestro. La configuración del nodo maestro es muy sencilla a través de los profiles de NServiceBus, simplemente debemos añadir el argumento NServiceBus.Master en el Host. Para asegurar la alta disponibilidad del nodo maestro es recomendable que se ejecute en un cluster.

Para configurar los nodos worker, añadiremos a su vez el argumento NServiceBus.Worker para establecer este comportamiento.

El funcionamiento o flujo de trabajo es el siguiente:

1. Los nodos worker envían un mensaje a [endpoint].distributor.control cada vez que están libres.
2. El nodo Master procesa la cola guardando todos los nodos workers disponibles en la cola [endpoint].distributor.storage.
3. Cuando el nodo Master recibe un mensaje utiliza el primer worker de la lista de [endpoint].distributor.storage para enviarle el mensaje y que lo procese.

   Ver Más

Siempre que usemos algún sistema de mensajería tenemos que adaptarnos al límite de tamaño del mensaje que el sistema es capaz de enviar. Este límite varía dependiendo de la tecnología usada.

En la mayoría de sistemas on-premise no hay mucho problema ya que el tamaño acostumbra a ser suficiente para la mayoría de casos. Por ejemplo, en MSMQ – el transporte por defecto en NServiceBus – el límite es de 4MB.

En sistemas en la nube este límite es notablemente inferior. Algunos ejemplos:

• Azure Queues: 8KB
• Azure Service Bus Queues: 64KB
• Amazon SQS: 64KB

En aquellos casos en los que se requiera un límite mayor ya sea porqué usamos NServiceBus en Azure o bien porqué queremos enviar algún dato de gran tamaño como una imagen o video, podemos hacer uso de la propiedad DataBusProperty.

Ver Más

Con la entrada del nuevo año ya falta menos para tener la versión definitiva de NServiceBus 3.0. Esta versión traerá un gran número de nuevas funcionalidades. Entre ellas:

• Integración de RavenDB para la persistencia de Sagas y almacenamiento de la información de subscripciones.
• Soporte para Azure.
• Transportar grandes cantidades de datos gracias al DataBus.
• Una configuración mucho más sencilla y no intrusiva.

Podéis leer un resumen de estas funcionalidades y descargar la beta desde aquí: http://www.nservicebus.com/NServiceBusV3NewFeatures.aspx

En este post hablaremos de los MessageMutators, una nueva funcionalidad que actúa como interceptores de los mensajes al llegar y/o al salir de nuestro endpoint. Así, podemos ejecutar transformaciones a nuestros mensajes de forma dinámica.

Ver Más