Patrón SAGA Choreography

Sesión 5: 3h39m

Existen 2 formas de implementar SAGA. 

SAGA - Corografía

La coreografía es una secuencia de pasos o movimientos en la danza... y también es similar en el desarrollo de software si aplicas SAGA - Coreografía. Con este enfoque, cada servicio produce y escucha los eventos de otros servicios, en función del evento de otros servicios decidirá la siguiente acción. La saga utiliza un bus de mensaje para comunicarse.

Flujo de SAGA-Choreography

1. El servicio de pedidos crea un registro en la base de datos con el estado "Verificando".
2. El servicio de pedidos publica un evento "El pedido se ha creado correctamente" y el servicio de Stock escuchará este evento.
3. El servicio de stock actualiza el número de productos de la base de datos stock.
4. El servicio de stock publica un evento "El producto se ha actualizado correctamente" y el servicio de pedidos y el servicio de envío escuchará este evento.
5. El servicio de pedido cambiará el estado del pedidio a "Envío"
6. El servicio de stock publica un evento "El producto se ha actualizado correctamente" y el servicio de pedidos y el servicio de envío escucharán este evento.
7. El servicio de envío crea un registro en la base de datos envíos.
8. El servicio de envío publica un evento "El envío se ha registrado correctamente" y el servicio de pedidos escuchará este evento.
9. El servicio de Pedido cambia el estado del pedido a "Finalizar".

Flujo de Rollback en SAGA-Choreography (Escenario 1)

Hay un error con Stock Service.

1. El servicio de pedidos crea un registro en la base de datos con el estado "Verificando"
2. El servicio de pedidos publica un evento "El pedido se ha creado correctamente" y el servicio de Stock escuchará este evento.
3. El servicio de stock actualiza el número de productos de la base de datos de stock. Pero hay un error inesperado al guardar el registro del producto.
4. Stock Service publica un evento de "reversión" "Error al actualizar el número de productos en stock". 
5. El servicio de pedido cambiará el estado del pedido a "Error".

Flujo de Rollback en SAGA-Choreography (Escenario 2)

El servicio de pedidos y el servicio de stock se ejecutan correctamente. Hay un error con el servicio de envío.

7. El servicio de envío crea un registro en la base de datos de envío. Pero hay un error inesperado al guardar.
8. El servicio de envío publica un evento de "reversión" "Error al registrar el servicio de envío" y tanto el servicio de pedidos.
9. El servicio de envío publica un evento de "reversión" "Error al registrar el servicio de envío" y tanto el servicio de stock.
10. El servicio de pedido cambiará el estado del pedido a "Error".
11. El servicio de stock actualiza el número del producto.

Flujo de SAGA-Choreography

• Tenga en cuenta que es crucial definir un ID compartido común para cada transacción, de modo que cada vez que lance un evento, todos los oyentes puedan saber de inmediato a qué transacción se refiere.
• Las compensaciones también pueden fallar. Pueden haber compensaciones reintentables.

Ventajas y desventajas de SAGA - Coreografía

• La coreografía es la forma más sencilla de implementar el patrón SAGA. Es muy fácil de entender y no requiere demasiado esfuerzo para construir. Cada transacción local en cadena es independiente ya que no tienen conocimiento directo entre sí. Si su transacción distribuida solo incluye de 2 a 4 transacciones locales (servicios), entonces la coreografía es una opción muy adecuada.
• Tener demasiadas transacciones locales hará que el seguimiento de qué servicios escuchan qué eventos, se vuelva complejo. Con la muestra anterior, solo tenemos 3 transacciones locales pero más de 10 pasos para manejar. Imaginemos que cuando tengamos 10 transacciones ¿qué sucederá?

Demo SAGA Choreography

Introducción del patrón SAGA

Sesión 5: 3h21m

Transacciones en un sistema distribuido

• Consistencia de los datos
• Las transacciones son el enfoque tradicional
• Transacciones del sistema monolítico
• Base de datos única, que es la única verdad
• Transacciones de microservicios
• Arquitectura distribuida
• Datos distribuidos
• Transacciones distribuidas
• Teorema de CAP
• La falla de la red sucederá
• Disponibilidad de datos o consistencia de datos

Opciones disponibles a nivel de transaccionalidad

• Transacciones ACID tradicionales
• Atomicidad, consistencia, aislamiento y durabilidad.
• Patrón de confirmación de dos fases (2PC)
• ACID es obligatorio
• Teorema CAP: Elección de consistencia.
• Patrón SAGA
• Atomicidad por disponibilidad y consistencia.
• Para sistemas distribuidos
• Patrón de consistencia eventual
• ACID
• Teorema CAP: Elección de disponibilidad.

