DRASI: Detecta y reacciona ante cambios en tu base de datos

DRASI: Detecta y reacciona ante cambios en tu base de
datos. Software Craftsman Solution Architect @ AVANADE GitKraken Ambassador Arquitectura de Soluciones Versión 1.0.0, Abril de 2025

2 2 Reflexión: ¿un camino al agnosticismo? (1/2) Mi trabajo
principal es actuar como Arquitecto de Soluciones y Aplicaciones, y cuando es necesario, me sumerjo en el código, creando plantillas de código y preparando todo lo necesario para que lo que solicito pueda ser implementado eficazmente. Si bien prefiero delegar estas tareas en un líder de confianza, asumo la responsabilidad cuando se requiere asegurar que los proyectos avancen según lo planeado. Además, he llevado otras gorras: la de Arquitecto Empresarial, colaborando estrechamente con el CTO para garantizar que nuestra infraestructura tecnológica esté en sintonía con las estrategias y objetivos a largo plazo de la organización. Desde esta perspectiva, la adopción de tecnologías como Dapr1 y Keda es fundamental (graduados en la CNCF). Estas herramientas ofrecen beneficios inmediatos para la gestión de aplicaciones distribuidas y el escalado automático eficiente en Kubernetes. Más allá de sus ventajas operativas, son parte de una estrategia más amplia hacia un sistema hiperagnóstico de infraestructura, lo que significa que estamos construyendo una arquitectura flexible y adaptable, capaz de operar en múltiples entornos sin quedar atrapada en un único proveedor. En este contexto, también estamos observando el surgimiento de nuevos jugadores como Aspire, que se integra lógicamente con Dapr, microservicios, Docker, y otras tecnologías modernas. Aspire promete ser un aliado clave en nuestra transición hacia una infraestructura más ágil y eficiente. Los proyectos en incubación como Radius también son de gran interés para nosotros. Aunque están en desarrollo, representan el futuro de la interoperabilidad y la portabilidad, elementos cruciales para mantener la agilidad y la capacidad de respuesta de nuestra infraestructura tecnológica. Estar atentos a estos avances nos permite anticiparnos y prepararnos para integrarlos cuando estén listos para ser utilizados. Para las organizaciones que aún no han previsto una migración completa a la nube, integrar Kubernetes con tecnologías como Dapr y Keda representa un primer paso estratégico. Esta integración no solo facilita una eventual transición a la nube, sino que también mejora nuestra capacidad para escalar y gestionar aplicaciones en entornos locales. Si en algún momento decidimos trasladar nuestra infraestructura a la nube o cambiar de proveedor, esta estrategia nos permitirá hacerlo de manera más sencilla y con menos fricciones. 1Sé que muchos binding-block de Dapr para tecnologías de Azure, como Azure Service Bus, están en fase alfa desde hace ya varios años. Sin embargo, el primer paso era graduar Dapr para asegurar que el proyecto tuviera continuidad y pudiera integrarse eficazmente en nuestras estrategias tecnológicas.

3 3 Reflexión: ¿un camino al agnosticismo? (2/2) ¿Por qué
mi rol me exige estar pendiente de los proyectos de incubación o sandbox?, por que puedes descubrir proyectos como Drasi, que nos permitirá crear una arquitectura impulsada por eventos de manera agnóstica, adoptando una nueva filosofía que podría denominarse “data-driven". Drasi promete revolucionar nuestra interacción con los datos en tiempo real, posibilitando respuestas más rápidas y precisas a eventos empresariales críticos. O Backstage que nos permite crear un IDP. O COPA que nos permite aplicar parches rápidamente a imágenes de contenedores sin necesidad de reconstruirlas, lo cual es especialmente útil para abordar vulnerabilidades en imágenes base heredadas o aplicaciones de terceros que no se mantienen directamente y el tiempo (única cosa que no se recupera en esta vida). O Confidential Containers (aquí hablo de Confidential Computing). En mi rol, es fundamental asegurar que las decisiones tecnológicas no solo satisfagan las necesidades presentes, sino que también posicionen a nuestra organización para enfrentar futuros desafíos y oportunidades. La capacidad de movernos entre diferentes entornos, sean estos locales o en la nube, sin sufrir el temido bloqueo de proveedor, es una ventaja competitiva que no podemos pasar por alto. Mi objetivo personal, ya sea en mi rol de Arquitecto de Soluciones y Aplicaciones o como Arquitecto Empresarial, es diseñar una infraestructura resiliente y adaptable que esté alineada con la visión estratégica de la organización. Me esfuerzo por asegurar que nuestros recursos y atención estén centrados en la entrega de valor al usuario, evitando que nos quedemos atrapados resolviendo problemas invisibles para ellos. Para concluir, permítanme ofrecerles un consejo desde mi experiencia como profesional dedicado a ayudar a empresas en la modernización de sus aplicaciones o en la creación de nuevas desde cero. Considero fundamental tomar decisiones arquitectónicas sólidas que garanticen el éxito de cada proyecto. Para ello, resulta imprescindible documentar los Registros de Decisiones Arquitectónicas (ADRs), ya que nos proporcionan un registro claro de las razones detrás de nuestras elecciones y cómo estas contribuyen al desarrollo exitoso de las aplicaciones. Además, valoro profundamente la importancia de mantener una comunicación abierta y honesta con los clientes, asegurando que todos estén informados y que nuestra relación se base en la confianza y la transparencia. Jose María Flores Zazo, Abril de 2025

