Latest / M365.FM – Podcast de Microsoft 365, Copilot e IA en español / Azure Service Bus explicado: colas, temas, mensajes fallidos y mensajería fiable (Doblaje IA)

Transcript

Azure Service Bus explicado: colas, temas, mensajes fallidos y mensajería fiable (Doblaje IA) · M365.FM – Podcast de Microsoft 365, Copilot e IA en español

0:01
Speaker 2: Listo para 10 días de Microsoft 365, Copilot y Azure
0:05
Speaker 2: y las personas que dan forma al futuro del trabajo.
0:08
Speaker 2: Este enero, M365 con está de vuelta y venimos a
0:11
Speaker 2: lo grande. Únete a nosotros para sesiones en vivo, demostraciones
0:15
Speaker 2: reales y conocimientos prácticos de MVP y expertos de la
0:17
Speaker 2: industria en todo el mundo. Nada de diapositivas genéricas ni
0:20
Speaker 2: tecnicismos interminables. Abordaremos desafíos reales. Copilot Studio, agentes de IA, Fabric, Seguridad,
0:27
Speaker 2: Gobernanza y Automatización. Ya seas un profesional de TI, desarrollador
0:31
Speaker 2: o líder empresarial, hay sesiones diseñadas para ti. Con 10
0:35
Speaker 2: días completos, puedes explorar múltiples tecnologías y conectar con una
0:39
Speaker 2: comunidad global. Mira las sesiones en vivo y lleva conocimientos
0:42
Speaker 2: prácticos a tu organización. Enero de 2027. 10 días. Una
0:48
Speaker 2: sola comunidad Microsoft. El registro ya está abierto. Reserva tu
0:52
Speaker 2: lugar hoy mismo. Eso es m365.net. Únete ahora en m365.com
1:02
Speaker 2: y nos veremos en vivo en enero. Entonces, imagina que
1:05
Speaker 2: necesitas enviar un mensaje a un compañero de trabajo. Vas
1:07
Speaker 2: hacia él, le entregas una nota y esperas hasta que
1:10
Speaker 2: le lea y responda. Eso funciona bien cuando ambos están
1:12
Speaker 2: ahí presentados. Pero¿ qué pasa si están en una reunión?¿
1:14
Speaker 2: Fue al almorzar o de vacaciones por una semana? Estás estancado.
1:17
Speaker 2: No puedes avanzar con tu trabajo hasta que ellos respondan.
1:19
Speaker 2: Eso es exactamente lo que sucede cuando dos aplicaciones se
1:21
Speaker 2: comunican directo. Una aplicación envía una solicitud y espera. Si
1:24
Speaker 2: la otra aplicación está lenta, ocupada o falló, la primera
1:26
Speaker 2: aplicación se queda bloqueada. Los desarrolladores llaman a este acoplamiento.
1:30
Speaker 2: Las dos aplicaciones envejecen. Si una falla, la otra también
1:32
Speaker 2: se rompe. En un sistema con docenas de servicios, eso
1:35
Speaker 2: es un desastre. La solución pone un intermediario. Un buffer
1:38
Speaker 2: digital que acepta mensajes cuando el emisor está listo y
1:40
Speaker 2: los retiene hasta que el receptor pueda procesarlos. Este intermediario
1:43
Speaker 2: se llama Intermediaries of Messages. Azure Service Bus es la
1:45
Speaker 2: versión de Microsoft de ese intermediario.¿ Qué es realmente un
1:48
Speaker 2: intermediario de mensajes?¿ Qué es un intermediario de mensajes? Es
1:51
Speaker 2: una pieza de software que se sitúa entre aplicaciones y
1:53
Speaker 2: se encarga de pasar los mensajes. El emisor de mensajes
1:55
Speaker 2: es el intermediario y sigue adelante en esperas. El receptor
1:59
Speaker 2: recoge el mensaje cuando está listo. Ambos lados nunca hablan directamente.
2:02
Speaker 2: Solo hablan con el intermediario. Los desarrolladores llaman esto desacoplamiento
2:05
Speaker 2: y es el objetivo. Cuando dos aplicaciones están desacopladas, pueden
2:08
Speaker 2: fallar de forma independiente. Si el receptor falla, el emisor
2:10
Speaker 2: ni siquiera se entera. El mensaje simplemente permanece en el intermediario.
2:14
Speaker 2: Cuando el receptor vuelve a estar en línea, retoma donde
2:16
Speaker 2: se quedó. Sin pérdida de datos, sin errores que gestionar.
2:18
Speaker 2: También pueden escalar de forma independiente. Si el emisor recibe
2:21
Speaker 2: un flujo masivo de tráfico, puede seguir enviando mensajes tan
2:23
Speaker 2: rápido como quiera. El agente absorbe el pico. El receptor
2:26
Speaker 2: procesa su propio RIT. 10 mensajes por minuto o 10.000.
2:30
Speaker 2: Y si necesitas actualizar una aplicación, puedes hacerlo sin detener
2:32
Speaker 2: todo el sistema. El otro lado nunca nota la diferencia.
2:35
Speaker 2: Aquí hay una forma sencilla de pensar. Estás en un
2:37
Speaker 2: edificio de oficinas y necesitas entregar un documento a alguien
2:39
Speaker 2: en el tercer piso, pero está en una reunión. Podrías
2:41
Speaker 2: esperar afuera de la sala de reuniones. O podrías dejar
2:44
Speaker 2: el documento en la recepción. El recepcionista lo toma, tú
2:47
Speaker 2: vuelves a tu escritorio y el documento se entrega cuando
2:49
Speaker 2: la persona está libre. La recepción es tu agente mensajes.
2:52
Speaker 2: Acepta el mensaje, lo guarda de forma segura y lo
2:55
Speaker 2: entrega cuando el receptor está listo. Azure Service Bus es
2:58
Speaker 2: la versión de Microsoft totalmente administrada de esta recepción. Totalmente
3:02
Speaker 2: administrada significa que no te preocupas por infraestructura. Sin servidores
3:05
Speaker 2: que parchear, discos duros que reemplazar ni copias de seguridad
3:07
Speaker 2: que probar. Microsoft se encarga de todo esto. Solo creas
3:09
Speaker 2: un espacio de nombres, configuras tus colas y temas y
3:11
Speaker 2: comienzas a enviar mensajes. Es mensajería sin servidor. Pagas por
3:14
Speaker 2: lo que usas y nunca piensas en el hardware subyacente. Entonces,¿
3:18
Speaker 2: cómo organizas intermediarios mensajes? Utiliza dos estructuras principales, colas y temas.
3:22
Speaker 2: Comencemos con la más sencilla. Anatomía de mensaje. Entonces ya
3:25
Speaker 2: hemos cubierto la estructura. Ahora, hablemos de lo que realmente
3:28
Speaker 2: viaja a través de ellas, el mensaje en sí. Piensa
3:32
Speaker 2: en un mensaje en Azure Service Bus como un contenedor
3:34
Speaker 2: con dos partes principales, el cuerpo y los metadatos. El
3:38
Speaker 2: cuerpo es tu información real, lo que intentas enviar. Normalmente
3:41
Speaker 2: está formateado como JSON o XML. Textoprano también funciona. Y
3:45
Speaker 2: los datos binarios son compatibles, pero en la práctica JSON
3:47
Speaker 2: es el formato más común. Es legible por humanos, fácil
3:50
Speaker 2: de trabajar y cualquier lenguaje de programación puede manejarlo. Los
3:52
Speaker 2: metadatos es donde las cosas se ponen interesantes. Cada mensaje
3:55
Speaker 2: viene con un conjunto de propiedades del sistema que Service
3:57
Speaker 2: Bus asigna automáticamente. Cosas como un ID de mensaje único,
4:00
Speaker 2: una marca de tiempo que muestra cuándo se encoró el
4:02
Speaker 2: mensaje y un número de secuencia que indica la posición
4:04
Speaker 2: del mensaje en la cola. Estos son administrados por el sistema.
4:07
Speaker 2: Tú no los configuras, simplemente están ahí. Pero también puedes
4:09
Speaker 2: añadir tus propias propiedades personalizadas. Estos son pares clave de
4:12
Speaker 2: valor que tú defines, como la región del cliente con
4:14
Speaker 2: un valor de Europa o el total del pedido con
4:17
Speaker 2: un valor de 29.29 o la prioridad con un valor
4:18
Speaker 2: de alta. Estas propiedades personalizadas son fundamentales para filtrar en
4:21
Speaker 2: los temas.¿ Recuerda los filtros de suscripción de los que hablamos?
4:27
Speaker 2: Funcionan comparándose con estas propiedades personalizadas. Configuras el filtro que dice,
4:31
Speaker 2: solo recibir mensajes donde la región del cliente sea Europa.
4:34
Speaker 2: Y la suscripción usa la propiedad personalizada para decidir si
4:37
Speaker 2: acepta el mensaje. Existen límites en el tamaño del mensaje.
4:40
Speaker 2: En el nivel estándar, un mensaje puede tener hasta 256 kilobytes.
4:43
Speaker 2: Eso es suficiente para mayores datos empresariales, registros de pedidos,
4:46
Speaker 2: perfiles de clientes, confirmaciones de pago, todo está muy por
4:48
Speaker 2: debajo de ese límite. Si necesitas más, el nivel premium
4:50
Speaker 2: admite mensajes de hasta un megabyte. Pero si envías datos
4:53
Speaker 2: más grandes que eso habitualmente, probablemente no deberías ponerlos en
4:56
Speaker 2: un mensaje. Almacena los datos grandes en otro lugar y
4:59
Speaker 2: coloca una referencia en el mensaje. Ese es el patrón común.
5:01
Speaker 2: La entrega programada es una función útil. Envías un mensaje ahora,
5:04
Speaker 2: pero le indicas a Service Bus que no lo haga
5:05
Speaker 2: visible hasta un momento específico en el futuro. Imagina que
5:08
Speaker 2: quieres enviar un correo electrónico de recordatorio en 24 horas.
5:11
Speaker 2: Envías el mensaje ahora con un tiempo de puesta en
5:12
Speaker 2: cola programado para mañana. Service Bus lo retiene, permanece invisible
5:16
Speaker 2: y nadie puede leerlo. Luego, en el momento exacto programado,
5:19
Speaker 2: aparece en la cola como si se acabara de enviar.
5:21
Speaker 2: Esto es perfecto para flujos de trabajo basados en tiempo
5:23
Speaker 2: recordatorio o tiempos de espera y procesamiento. El ciclo de
5:26
Speaker 2: vida de un mensaje es así. Primero, se envía la
5:28
Speaker 2: cola o al tema. Service Bus lo almacena de forma
5:30
Speaker 2: duradera escrito en almacenamiento de triple room. Luego, un receptor
5:33
Speaker 2: solicita un mensaje. Service Bus lo bloquea para que ningún
5:35
Speaker 2: otro receptor pueda tomarlo. El receptor procesa el mensaje. Si
5:39
Speaker 2: todo se lee bien, el receptor llama a complete. Service
5:42
Speaker 2: Bus elimina el mensaje. Si algo sale mal, el receptor
5:44
Speaker 2: puede llamar a abandono. El bloqueo se libera y el
5:47
Speaker 2: mensaje vuelve a la cola para otro intento. Si el
5:50
Speaker 2: mensaje sigue fallando, finalmente se mueve a la cola de
5:52
Speaker 2: mensajes fallidos. Hablaremos de eso contigo. Lo importante es que
5:55
Speaker 2: los mensajes son duraderos. No desaparecen si un receptor falla.
5:58
Speaker 2: No se pierden si la red se cae. Permanecen en
6:00
Speaker 2: Service Boss almacenados de forma segura hasta que se procesan
6:02
Speaker 2: correctamente o se mueven explícitamente a la cola de mensajes fallidos.
6:05
Speaker 2: Esa confiabilidad es la razón principal para usar un agente
6:08
Speaker 2: de mensajes en primer lugar. Funciones avanzadas que marcan la diferencia.
6:12
Speaker 2: Ahora hablemos de las funciones que convierten una simple cola
6:14
Speaker 2: de mensajes en una plataforma en la que puedes confiar
6:15
Speaker 2: comenzando con la cola de mensajes fallidos. Mencionamos antes que
6:19
Speaker 2: los mensajes que siguen fallando finalmente se mueven a otro lugar.
6:22
Speaker 2: Ese otro lugar es la cola de mensajes fallido. Piénselo
6:24
Speaker 2: como una celda de retención. Cuando un mensaje excede su
6:27
Speaker 2: recuento máximo de entrega o cuando caduca porque expiró su
6:29
Speaker 2: tiempo de vida, no desaparece simplemente. Se mueve a una
6:32
Speaker 2: subcola separada dentro de la misma cola o suscripción. Puede
6:35
Speaker 2: inspeccionar esos mensajes, averiguar que salió mal y decidir qué hacer.
6:39
Speaker 2: Tal vez los datos estaban mal formados y necesita corregirlo.
6:41
Speaker 2: Tal vez la lógica de procesamiento tiene error. Tal vez
6:44
Speaker 2: el sistema de destino estaba fuera de servicio y deseaba
6:45
Speaker 2: intentar más tarde. La cola de mensajes fallido le ofrece
6:47
Speaker 2: un plan de respuesta. Nada se pierde silenciosamente. Ahora, aclaremos
6:50
Speaker 2: un malentendido común sobre las sesiones. De forma predeterminada, Azure
6:54
Speaker 2: Service Boost no garantiza que los mensajes se procesen en orden.
6:57
Speaker 2: Sé que dijimos que las cosas son fifo, primero entrar,
6:59
Speaker 2: primero salir. Y eso es cierto para cómo llegan los mensajes,
7:01
Speaker 2: pero el orden de procesamiento es otra historia. Si tiene
7:04
Speaker 2: varios consumidores extrayendo de la misma cola y un mensaje
7:07
Speaker 2: tarda más en procesarse que otro, el segundo mensaje podría
7:09
Speaker 2: terminar antes que el primero. El orden se pierde. Las
7:12
Speaker 2: sesiones solucionan esto. Una sesión agrupa mensajes relacionados. Usted asigna
7:16
Speaker 2: un ID de sesión a cada mensaje, como un número
7:18
Speaker 2: de pedido de cliente o un ID de instancia de
7:19
Speaker 2: flujo de trabajo. Todos los mensajes con el mismo ID
7:22
Speaker 2: de sesión son procesados por el mismo consumidor, uno a
7:24
Speaker 2: la vez y en orden. Ningún otro consumidor puede tocarlo.
7:27
Speaker 2: Esto le brinda un procesamiento FIFO estricto dentro de esa sesión.
7:30
Speaker 2: Diferentes sesiones aún pueden ser procesadas en paralelo por distintos consumidores.
7:34
Speaker 2: Así mantiene su rendimiento, mientras preserva el orden donde es importante.
7:37
Speaker 2: La detección de duplicados es otra gran característica. A veces
7:39
Speaker 2: la red tiene problemas. Su aplicación envía un mensaje, pero
7:42
Speaker 2: la respuesta se pierde. Entonces su aplicación envía de nuevo
7:45
Speaker 2: pensando que el primero nunca llegó. Sin detección de duplicados,
7:47
Speaker 2: ese mensaje se procesa dos veces. Con ella, Service Bus
7:51
Speaker 2: recuerda el ID del mensaje durante un periodo configurable, generalmente
7:54
Speaker 2: hasta 30 días. Si ve el mismo ID de mensaje
7:57
Speaker 2: de nuevo, descarta el duplicado silenciosamente. El receptor nunca sabe
8:00
Speaker 2: que hubo un reintento. Las transacciones le permiten agrupar varias
8:03
Speaker 2: operaciones en una unidad atómica. Tal vez necesite tomar un
8:05
Speaker 2: mensaje de una cola, procesarlo y enviar un resultado a
8:08
Speaker 2: otra cola. Si algún paso falla, desea que todo se revierta.
8:11
Speaker 2: El mensaje regresa a la primera cola. El resultado nunca
8:14
Speaker 2: se envía. Todo permanece consistente. Esto es crítico para los
8:16
Speaker 2: sistemas financieros, donde el procesamiento parcial es peor que no
8:19
Speaker 2: procesar nada. El reenvío automático le permite encadenar cola. Los
8:22
Speaker 2: mensajes llegan a una cola y se reenvían automáticamente a otra.
8:26
Speaker 2: Esto es útil para construir tuberías de procesamiento. Un mensaje llega,
8:29
Speaker 2: se valida y luego se reenvía a una cola diferente
8:31
Speaker 2: para realizar el trabajo real. La primera cola se mete
8:33
Speaker 2: en medio. La segunda cola se engarga del trabajo pesado.
8:36
Speaker 2: La postergación le permite emitir un mensaje temporalmente y se
8:38
Speaker 2: recibe un mensaje, pero los datos a los que hace
8:40
Speaker 2: referencia aún no están listos. Puede postergar Permanece en la cola,
8:43
Speaker 2: pero es invisible. Más tarde, usando el número de secuencia,
8:46
Speaker 2: puede recuperarlo y procesarlo cuando sea el momento adecuado. Estas
8:48
Speaker 2: características son las que separan una cola simple de un
8:51
Speaker 2: sistema sobre el que puede construir su negocio. Service Bus
8:53
Speaker 2: frente a las alternativas. Entonces,¿ cuándo eliges Service Bus en
8:56
Speaker 2: lugar de otra cosa? Permítame explicarse. Azure Storage Queues es
9:00
Speaker 2: la opción más sencilla, barata, rápida y fácil de configurar.
9:03
Speaker 2: Pero es una limitada. Los mensajes tienen un máximo de
9:06
Speaker 2: 64 kilobytes y no obtiene temas, sesiones, colas de mensajes
9:09
Speaker 2: fallidos ni transacciones. Son excelentes para colas de trabajos en
9:12
Speaker 2: segundo plano, donde solo necesita delegar tareas, pero si necesita
9:15
Speaker 2: alguna de las funciones avanzadas que mencionamos, la superará rápidamente.
9:18
Speaker 2: Event Hubs está diseñado para algo completamente diferente, la transmisión
9:21
Speaker 2: de eventos de alto rendimiento. Piensa en millones de eventos
9:24
Speaker 2: por segundo desde dispositivos IoT o registros de aplicaciones. No
9:27
Speaker 2: es un intermediario de mensajes, es una canalización de ingesta
9:29
Speaker 2: de datos. Por lo tanto, no lo usaría para flujos
9:31
Speaker 2: de trabajo transaccional. Lo usa cuando necesita capturar y procesar
9:34
Speaker 2: flujos masivos de datos. Event Grid es la opción ligera,
9:37
Speaker 2: un sistema de publicación y suscripción para activadores controlados por eventos.
9:41
Speaker 2: Cuando se carga un blob al almacenamiento, Event Grid puede
9:43
Speaker 2: activar una Azure Function. Cuando se crea un recurso, puede
9:46
Speaker 2: notificar a otros servicios. Es rápido, barato y perfecto para
9:49
Speaker 2: escenarios reactivos, pero no es una cola. No retiene mensajes
9:52
Speaker 2: para un procesamiento posterior, por lo que si el receptor
9:54
Speaker 2: está fuera de línea, el evento se pierde. Ahora, Service
9:56
Speaker 2: Bus se ubica justo en el medio. Tiene las ricas
9:59
Speaker 2: funciones de un intermediario empresarial sin la complejidad de administrar uno.
10:02
Speaker 2: Si necesita colas de mensajes fallidos, sesiones, transacciones, temas con
10:05
Speaker 2: filtros o entrega garantizada, Service Bus es la elección correcta.¿
10:09
Speaker 2: Qué hay de Kafka? Esta es una conversación completamente diferente.
10:11
Speaker 2: Service Bus es para comandos y flujos de trabajo comerciales,
10:14
Speaker 2: mientras que Kafka es para transmisión de eventos y análisis.
10:17
Speaker 2: Muchos sistemas grandes se utilizan ahora. ServiceBus maneja la mensajería operativa.
10:20
Speaker 2: Kafka maneja la canalización de datos. Son complementarios, no competidores.¿
10:24
Speaker 2: Qué hay en una regla general? Si se pregunta,¿ se
10:26
Speaker 2: procesó este mensaje correctamente? Use ServiceBus. Si se pregunta,¿ puedo
10:31
Speaker 2: reproducir la transmisión de eventos de la semana pasada? Use Kafka.
10:34
Speaker 2: Herramientas diferentes para trabajos diferentes. Casos de uso en el
10:36
Speaker 2: mundo real. Hagámoslo realidad con unos ejemplos. Así es como
10:39
Speaker 2: funciona ServiceBus en producción. Comencemos con el comercio electrónico. Un
10:42
Speaker 2: cliente realiza un pedido en un sitio web. El servidor
10:45
Speaker 2: web recibe el pedido, publica un mensaje en una cola
10:47
Speaker 2: de Service Bus y le dice al cliente, gracias, su
10:49
Speaker 2: pedido está confirmado, quemado. El cliente recibe una respuesta rápida
10:53
Speaker 2: sin tener que esperar. Detrás de escena, un grupo de
10:55
Speaker 2: servicios de trabajo extrae datos de esa cola. Un trabajador
10:58
Speaker 2: procesa el pago, otro verifica el inventario y otro prepara
11:00
Speaker 2: la etiqueta de envío. Cada trabajador toma el siguiente mensaje,
11:04
Speaker 2: hace su labor y continúa. El cliente nunca ve nada
11:06
Speaker 2: de eso, solo ve la confirmación. Ese es el patrón
11:09
Speaker 2: clásico de procesamiento asíncrono. Respuesta instantánea para el usuario, trabajo
11:13
Speaker 2: pesado en segundo plano. Los sistemas financieros llevan esto en serio.
11:16
Speaker 2: El procesamiento de pagos requiere entrega garantizada. No se puede
11:19
Speaker 2: perder una transacción y procesarla dos veces. Se requiere orden
11:21
Speaker 2: y transacciones. Service Bus le brinda todo eso. Llega un
11:24
Speaker 2: método de pago, se procesa y el resultado se envía
11:27
Speaker 2: a otra cola. Si algo falla, todo se revierte por
11:30
Speaker 2: lo que el dinero nunca se mueve incorrectamente. Aquí es
11:33
Speaker 2: donde brilla Service Bus. No solo mueve datos, sino que
11:35
Speaker 2: los mueve de forma segura. Ahora piensa en la distribución
11:37
Speaker 2: de múltiples servicios. Un nuevo cliente se registra en su plataforma.
11:40
Speaker 2: Usted desea que el CRM se entere, que el sistema
11:42
Speaker 2: de marketing envíe un correo de bienvenida y que el
11:43
Speaker 2: equipo de soporte cree un ticket. En lugar de llamar
11:45
Speaker 2: a tres servicios diferentes, usted publica un mensaje en un
11:48
Speaker 2: tema llamado cliente registrado. Cada servicio tiene su propia suscripción.
11:52
Speaker 2: La de suscripción del CRM toma cada mensaje. La de
11:55
Speaker 2: marketing filtra solo nuevos clientes y la de soporte filtra
11:58
Speaker 2: solo clientes premium. Un mensaje, tres reacciones. Y si lo
12:01
Speaker 2: añade a un cuarto servicio, simplemente crea una nueva suscripción.
12:04
Speaker 2: El remite nunca cambia. Las empresas de logística usan esto
12:07
Speaker 2: a gran escala. Imagina un sistema de seguimiento de paquetes
12:09
Speaker 2: donde cientos de miles de camiones envían actualizaciones de ubicación
12:12
Speaker 2: cada pocos segundos. Cada actualización es un mensaje y las
12:15
Speaker 2: actualizaciones de cada paquete deben procesarse en orden. No puede
12:17
Speaker 2: procesar la actualización de entregado antes que la de enviado
12:20
Speaker 2: para entrega. Las sesiones manejan esto. Cada paquete obtiene su
12:23
Speaker 2: propio ID de sesión y todas las actualizaciones de ese
12:25
Speaker 2: paquete pasan por la misma sesión en orden. Diferentes paquetes
12:28
Speaker 2: aún pueden procesarse en paralelo. Millones de paquetes, miles de
12:31
Speaker 2: millones de actualizaciones todo manejado de forma confiable. Las arquitecturas
12:34
Speaker 2: de microservicios usan Service Bus como su columna vertebral de
12:36
Speaker 2: comunicaciones Servicios no se llaman directamente entre sí, intercambian mensajes.
12:42
Speaker 2: El servicio A envía un comando a una cola, el
12:43
Speaker 2: servicio B lo recoge y hace el trabajo. El servicio
12:46
Speaker 2: C publica un evento en un tema, y los servicios
12:48
Speaker 2: D y E reaccionan cada uno a su manera, sin
12:51
Speaker 2: llamadas directas, sin acoplamiento estrecho. Cada servicio puede actualizarse, escalarse
12:55
Speaker 2: o reemplazarse sin afectar a los demás. Este es un
12:57
Speaker 2: patrón que se observa en empresas más antiguas. Tienen un
12:59
Speaker 2: sistema heredado de sus instalaciones que no es fácil de reemplazar,
13:01
Speaker 2: pero quieren usar servicios modernos en la nube. Así que
13:04
Speaker 2: cierran la brecha con ServiceBus. El sistema heredado envía mensajes
13:07
Speaker 2: a una cola y las aplicaciones en la nube los consumen.
13:10
Speaker 2: El sistema antiguo nunca sabe que se comunica con la
13:11
Speaker 2: nube y la nube nunca sabe que se comunica con
13:13
Speaker 2: un sistema antiguo. Service Bus se sitúa en el medio,
13:16
Speaker 2: traduciendo y retransmitiendo. La entrega programada gestiona las tareas docentes.
13:20
Speaker 2: Enviar un correo de recordatorio en 24 horas. Expirar esta
13:23
Speaker 2: reserva en 30 minutos si no se confirma. Generar un
13:25
Speaker 2: informe semanal cada lunes a las 8 am. Envíase el
13:28
Speaker 2: mensaje ahora con una fecha de entrega futura y Service
13:30
Speaker 2: Bus lo retiene y lo libera en el momento exacto.
13:33
Speaker 2: Sin trabajos cron, sin temporizadores en segundo plano, solo mensaje
13:36
Speaker 2: con temporizador. El hilo conductor en todos estos ejemplos es
13:38
Speaker 2: el mismo. El emisor no espera al receptor y el
13:41
Speaker 2: receptor no necesita estar conectado cuando se envía el mensaje. Desacoplados.
13:45
Speaker 2: Y ese desacoplamiento hace que todo el sistema sea más resistente,
13:47
Speaker 2: más escalable y más fácil de cambiar. El panorama general
13:51
Speaker 2: porque todo encaja. Entonces,¿ qué es exactamente Service Bus? Es
13:54
Speaker 2: la columna vertebral que permite que servicios independientes se comuniquen
13:56
Speaker 2: de forma fiable sin depender unos de otros. Tres palabras
13:59
Speaker 2: lo resumen. Desacoplar, almacenar y enrutar. Desacoplar significa que los
14:03
Speaker 2: servicios no necesitan conocerse entre sí, solo conocen la cola
14:06
Speaker 2: o el tema. Eso significa que puedes cambiar un servicio
14:08
Speaker 2: sin romper los demás, escalar uno sin afectar al resto
14:11
Speaker 2: y desplegar actualizaciones en uno mientras los demás siguen funcionando.
14:14
Speaker 2: Almacenar significa que cuando el tráfico aumenta la cola absorbe
14:16
Speaker 2: la carga. El emisor sigue enviando a máxima velocidad mientras
14:19
Speaker 2: el receptor procesa a su propio ritmo, por lo que
14:21
Speaker 2: nadie se bloquea ni se satura y el almacenamiento suaviza
14:23
Speaker 2: los picos y rellena los valles. Enrutar significa que las
14:27
Speaker 2: colas envían mensajes a un consumidor mientras que los temas
14:29
Speaker 2: transmiten a muchos y los filtros aseguran que cada consumidor
14:32
Speaker 2: reciba solo lo que necesita para que el mensaje llegue
14:34
Speaker 2: al lugar correcto automáticamente. Las colas manejan la distribución de
14:38
Speaker 2: trabajo punto a punto y los temas manejan la transmisión
14:40
Speaker 2: a muchos consumidores. Las funciones avanzadas manejan los casos excesivos.
14:44
Speaker 2: Los fallos van a la cola de mensajes fallidos, se
14:46
Speaker 2: ordenan las sesiones de usuario, se detectan duplicados, las transacciones
14:48
Speaker 2: mantienen todo consistente y...