Confirmación de 2 fases (Two Phase Commit / 2PC)

Lograr transacciones ACID en sistema distribuido.

• Patrón para transacciones distribuidas
• El administrador de transacciones maneja la transacciones
• Fase de preparación
• El gestor de transacciones notifica el inicio de preparación
• Fase de confirmación
• El gestor de transacciones recibe las confirmaciones.
• Gestor de transacciones
• Emite un Commit en caso todos hayan confirmado.
• Emite un Rollback en caso uno no haya confirmado.

• Advertencias
• Confianza en un administrador de transacciones
• Sin respuesta de confirmación
• Fallar después de una confirmación
• Las transacciones pendientes bloquean recursos
• Evitar implementaciones personalizadas
• Tiene problemas de escalado.
• Rendimiento reducido
• ANTIPATRÓN
• Considerar alternativas
• Patrón de Saga
• Consistencia eventual

Contexto

• Con la adopción del patrón "Base de datos por servicio" en la arquitectura de microservicios, significa que cada servicio tiene su propia base de datos.
• Existe un problema sobre cómo garantizar la coherencia de los datos entre los servicios.
• Por ejemplo, está implementando la función Pedido en un proyecto de Compras en línea. Cuando el usuario final realiza un pedido, la aplicación llamará al servicio de Stock para actualizar el número de producto en el stock, luego llamará al servicio de envío para entregar el producto solicitado al usuario final. 

•   ¿Cuál es el problema?
• ¿Qué sucede si la cantidad del producto es menor que la cantidad que pide el usuario final?
• ¿O qué sucede si hay un problema con el servicio de envío (shipping) y la aplicación no puede registrar el envío correctamente?
• Los pedidos, el artículo y el envío están en diferentes bases de datos, por lo que no podemos usar una transacción ACID local. Esa es la razón por la que no se puede usar uno de los tipos de transacciones que se llama "Confirmación de dos fases" - "2PC".
• Las transacciones distribuidas, como el protocolo de confirmación en dos fases (2PC), requieren que todos los participantes de una transacción la confirmen o reviertan antes de que la transacción pueda continuar. No obstante, algunas implementaciones de participantes, como las bases de datos NoSQL y la administración de mensajes, no admiten este modelo.

SAGA

• El patrón de saga proporciona la administración de transacciones mediante una secuencia de transacciones locales. 
• Una transacción local es el esfuerzo del trabajo atómico realizado por un participante de la saga. 
• Cada transacción local actualiza la base de datos y publica un mensaje o evento para desencadenar la siguiente transacción local en la saga. 
• Si se produce un error en una transacción local, la saga ejecuta una serie de transacciones de compensación que deshacen los cambios realizados por las transacciones locales anteriores.
• No existe el rollback en las transacciones distribuidas gestionadas por saga.
• Saga es la gestión de una transacción para mantener la disponibilidad como la consistencia.

• Las transacciones compensables son transacciones que se pueden invertir procesando otra transacción con el efecto opuesto.
• Una transacción dinámica es el punto en el que se debe continuar o no continuar en una saga. Si se confirma la transacción dinámica, la saga se ejecuta hasta su finalización. Una transacción dinámica puede ser una transacción que no es compensable ni reintentable, o puede ser la última transacción compensable o la primera transacción reintentable de la saga. 
• Las transacciones reintentables son transacciones que siguen a la transacción dinámica y que está garantizando que se realizarán correctamente. 

Recomendaciones para implementar CQRS

Sesión 5: 3h16m

Hay diferentes tipos de CQRS que puede aprovecharse en el diseño de software; No hay nada de malo en apegarse al tipo Regular y no avanzar más allá de los tipos Premium o Deluxe, siempre y cuando el tipo Regular cumpla con los requisitos de su aplicación. 

CQRS no es una elección binaria. Hay algunas variaciones diferentes entre no separar las lecturas y escrituras en absoluto (tipo regular) y separarlas complemetamente (tipo deluxe).

Debe haber un equilibrio entre el grado de segregación y la sobrecarga de complejidad que introduce. El equilibrio en sí debe encontrarse en cada aplicacio´n de software concreta aparte, a menudo después de varias iteraciones. El CQRS en sí no debe implementarse "solo porque podemos"; Solo debe ponerse sobre la mesa para cumplir con requisitos concretos, a saber, para escalar las operaciones de lectura de la aplicación.

Implementando CQRS (SQL y NoSQL)