4 4 ¿Cómo está organizado este documento? • ¿Qué es?
• ¿Para qué sirve? • ¿Cómo funciona? • ¿Por qué utilizarlo? • ¿Dónde puedo aplicarlo? • Comparación con otras tecnologías similares • Conceptos clave • Caso de Uso I • Caso de Uso II • Conclusión https://drasi.io/

5 5 ¿Qué es? (1/3) Drasi es una plataforma de
procesamiento de datos diseñada para simplificar la detección de cambios en sistemas de datos y desencadenar respuestas automáticas a esos cambios. Permite el seguimiento de registros y flujos de cambio a través de varios sistemas, evaluándolos para determinar su relevancia y reaccionando en tiempo real. Drasi utiliza consultas continuas que monitorean los datos en tiempo real. Cuando ocurre un cambio que coincide con criterios predefinidos, Drasi activa acciones contextuales, haciendo el proceso eficiente y escalable. La arquitectura de Drasi se compone de tres componentes fundamentales: • Fuentes (Sources): Estas conectan Drasi a sistemas externos (bases de datos, sistemas de mensajería, etc.) y los monitorean para detectar cambios. • Consultas Continuas (Continuous Queries): Estas consultas se mantienen activas y se actualizan constantemente a medida que ocurren cambios en los datos. Utilizan el lenguaje de consulta Cypher para escribir consultas complejas basadas en gráficos. • Reacciones (Reactions): Se activan cuando las Consultas Continuas detectan cambios relevantes. Drasi proporciona reacciones estándar que envían estos cambios a sistemas externos o ejecutan comandos directamente dentro del sistema.

6 6 ¿Qué es? (2/3) D R A S I
Datos Consultas Continuas Relaciones Acciones Externas Fuentes

7 7 ¿Qué es? (3/3) ¿Otro Change Data Capture (CDC)?
Si ya tienes experiencia con herramientas tradicionales de Change Data Capture (CDC) y estás pensando que Drasi es más de lo mismo, déjame adelantarte que no es así. Drasi no se limita a capturar eventos de inserción, actualización o eliminación; su enfoque único basado en consultas continuas y el lenguaje Cypher permite no solo detectar cambios en tiempo real, sino también analizar y entender las relaciones complejas entre los datos, incluso cuando provienen de múltiples fuentes con esquemas dispares. Además, su capacidad para combinar datos relacionales, gráficos y de sistemas externos, junto con reacciones configurables que pueden ejecutar acciones automatizadas o integrarse en tiempo real con aplicaciones y servicios, redefine lo que significa procesar cambios en datos. Drasi no es más de lo mismo; es una evolución que convierte la detección de cambios en una herramienta de acción inteligente.

8 8 ¿Para qué sirve? (1/2) Drasi es una plataforma
innovadora diseñada para facilitar la gestión de eventos en sistemas complejos mediante la detección de cambios críticos y la ejecución de respuestas automáticas en tiempo real. A través de consultas continuas, Drasi monitorea datos provenientes de diversas fuentes, como bases de datos y sistemas de mensajería, permitiendo una integración eficiente en arquitecturas impulsadas por eventos. Esto significa que los desarrolladores/as pueden establecer criterios predefinidos para evaluar los cambios detectados y activar acciones contextuales adaptadas a los objetivos del negocio, optimizando así los procesos en tiempo real. La plataforma asegura que las respuestas sean oportunas y relevantes, sin necesidad de duplicar datos en un Data Lake ni realizar consultas repetitivas, lo que la hace ideal para aplicaciones de IoT, gestión de seguridad y otros escenarios donde la agilidad y la eficiencia son cruciales. El diseño flexible de Drasi permite la personalización y adaptación a entornos específicos, facilitando la creación de soluciones dinámicas y robustas que mejoran la operatividad empresarial. Al permitir una supervisión continua y una rápida reacción a los cambios, Drasi ayuda a mantener la claridad y simplicidad en sistemas complejos. Las organizaciones pueden reaccionar rápidamente a los cambios y aprovechar oportunidades en tiempo real, manteniendo la agilidad del negocio y optimizando el uso de recursos. Con su capacidad de integración y automatización, Drasi representa un avance significativo en el manejo de arquitecturas de datos modernas.

9 9 ¿Para qué sirve? (2/2) La automatización en tiempo
real de Drasi garantiza respuestas oportunas a eventos críticos, asegurando que las organizaciones puedan actuar de inmediato ante situaciones importantes. Gracias a sus consultas continuas, Drasi evalúa constantemente los cambios sin necesidad de duplicar datos, manteniendo la eficiencia del sistema. Su flexibilidad y capacidad de adaptación permiten una personalización acorde a necesidades específicas, lo que es fundamental para entornos de IoT y seguridad, donde la eficiencia en la gestión de arquitecturas de eventos es clave. Además, Drasi optimiza los recursos al mantener la agilidad y eficiencia en la gestión de datos, asegurando que las organizaciones puedan maximizar su rendimiento y capacidad de respuesta. En resumen: • Automatización en Tiempo Real: Respuestas oportunas a eventos críticos. • Consultas Continuas: Evaluación constante de cambios sin duplicar datos. • Flexibilidad y Adaptación: Personalización según necesidades específicas. • Ideal para IoT y Seguridad: Mejora la eficiencia en arquitecturas de eventos. • Optimización de Recursos: Agilidad y eficiencia en la gestión de datos. • Integración Eficiente: Conexión fluida con múltiples fuentes de datos. • Simplicidad en Complejidad: Simplifica la gestión de sistemas complejos.

10 10 ¿Por qué utilizarlo? La plataforma está diseñada para
abordar los desafíos asociados con las arquitecturas basadas en eventos, donde la detección de cambios relevantes puede ser abrumadora debido a la frecuencia y complejidad creciente de los eventos. Drasi simplifica la automatización de reacciones inteligentes en sistemas dinámicos, proporcionando información accionable en tiempo real sin la sobrecarga de los métodos tradicionales de procesamiento de datos. Utiliza consultas continuas para evaluar los cambios entrantes según criterios predefinidos, permitiendo una respuesta oportuna y pertinente. Esto se logra mediante sus tres componentes fundamentales: Fuentes, Consultas Continuas y Reacciones. Drasi es ideal para aplicaciones prácticas como la gestión de edificios inteligentes, donde puede monitorear las condiciones de las habitaciones y actualizar automáticamente los paneles de control. También puede mejorar la gestión de riesgos rastreando incidentes y alertando al personal clave cuando empleados o activos están en riesgo, optimizar sistemas de entrega activando acciones cuando los clientes llegan a zonas de recogida, y mejorar la seguridad detectando y respondiendo a amenazas potenciales en clústeres de Kubernetes. Ventajas de Drasi Desafíos de los sistemas tradicionales Reduce la carga operativa y de ingeniería. Desperdicio de recursos al consultar datos sin cambios. Detección de cambios precisa, escalable y declarativa. Lógica compleja para detectar y filtrar eventos genéricos. Marco estandarizado para reaccionar a cambios críticos. Soluciones personalizadas para detectar y reaccionar a eventos.

11 11 ¿Dónde puedo utilizarlo? (1/1) Cómo Drasi es una
plataforma versátil que se puede utilizar en diversos escenarios donde la detección de cambios en tiempo real y la reacción automática son cruciales aquí os presento algunas áreas y un caso de uso donde Drasi puede ser implementado: • Gestión de infraestructuras de TI: Monitoreo de servidores y redes para detectar fallos o anomalías, y activar procedimientos de remediación automáticamente. • Aplicaciones de IoT: Integración con dispositivos inteligentes para ajustar configuraciones en respuesta a cambios de entorno o necesidades del usuario. • Sistemas de seguridad: Vigilancia de sistemas para detectar amenazas potenciales y activar alertas o medidas de seguridad de manera inmediata. • Logística y transporte: Seguimiento de flotas y optimización de rutas en función de condiciones del tráfico o necesidades de entrega. • e-commerce: • Gestión de Inventarios: Drasi puede monitorear los niveles de inventario en tiempo real. Cuando detecta que un producto está próximo a agotarse, puede activar automáticamente el proceso de reabastecimiento, garantizando que siempre haya stock disponible. • Optimización de Ofertas y Promociones: Al detectar tendencias o cambios en el comportamiento de compra de los clientes, Drasi puede ajustar automáticamente las ofertas y promociones para maximizar las ventas y mejorar la experiencia del cliente.

12 12 ¿Dónde puedo utilizarlo? (2/5) • Seguimiento de Órdenes
de Compra: Drasi puede gestionar el flujo de órdenes de compra, asegurando que cada etapa del proceso se complete sin problemas y notificando a los equipos responsables si se detectan retrasos o errores. • Personalización de la Experiencia del Cliente: Al analizar el historial de navegación y compras de los usuarios, Drasi puede personalizar recomendaciones de productos y contenido en tiempo real, mejorando la satisfacción del cliente y aumentando las conversiones. • Salud y atención médica: Gestión de recursos hospitalarios: Drasi puede ayudar a optimizar la asignación de recursos hospitalarios, como camas y personal, en función de la demanda actual y cambios en las necesidades de atención, mejorando la eficiencia operativa y la atención al paciente. Nota del autor Si estás pensado en el típico patrón SAGA, déjame explicarlo más adelante. Te sorprenderá el nuevo enfoque. Nota del autor Si esas viendo que un modelo de WebSocket encaja con todo esto de Drasi, supones muy bien. Creo que vamos a poder sacar mucho partido a este protocolo y sobre todo a Azure SignalR.