Sesión 5: 2h37m

Ejemplo de implementación de CQRS

 

                     

Consistencia eventual en microservicios

Sesión 5: 1h18m

Requerimientos funcionales de MSA (Microservice Architecture)

Una arquitectura orientada a microservicios tiene que cumplir con algunos requisitos técnicos de arquitectura.

• Débilmente acoplado
• Independientemente cambiable
• Desplegable independientemente
• Contratos de apoyo y honor: El equipo tiene que auto-organizarse.
• API agnóstica a la tecnología
• Diseño para fallos

Cómo diseñar microservicios basados en API

• Estilo arquitectónico: Es el diseño de la aplicación en el nivel más alto de abstracción. Un ejemplo de estilo arquitectónico es microservicios.
• Patrón de arquitectura: cómo van a estar estructurados los componentes. Es una forma de implementar un estilo arquitectónico. Ejemplos:
• Estas capas los voy a organizar con MVC
• Voy a usar el patrón de descomposición DDD
• Voy a utilizar el patrón de BD por servicio
• Uso de Clean Architecture
• Patrón de diseño: Aquí ya estamos viendo código. Casos particulares a nivel de desarollo. Ejemplos:
• Patrón Observer
• Patrón Retry
• Patrón Circuit Breaker

Opciones de arquitectura

• Patrones de arquitectura API
• Facade pattern
• Proxy pattern
• Stateless service pattern
• Estilos de arquitectura API
• Pragmatic REST
• HATEOS (True REST)
• RPC
• SOAP

Estilo de arquitectura REST

Es el estilo arquitectónico que complementa a los microservicios es REST quien permite establecer mecanismos de comunicación.

¿Qué es REST?

• Es un estilo que define restricciones.
• Utiliza una infraestructura basada en HTTP
• Hereda las ventajas de la web
• Conceptos clave
• JSON, XML o CUSTOM
• Endpoints de recursos
• Interfaz de recursos uniforme

Consistencia Eventual

La consistencia eventual es un principio en sistemas distribuidos, como los microservicios, donde no se garantiza la consistencia inmediata de los datos en todo el sistema, pero se asegura que, con el tiempo, todos los nodos (o microservicios) llegarán a un estado consistente.

• Existen sitios web que necesitan un poco de paciencia. Haces una actualización de algo, se actualiza la pantalla y falta la actualización. Esperas uno o dos minutos, pulsas Refresh, y ahi está. 
• Incoherencias como esta son lo suficientemente irritantes, pero pueden ser mucho más graves. La lógica empresarial puede terminar tomando decisiones sobre información inconsistente, cuando esto sucede puede ser extremadamente difícil diagnosticar lo que salió mal porque cualquier investigación se producirá mucho después de que se haya cerrado la ventana de incoherencia.
• Los microservicios introducen problemas de coherencia eventuales debido a su loable insistencia en la administración descentralizada de datos. Con un monolito, puede actualizar un montón de cosas juntas en una sola transacción. 
• Los microservicios requieren varios recursos para actualizar y las transacciones distribuidas se fruncen el ceño (por una buena razón). Por lo tanto, ahora, los desarrolladores deben ser conscientes de los problemas de coherencia y averiguar cómo detectar cuándo las cosas están fuera de sincronización antes de hacer cualquier cosas que el código se arrepentirá. 
• La mayoría de aplicaciones necesitan bloqueos sin conexión para evitar transacciones de base de datos de larga duración.
• Los sistemas externos necesitan actualizaciones que no se puedan coordinar con un administrador de transacciones. 
• Los procesos de negocio son a menudo más tolerantes a las incoherencias, porque las empresas a menudo valoran más la disponibilidad.

Consistencia Eventual - Teorema de CAP

El teorema de CAP nos va a indicar 3 aspectos fundamentales para definir como vamos a modelar nuestra BD o nuestros procesos distribuidos.

• La consistencia (consistency): Cualquier lectura recibe como respuesta la escritura más reciente o un error.
• La disponibilidad (availability): Cualquier petición recibe una respuesta no errónea, pero sin la garantía de que contenga la escritura más reciente.
• Tolerancia al particionado (partition tolerance): El sistema sigue funcionando incluso si un número arbitrario de mensajes son descartados (o retrasados) entre nodos de la red.

Consistencia Eventual