13 13 ¿Dónde puedo utilizarlo? (3/5) Comparación entre Saga y
Drasi para el seguimiento de órdenes de compra: Saga • Descomposición de Transacciones: En un sistema utilizando el patrón Saga, cada etapa del proceso de una orden de compra se representa como una transacción individual. Si una etapa falla, se ejecutan acciones de compensación para revertir los cambios realizados. • Complejidad de Implementación: Implementar un patrón Saga requiere definir claramente cada paso y sus correspondientes acciones de compensación, lo cual puede ser complejo y requerir mucho código. • Manejo de Errores: La lógica de compensación debe ser cuidadosamente diseñada para asegurar que los errores se manejen correctamente, lo cual puede ser un desafío. Drasi • Automatización de Reacciones: Drasi simplifica el proceso al detectar automáticamente cambios en el flujo de órdenes de compra y activar reacciones contextuales sin necesidad de descomponer transacciones en etapas individuales. • Menor Complejidad: Al utilizar Drasi, la necesidad de implementar acciones de compensación se reduce, ya que las reacciones automatizadas pueden manejar errores en tiempo real y ajustar el proceso según sea necesario. • Monitoreo en Tiempo Real: Drasi ofrece una supervisión continua, lo que permite detectar y reaccionar ante retrasos o errores de manera inmediata, asegurando que el proceso se complete sin problemas.

14 14 ¿Dónde puedo utilizarlo? (4/5) Ventajas de usar Drasi
sobre el patrón Saga • Simplicidad: Drasi reduce la complejidad al proporcionar un marco de trabajo automatizado para la detección y reacción ante cambios, eliminando la necesidad de definir manualmente cada etapa y su lógica de compensación. • Agilidad: La capacidad de Drasi para reaccionar en tiempo real permite ajustes rápidos y eficientes, mejorando la respuesta ante errores o retrasos sin necesidad de desarrollar lógica de compensación extensa. • Escalabilidad: Drasi puede gestionar un gran número de órdenes de compra simultáneamente, adaptándose fácilmente a variaciones en la carga de trabajo sin comprometer la eficiencia. Caso de uso: Gestión de eventos en centros de conferencias Imagina un sistema implementado en un centro de conferencias que utiliza Drasi para gestionar los eventos que se llevan a cabo. Drasi puede monitorear los registros de reservas de salas y detectar cambios en el número de asistentes esperados, activando automáticamente ajustes en la logística del evento. Si el número de asistentes supera un umbral predefinido, Drasi puede enviar alertas al equipo de catering para aumentar el suministro de alimentos y bebidas, al equipo de limpieza para asegurar que las instalaciones estén adecuadas, y al personal de seguridad para ajustar la disposición de vigilancia. Este uso de Drasi facilita la gestión dinámica de eventos, asegurando que todos los equipos involucrados estén informados y puedan responder de manera oportuna a los cambios en las necesidades del evento.

15 15 ¿Dónde puedo utilizarlo? (5/5) Fuentes Registros de Reservas
de Salas (Base de Dato) Relaciones Acciones Externas Consultas Continuas Registro del Numero de Asistentes (Base de Datos) ¿Umbral de asistentes superado? Enviar Alerta Al equipo de catering Enviar Alerta Al equipo de limpieza Enviar Alerta Al equipo de seguridad

16 16 Comparación con otras tecnologías similares (1/6) Debezium Debezium
es una plataforma de captura de cambios en datos (CDC) que permite el monitoreo de bases de datos en tiempo real. Se integra con Apache Kafka para transmitir cambios y es compatible con múltiples sistemas de gestión de bases de datos como PostgreSQL, MySQL, MongoDB, entre otros. Apache Kafka Aunque Kafka es principalmente una plataforma de streaming de eventos, puede ser utilizada en combinación con herramientas de CDC como Debezium para procesar y reaccionar ante cambios en bases de datos. Kafka Streams permite el procesamiento de datos en tiempo real. AWS Lambda y DynamoDB Streams DynamoDB Streams permite capturar cambios en tablas de DynamoDB, y combinándolo con AWS Lambda, se pueden crear funciones que reaccionen a estos cambios, proporcionando una solución serverless para la detección de cambios en datos. Esto mismo podemos aplicarlo con Azure Functions y Azure Cosmos DB.

17 17 Comparación con otras tecnologías similares (2/6) Google Cloud
Pub/Sub Similar a Kafka, Google Cloud Pub/Sub es un servicio de mensajería asíncrona que puede ser utilizado para procesar eventos y cambios de datos en tiempo real. Se puede integrar con otras herramientas de Google Cloud para crear respuestas automáticas a cambios. Aunque realmente quien creo que es mejor para esto es API de BigQuery Storage Write. Change Data Capture (CDC) en SQL Server SQL Server ofrece funcionalidades de CDC que permiten detectar cambios en las bases de datos. Esto puede integrarse con otros sistemas para reaccionar ante estos eventos. Firebase Realtime Database Firebase ofrece una base de datos en tiempo real que permite detectar cambios de manera instantánea y reaccionar a ellos, especialmente útil para aplicaciones móviles y web.

18 18 Comparación con otras tecnologías similares (3/6) Como podéis
observar la única comparación posible es entre: Drasi y Debezium , herramientas que abordan la detección de cambios en bases de datos, pero no dependen de la propia base de datos. Trabajan de forma diferentes y están diseñadas para distintos propósitos. A continuación, te presento algunas diferencias clave entre ambas: Propósito y Enfoque • Debezium: Su principal objetivo es rastrear cambios en las bases de datos para integrarlos en sistemas de streaming de datos y otras aplicaciones. • Drasi: Se enfoca en la detección de cambios y la reacción a ellos en tiempo real. No solo se centra en la captura de cambios, sino también en proporcionar herramientas integradas para reaccionar a esos cambios mediante consultas continuas y acciones configurables. Tecnología Subyacente • Debezium: Se basa en Apache Kafka para la transmisión de mensajes. Depende Requiere un ecosistema Kafka para funcionar, lo que implica tener un cluster Kafka operando. • Drasi: No depende de Kafka u otro sistema de mensajería en particular. Está diseñado para integrar fuentes de datos, consultas y reacciones directamente dentro de su propio marco. Nota del autor Solamente voy a comprar Debezium con Drasi, las otras tecnologías no son CDC propiamente dichos, lo que si voy a comprar es con Azure Stream Analytics para que podáis ver alguna tecnología del ecosistema de Azure que puede llegar a ser similar a Drasi.

19 19 Comparación con otras tecnologías similares (4/6) Implementación y
Configuración • Debezium: Requiere configurar conectores para cada base de datos que se desea monitorear. Esto implica cierta complejidad en la configuración inicial, especialmente en entornos distribuidos. • Drasi: Proporciona un enfoque más integrado para configurar fuentes de datos, consultas y reacciones en un solo entorno, lo que puede simplificar la implementación de soluciones completas. Integración y Flexibilidad • Debezium: Se integra bien con otros componentes del ecosistema Kafka, lo que lo hace altamente flexible para arquitecturas basadas en eventos y microservicios. • Drasi: Está diseñado para ofrecer una solución más completa dentro de su propio entorno, facilitando la creación de soluciones que detectan y reaccionan a cambios sin necesidad de múltiples herramientas externas. Casos de Uso • Debezium: Es ideal para escenarios donde se requiere replicación de datos, sincronización entre sistemas, o alimentar sistemas de streaming de datos con cambios de la base de datos. • Drasi: Es adecuado para aplicaciones que necesitan reaccionar en tiempo real a cambios en los datos, como sistemas de alerta, actualizaciones en tiempo real, y aplicaciones interactivas. Debezium se centra solamente en la captura y transmisión de cambios de datos; Drasi va un paso más allá al proporcionar capacidades integradas para reaccionar a esos cambios. as implementar.

20 20 Comparación con otras tecnologías similares (5/6) Intencionadamente no
he puesto Azure Stream Analytics, por que quería abordarlo de forma individual. Drasi y Azure Stream Analytics comparten varias características. Ambas están diseñadas para procesar y analizar datos en tiempo real provenientes de diversas fuentes. Similitudes • Procesamiento en Tiempo Real: Están diseñadas para procesar datos en tiempo real, permitiendo a las organizaciones tomar decisiones rápidas basadas en eventos actuales. • Monitoreo Continuo: Ambas soluciones ofrecen capacidades para monitorear continuamente los flujos de datos y detectar cambios o patrones importantes. • Integración de Datos: Permiten la integración de datos de múltiples fuentes, como bases de datos, sistemas de mensajería y dispositivos IoT. • Automatización de Respuestas: Las dos plataformas pueden activar acciones automáticas en respuesta a eventos específicos, mejorando la eficiencia operativa.

21 21 Comparación con otras tecnologías similares (6/6) Diferencias •
Enfoque de Implementación: Drasi puede ofrecer un enfoque más centrado en la personalización y adaptación a entornos específicos, mientras que Azure Stream Analytics puede centrarse en un conjunto más estandarizado de capacidades analíticas. • Capacidades de Personalización: Drasi ofrece un nivel de personalización más elevado para definir criterios y acciones específicas, mientras que las plataformas de streaming ofrecen configuraciones predefinidas. • Infraestructura y Herramientas: Azure Stream Analytics esta asociada a la nube de Azure y herramientas para el procesamiento de datos con las que se puede integrar de forma muy sencilla incluso personalizados, mientras que Drasi esta diseñado para integrarse directamente sin depender de servicios externos. Aunque Drasi y Azure Stream Analytics comparten el objetivo de procesar y responder a datos en tiempo real, gracias a Darsi nos olvidamos del bloqueo de proveedor (vendor lock-in), esto afianza aun más uno de los objetivos del ecosistema que está promoviendo Microsoft con herramientas opensource destinadas al mundo de los contenedores. Nota del autor Supongo que han elegido la licencia Apache 2.0 sobre la licencia MIT (antes era un defensor de MIT por su permisividad hasta que ocurrió esto y vi que era mejor la Apache 2.0) por qué puede ofrecer ciertas ventajas, especialmente si deseas asegurarte de que tu proyecto no se convierta fácilmente en un proyecto de pago, os pongo las más relevantes: • Cláusula de Patentes: La licencia Apache 2.0 incluye una cláusula de concesión de patentes que otorga a los usuarios una licencia explícita para cualquier patente cubierta por el proyecto. Si un contribuyente inicia una demanda de patentes contra cualquier parte del proyecto, pierde sus derechos de patente bajo la licencia. Esto puede desincentivar a las entidades de convertir el proyecto en un producto de pago basado en patentes. • Protección de Marcas: Aunque ambas licencias permiten el uso comercial, Apache 2.0 tiene disposiciones más claras sobre el uso de marcas comerciales, lo que puede ofrecer una capa adicional de protección sobre cómo se puede comercializar el proyecto. • Requisitos de Distribución: La licencia Apache 2.0 requiere que se mantengan las notificaciones de copyright y licencias en las copias del software, y que se incluya una copia de la licencia, lo cual puede hacer más difícil que alguien privatice el código sin cumplir con estos requisitos.