• Los datos eventualmente serán consistentes
• BASE (no va haber una protección de transacción)
• BASE vs ACID
• ACID and BASE are two database transaction models, each with their own advantages and trade-offs. 
• Disponibilidad sobre consistencia
• Evitar el bloqueo de recursos
• Ideal para tareas de larga duración
• Preparado para inconsistencias
• Condiciones de carrera
• Replicación de datos
• Basado en eventos
• Transacción/acciones generadas como eventos
• Mensajes usando message brokers

Demo: Introducción a eventos

1h51m

Bus de Mensajes: Es un gestor de colas. Tenemos tecnologías como Rabbit, Kafka, Azure Service Bus, Amazon SNS, etc. Se recomienda Rabbit para la etapa de desarrollo y utilizar Kafka para producción. 

Nota: Para desarrollo multiplaforma se puede usar Microsoft Orleans.

Patrón CQRS a un microservicio

Sesión 5: 20m30s

El patrón CQRS no es exclusivo de microservicios.

Command Query Responsability Segregation (CQRS)

• CQRS
• Dividir las responsabilidades en lectura y escritura.
• Modelos de comando (Command) y/o servicios
• Modelos de consulta (Query) y/o servicios
• ¿Por qué?
• Separación de responsabilidades
• Notificaciones de eventos manejadas por comando (Escritura)
• Informes/funciones manejadas por consulta (Lectura)
• Separación de tecnologías
• Servicio y almacenamiento
• Desafíos
• Comando y consulta de sincronización de bases de datos.
• Tengo que mantener los datos sincronizados.

Usualmente se usa un Message Broker para actualizar el componente de consulta.

Tipos de CQRS

Ejemplo de código

• Un comando es un DTO
• MediateR es un procesador de comandos
• Usualmente Event Source y CQRS se usan juntos

Patrones de gobierno de datos

Sesión 5: 5m30s

Patrones de estructura de datos

• Base de datos por servicio: Cada microservicio administra sus datos (soberanía de datos). Los desarrolladores usan API's bien definidas para facilitar la comunicación entre las bases de datos de dos o más microservicios.
• Base de datos compartida (antipatrón): Permite que varios servicios accedan y almacenen datos en la misma base de datos. Si usa la base de adtos compartida apra varios microservicios, entonces caerá en un antipatrón y debe evitar estos enfoques.
• Patrón Saga: Saga es una secuencia de transacciones locales en la que el resultado de cada transacción depende de un nuevo evento anterior. Si alguna transacción falla, saga realiza una serie de transacciones de compensación. Gestión de transacciones distribuidas (pseudo transacción por que no cumple con todo los aspectos de una transacción).

No olvidar que los microservicios es una arquitectura lógica. Usualmente va a coincidir con la arquitectura física. Sin embargo, con el tiempo la arquitectura física se va ir complejizando. El uso de los DBLinks en base de datos también es un antipatrón.

Patrones de gestión de comunicación de los datos

• Patrón CQRS: Se proporciona a la base de datos de comandos y consultas separadas para realizar mejor la consulta de varios microservicios. CQRS ofrece un mayor rendimiento y una mejor escalabilidad de los microservicios.
• Patrón Event Sourcing: Proporciona acumular eventos y agregarlos en una secuencia de eventos en bases de datos. De esta manera podemos reproducir a cierto punto de los eventos. Este patrón está muy bien usando con cqrs y patrones de saga.
• Composición de APIs: Utiliza compositores de API para acceder a los conjuntos de datos de los servicios. Después de obtener los datos, el patrón utiliza una "unión en memoria" para emparejar dos servicios antes de enviarlos al consumidor.

Infraestructura de persistencia - NoSQL (CosmosDB)

Sesión 4: 3h48m

Tipos de Base de datos NoSQL

• Clave-Valor: Vincula una clave dada a un registro de cualquier tipo.
• Documental: Se basan en el conceptodetrás de clave-valor, extendiéndolo para admitir objetos complejos de varias capas denominados documentos.
• Columnar: Puede pensar en las filas como claves en un almacén clave-valor y las columnas como el valor.
• Grafos: Enfoque hacia la relación entre entidades. Las entidades, como los usuarios, están representadas por nodos, mientras que las conexiones dictan cómo se relacionan.

¿Cómo elegir la BD más óptima? Teorema CAP

MongoDB

• MongoDB es una base de datos de documentos que ofrece una gran escabilidad y flexibilidad y un modelo de consultas e indexación avanzado.
• MongoDB almacena datos en documentos flexibles similiares a JSON, po lo que los campos pueden variar entre documentos y la estructura de datos puede cambiarse con el tiempo.
• El modelo de documento se asigna a los objetvos en el código de su aplicación para facilitar el trabajo con los datos.
• MongoDB es una base de datos distribuida en su núcleo.