22 22 Conceptos clave (1/9) Fuentes Las "Fuentes" en Drasi
proporcionan conectividad a los sistemas que Drasi puede observar como fuentes de cambio. Cumplen tres funciones importantes: • Procesan el registro de cambios generado por el sistema fuente y lo envían a consultas continuas. • Traducen los datos de cambio en un modelo de datos consistente de gráfico de propiedades • Y permiten que las consultas continuas inicialicen el estado del resultado de la consulta. Para crear una fuente, se utiliza la CLI de Drasi, proporcionando direcciones de puntos de acceso y credenciales para el sistema fuente y definiendo el recurso de fuente en un archivo YAML. apiVersion: v1 kind: Source name: <id> spec: kind: <source-type> properties: ... source.yaml drasi apply -f source.yaml Crear drasi list source Listar drasi delete source <id> Borrar

23 23 Conceptos clave (2/9) Consultas Continuas Las Consultas Continuas
son el componente más importante de Drasi. Permiten especificar qué cambios detectar en los sistemas fuente y qué datos distribuir cuando se detectan cambios. A diferencia de las consultas instantáneas, las Consultas Continuas se ejecutan perpetuamente, manteniendo un resultado de consulta preciso y actualizado con los cambios en la base de datos fuente. Se implementan como consultas de gráficos escritas en el lenguaje Cypher (un lenguaje que no es nuevo, aquella persona que me siguen sabrá que es el que se usa en Neo4j para grafos, aunque en este caso como se está desarrollando mejor fijarse en la documentación oficial) permitiendo detectar cambios complejos y generar notificaciones detalladas de los mismos. Continuando con nuestro caso de uso “Gestión de eventos en centros de conferencias”, supongamos: • Nodos Event: Cada objeto representa un evento, con un identificador único eventId, un nombre, el número de asistentes esperados, y la fecha del evento. • Nodos Room: Cada objeto representa una sala, con un identificador único roomId, un nombre y la capacidad máxima de la sala. • Relación Hosted_In: Cada objeto representa la relación entre un evento y una sala, indicando qué evento se lleva a cabo en qué sala a través de los identificadores eventId y roomId.

24 24 Conceptos clave (3/9) [ { "eventId": "ev001", "name":
"Tech Conference 2023", "expectedAttendees": 150, "date": "2023-11-10" }, { "eventId": "ev002", "name": "Annual Gala", "expectedAttendees": 80, "date": "2023-12-05" }, { "eventId": "ev003", "name": "Startup Pitch Night", "expectedAttendees": 120, "date": "2023-12-15" } ] [ { "roomId": "rm101", "name": "Main Hall", "capacity": 200 }, { "roomId": "rm102", "name": "Conference Room A", "capacity": 100 }, { "roomId": "rm103", "name": "Banquet Hall", "capacity": 150 } ] [ { "eventId": "ev001", "roomId": "rm101" }, { "eventId": "ev002", "roomId": "rm103" }, { "eventId": "ev003", "roomId": "rm102" } ] Event Hosted_In Room Nota del autor El ejemplo es relacional para que se entienda mejor.

25 25 Conceptos clave (4/9) apiVersion: v1 kind: ContinuousQuery name:
catering-alert spec: mode: query sources: subscriptions: - id: event-management nodes: - sourceLabel: Event - sourceLabel: Room relations: - sourceLabel: HOSTED_IN joins: - id: EVENT_TO_ROOM keys: - label: Event property: eventId - label: Room property: roomId query: > MATCH (e:Event)-[:HOSTED_IN]->(r:Room) WHERE e.expectedAttendees > 100 RETURN e.name AS EventName, e.expectedAttendees AS AttendeesCount, r.name AS RoomName query.yaml

26 26 Conceptos clave (5/9) Explicación del Ejemplo: • Fuentes
y Suscripciones: La consulta continua se suscribe a la fuente event-management, monitoreando nodos etiquetados como Event y Room, y la relación Hosted_In para identificar qué evento se lleva a cabo en qué sala. • Joins: Unimos datos de eventos y salas utilizando las propiedades eventId y roomId para crear una conexión entre ellos. • Consulta Cypher: La consulta detecta eventos donde el número de asistentes esperados supera los 100. Devuelve el nombre del evento, la cantidad de asistentes y el nombre de la sala, que son los datos relevantes para el equipo de catering. Obtenemos como resultado: [ { "EventName": "Tech Conference 2023", "AttendeesCount": 150, "RoomName": "Main Hall" }, { "EventName": "Startup Pitch Night", "AttendeesCount": 120, "RoomName": "Conference Room A" } ]

27 27 Conceptos clave (6/9) Los middlewares son componentes esenciales
en la arquitectura de Drasi que permiten el procesamiento previo de cambios entrantes desde las fuentes de datos antes de que lleguen al motor de consultas. Su función principal es transformar, modificar o enriquecer los datos según sea necesario, facilitando tareas como la normalización de valores, la aplicación de mapeos o el agregado de campos calculados. Funcionalidades de los Middlewares: • Transformación de Datos: Los middlewares pueden modificar los datos entrantes para ajustarse a las necesidades específicas de la aplicación. Por ejemplo, pueden cambiar el formato de los datos o combinar varios campos en uno. • Enriquecimiento de Datos: Pueden agregar información adicional a los datos entrantes, como cálculos basados en los datos existentes o la inserción de datos externos. • Normalización: Ayudan a estandarizar los valores de los datos, asegurando que todos sigan un formato consistente. apiVersion: v1 kind: ContinuousQuery name: catering-alert spec: ... query.yaml drasi apply -f query.yaml Crear drasi list query Listar drasi delete query <id> Borrar

28 28 Conceptos clave (7/9) Tipos de Middleware • Unwind:
Se utiliza para descomponer un array de valores anidado dentro de las propiedades de un nodo o relación, creando nuevos elementos de nivel superior en el gráfico. • Map: Permite remapear una inserción, actualización o eliminación entrante de una fuente a una operación diferente para otro elemento, facilitando la modificación del flujo de datos entre diferentes entidades. Ejemplo Práctico: Unwind Middleware Imagina que los registros de reservas de salas incluyen un array de "asistentes esperados" con detalles sobre cada grupo de asistentes. El middleware Unwind puede descomponer este array en nodos individuales de "Grupo de Asistentes", cada uno con su propio número de personas, tipo de grupo (VIP, regular, etc.), y requerimientos especiales. Esto permite una gestión más precisa de los recursos necesarios para cada grupo específico dentro de un evento. Ejemplo Práctico: Map Middleware Supongamos que tienes un registro de cambios en el número de asistentes que es solo de inserción, pero el sistema solo necesita el valor más reciente para activar alertas. El middleware Map puede remapear las inserciones de los registros a actualizaciones de un nodo "Evento", asegurando que solo se mantenga el número actual de asistentes. Esto optimiza el uso de memoria y procesamiento, permitiendo que el sistema reaccione rápidamente a cambios que superen el umbral predefinido.

29 29 Conceptos clave (8/9) Los middlewares se configuran en
Drasi mediante archivos YAML, donde se definen sus tipos, nombres y propiedades específicas necesarias para su operación. Esto proporciona flexibilidad y adaptabilidad en el manejo de datos, ajustándose a las necesidades dinámicas de la gestión de eventos. apiVersion: v1 kind: ContinuousQuery name: catering-alert spec: mode: query sources: subscriptions: - id: event-management nodes: - sourceLabel: Event - sourceLabel: Room relations: - sourceLabel: HOSTED_IN joins: - id: EVENT_TO_ROOM keys: - label: Event property: eventId - label: Room property: roomId middleware: - name: extract-attendees kind: unwind Event: - selector: $.expectedAttendees[*] label: AttendeeGroup key: $.groupType relation: HAS_GROUP - name: latest-attendee-count kind: map Event: insert: - selector: $ op: Update label: Event id: $.eventId properties: eventId: $.eventId currentAttendees: $.expectedAttendees query: > MATCH (e:Event)-[:HOSTED_IN]->(r:Room) WHERE e.currentAttendees > 100 RETURN e.name AS EventName, e.currentAttendees AS AttendeesCount, r.name AS RoomName

30 30 Conceptos clave (9/9) Reacciones Las reacciones en Drasi
son componentes que procesan los cambios en los resultados de una o más Consultas Continuas y actúan sobre ellos. La acción específica depende del tipo de reacción que se esté utilizando. De momento tenemos reacciones para: AWS EventBridge, Azure Event Grid, Azure Storage Queue, Debezium, Drasi Debug, Drasi Result, Comando Gremlin, SignalR, Procedimiento Almacenado. apiVersion: v1 kind: Reaction name: <id> spec: kind: <reaction-type> queries: <query-id>: <query-config> ... properties: (reaction kind specific fields) reaction.yaml drasi apply –f reaction.yaml Crear drasi list reaction Listar drasi delete reaction <id> Borrar