Cosmos DB

• Azure Cosmos DB es un servicio de base de datos con varios modelos distribuidos de forma global de Microsoft. Su compentencia es Amazon Aurora.
• Puede escalar de forma elástica el rendimiento y almacenamiento y sacar provecho del rápido acceso a datos.
• Base de datos relacional: PostgresSQL
• Base de datos NoSQL: MongoDB, Cassandra, Tables o Gremlin.

Git Branching Strategies

Relación jerárquica de conceptos:

Ciencia y Tecnología / Ingeniería
    └── Ciencias de la Computación / Tecnologías de la Información (TI)
        └── Ingeniería de software
            └── Configuration Management
                └── Control de versiones
                    └── Git
                        └── Git Branching Strategies

Una estrategia de branching en Git es un enfoque o metodología que define cómo organizar y gestionar las ramas de un proyecto en un repositorio Git. Estas estrategias ayudan a los equipos de desarrollo a colaborar de manera eficiente, mantener el código limpio y gestionar el ciclo de vida de las versiones.

Algunas de las estrategias más comunes son:

Git Flow:

• Utiliza ramas principales como main (o master) y develop.
• Ramas específicas para características (features), correcciones (hotfixes) y versiones de producción (releases).
• Es ideal para proyectos con ciclos de desarrollo largos y varias versiones de lanzamiento.

GitHub Flow:

• Más simple que Git Flow.
• Solo utiliza la rama main.
• Los desarrolladores crean ramas de características (feature branches) a partir de main y, cuando terminan, hacen un pull request para revisarlas y fusionarlas.
• Se enfoca en un desarrollo continuo y rápido, ideal para proyectos donde el despliegue es frecuente.

GitLab Flow:

• Similar a GitHub Flow, pero incluye varias ramas como main, staging y production para gestionar entornos de desarrollo, pruebas y producción.
• Permite una mejor alineación con los entornos de despliegue.

Trunk-based Development:

• Todo el desarrollo se realiza en una única rama, llamada trunk o main.
• Los cambios son pequeños y se fusionan rápidamente.
• Ideal para equipos que practican despliegues continuos y quieren minimizar el número de ramas largas.

Links

• What Are the Best Git Branching Strategies
• Gitflow - Animated
• Gitflow animado (Fullscreen)

Infraestructura de persistencia en NET 6 y MS SQL Server 2022

Clase 4: 3h41m

Cuando creamos aplicaciones .NET usualmente utilizamos bases de datos relacional en SQL Server. La herramienta con la que implementamos el acceso a datos es Entity Framework. 

Entity Framework Core

• EF Core es una versión ligera, extensible, de código abierto y multiplataforma de la popular tecnología de acceso a datos Entity Framework.
• EF Core puede servir como asignador relacional de objetos (O/RM), lo que permite a los desarrolladores de .NET trabajar con una base de datos mediante objetos .NET y eliminar la mayoría de acceso a los datos que normalmente deben escribir. 
• EF Core es compatible con muchos motores de bases de datos.

Entity Framework Core - Modelo

• Con EF, el acceso a datos se realiza mediante un modelo.
• Un modelo se compone de clases de entidad y un objeto de contexto que representa una sesión con la base de datos, lo que permite consultar y guardar los datos.
• Puede generar un modelo a partir de una base de datos existente, codificar manualmente un modelo para que coincida con la base de datos o usar migraciones de EF para crear una base de datos a partir del modelo y que evoluciones a mediad que cambia el modelo.

Entity Framework Core - Consultas

• EF Core usa Language Integrated Query (LINQ) para consultar datos de la base de datos. LINQ permite usar C# (o el lenguaje .NET que prefiera) para escribir consultas fuertemente tipadas.
• Usa el contexto derivado y las clases de entidad para hacer referencia a los objetos de base de datos. EF Core pasa una representación de la consulta LINQ al proveedor de la base de datos. A su vez, los proveedores de la base de datos la traducen al lenguaje de la consulta específico para la base de datos (por ejemplo, SQL para una base de datos relacional).

SQL Server / Azure SQL Database

• Una base de datos de SQL Server consta de una colección de tablas en las que se almacena un conjunto específico de datos estructurados.
• Una tabla contiene una colección de filas, tambien denominadas tuplas o registros, y columnas, también denominadas atributos.
• Cada columna de la tabla se ha diseñado para almacenar un determinado tipo de información; por ejemplo, fechas, nombres, importes en monena o números.

Links

• Try examples in your browser
• Entity Framework playground