31 31 Caso de Uso I (1/10) Gestión de eventos
en centros de conferencias Este ejemplo es la continuación del caso de uso que he definido anteriormente (página 13). Prerrequisitos • Docker. • Kind. • Visual Studio Code + extensión de Drasi + extensión de Kubernetes. Instalación de Drasi • Pasos disponibles para el entorno que uses. En mi caso estoy usando Kind. En mi caso uso para instalar Drasi, el flag --local , de esta forma no tengo que conectarme con el registro de imágenes on-line. • Lanzar el test rápido para observar que Drasi esta funcionando correctamente. Desplegar y configurar SQL Server en el Cluster de Kubernetes kubectl create namespace usecase-drasi-one kubectl get namespaces --no-headers -o custom-columns=NAME:.metadata.name

32 32 Caso de Uso I (2/10) • Clonamos este
proyecto: https://github.com/jmfloreszazo/drasi_detect_changes_database • Usamos la carpeta usercas_one.

33 33 Caso de Uso I (3/10) • Aplicamos el
despliegue: kubectl apply -f sql-server-deployment.yaml • Revismos el estado de pod, puede tardar unos segundos (depende de tu equipo): kubectl get pods -n usecase-drasi-one • Miramos la IP del nodo para asegurarnos que esta todo correcto: kubectl get service sql-server -n usecase-drasi-one

34 34 Caso de Uso I (4/10) • Usamos un
port-forward como solución temporal (solo se usa en desarrollo o pruebas): kubectl port-forward service/sql-server 1433:1433 -n usecase-drasi-one • Finalmente podemos conectamos contra localhost puerto 1433 en cualquier herramienta que uses para trabajar con SQL Server. • Creamos una nueva base de datos y añadimos el contenido: db-template.sql

35 35 Caso de Uso I (5/10) • Desplegamos una
cola en Azure Storage Account. Y nos guardamos la cadena de conexión. • O desplegamos en un Azure EventGrid. Tenéis los dos ficheros en el directorio para ejecutar el que más os interese, pero en este caso debes escoger el esquema como CloudEvents.

36 36 Caso de Uso I (5/10) • Desplegamos una
cola en Azure Storage Account. Y nos guardamos la cadena de conexión. • Por tanto, tenemos un origen de datos (Source)que es un SQL Server en nuestro K8s local y como reacción (Reactions) llevará la información a nuestro Azure Storage Account (reacciones disponibles). Con la infraestructura desplegada y funcional, es le momento de trabajar con Drasi. • Creamos el YAML de origen: my-source.yaml • Aplicamos el origen: drasi apply -f my-source.yaml

37 37 Caso de Uso I (6/10) • Revisamos el
estado del origen: drasi list source

38 38 Caso de Uso I (7/10) • Creamos el
YAML de reacción: my-continuous-query.yaml • Aplicamos la reacción: drasi apply -f my-continuous-query.yaml • Revisamos el estado de la reacción: drasi list query

39 39 Caso de Uso I (8/10) • Creamos el
YAML de la reacción: my-reaction-az-eventgrid.yaml • Aplicamos la reacción: drasi apply -f my-reaction-az-eventgrid.yaml • Revisamos el estado de la reacción: drasi list reaction

40 40 Caso de Uso I (9/10) • Ahora ejecutamos
esta consulta: INSERT INTO Events (eventId, name, expectedAttendees, eventDate) VALUES ('ev004', 'Drasi Conf 2025', 120, '2025-04-05'); • Observamos si la consulta continua esta funcionando: Nota del autor Observa que en la versión 0.2.0 de Drasi tenemos de momento una opción que nos muestra lo que está ocurriendo con nuestra consulta continua.

41 41 Caso de Uso I (10/10) • Y finalmente
miramos si efectivamente el evento esta en el EventGrid, que en mi caso lo he reenviado a un Azure Storage Account:

42 42 Caso de Uso II (1/3) Sensor de Temperatura
(IoT) Este ejemplo muestra como una aplicación de IoT saca la temperatura media de dispositivo y lo envía, esta vez, al debug para que puedas observar como funciona. Pasos • Usamos la carpeta usercas_two. • Ejecuta: db-template.sql • Crea el origen: my-source.yaml • Añade la consulta continual: my-continuous-query.yaml • Establece la reacción: my-reaction.yaml • Reasignamos los puertos para poder ver el portal: kubectl port-forward -n drasi-system services/iot-tracking-debug-gateway 8080:8080 • http://127.0.0.1:8080/query/iot-tracking-query-avg-last-30s

43 43 Caso de Uso II (2/3)

44 44 Caso de Uso II (3/3) • Ejecutamos el
bucle que generar telemetría y volvemos a entrar en el depurador:

DRASI: Detecta y reacciona ante cambios en tu b...

DRASI: Detecta y reacciona ante cambios en tu base de datos

More Decks by Jose María Flores Zazo

Other Decks in Programming

Featured

Transcript