Latest / M365.FM – Microsoft 365, Copilot & AI podcast in het Nederlands / Azure Service Bus uitgelegd: wachtrijen, onderwerpen, dead-letter en betrouwbare berichtenuitwisseling (AI-nasynchronisatie)

Transcript

Azure Service Bus uitgelegd: wachtrijen, onderwerpen, dead-letter en betrouwbare berichtenuitwisseling (AI-nasynchronisatie) · M365.FM – Microsoft 365, Copilot & AI podcast in het Nederlands

• 0:00
  Speaker 2: Klaar voor 10 dagen Microsoft 365, Copilot, AI, Azure en
• 0:05
  Speaker 2: de mensen die de toekomst van werk vormgeven? Deze januari
• 0:09
  Speaker 2: is M365 komt terug en pakken we groter uit. Doe
• 0:13
  Speaker 2: mee voor live sessies, praktijkdemo's en praktische kennis van MVP's
• 0:17
  Speaker 2: en experts wereldwijd. Geen algemene sliedes, geen eindeloze modewoorden. We
• 0:22
  Speaker 2: pakken de echte uitdagingen aan Copilot Studio, AI Agents, Fabric, Beveiliging,
• 0:27
  Speaker 2: Governance en Automatisering. Of je nu een IT professional, ontwikkelaar
• 0:32
  Speaker 2: of zakelijk leider bent, er zijn sessies voor jou ontworpen.
• 0:35
  Speaker 2: Met 10 volledige dagen kun je diverse technologieën verkennen en
• 0:38
  Speaker 2: in contact komen met een wereldwijde community. Kijk live mee
• 0:41
  Speaker 2: en neem praktische inzichten mee terug naar je organisatie. Januari 2027,
• 0:47
  Speaker 2: 10 dagen, 1 Microsoft Community. De registratie is nu geopend.
• 0:51
  Speaker 2: Claim vandaag nog je plek. Dat is m365com.net Meld je
• 1:00
  Speaker 2: aan op m365com.net en we zien je live in januari.
• 1:05
  Speaker 2: Stel je voor dat je een bericht naar een collega
• 1:07
  Speaker 2: moet sturen. Je loopt erheen, geeft een briefje en wacht
• 1:09
  Speaker 2: tot ze het lezen en reageren. Dat werkt prima als
• 1:12
  Speaker 2: jullie er allebei zijn. Maar wat als ze in een
• 1:14
  Speaker 2: vergadering zitten, lunchen of een week op vakantie zijn? Dan
• 1:16
  Speaker 2: loop je vast. Je kunt niet verder met je werk
• 1:18
  Speaker 2: tot ze antwoorden. Dat is precies wat er gebeurt wanneer
• 1:21
  Speaker 2: twee apps direct met elkaar praten. De ene app stuurt
• 1:23
  Speaker 2: een verzoek en wacht. Als de andere app traag of
• 1:25
  Speaker 2: bezet is of gecrash is, loopt de eerste app vast.
• 1:28
  Speaker 2: Ontwikkelaars noemen dit nauwe koppeling. De twee apps zitten aan
• 1:30
  Speaker 2: elkaar vast. Als er een faalt, faalt de ander ook.
• 1:33
  Speaker 2: In een systeem met tientallen services is dat een ramp.
• 1:36
  Speaker 2: De oplossing zet een tussenpersoon tussen hen in. Een digitale
• 1:38
  Speaker 2: buffer die berichten accepteert wanneer de verzender er klaar voor
• 1:40
  Speaker 2: is en ze vasthoudt tot de ontvanger ze kan verwerken.
• 1:42
  Speaker 2: Die tussenpersoon wordt een message broker genoemd. Een Azure Service
• 1:45
  Speaker 2: Bus is Microsofts versie van die tussenpersoon. Wat is eigenlijk
• 1:48
  Speaker 2: een message broker? Dus, wat is een message broker nu echt?
• 1:51
  Speaker 2: Het is software die tussen apps in staat en het
• 1:53
  Speaker 2: doorgeven van berichten afhandelt. De verzender stuurt een bericht naar
• 1:56
  Speaker 2: de broker en gaat weer door. Niet wachten, de ontvanger
• 1:59
  Speaker 2: haalt het bericht op wanneer die er klaar voor is.
• 2:00
  Speaker 2: De twee partijen praten nooit direct met elkaar. Ze praten
• 2:03
  Speaker 2: alleen met de broker. Ontwikkelaars noemen dit ontkoppeling en dat
• 2:05
  Speaker 2: is precies het punt. Wanneer twee apps ontkoppeld zijn, kunnen
• 2:08
  Speaker 2: ze onafhankelijk falen. Als de ontvanger crasht, merkt de verzender
• 2:11
  Speaker 2: daar niets van. Het bericht blijft gewoon in de broker wachten.
• 2:13
  Speaker 2: Wanneer de ontvanger weer online komt, gaat deze verder waar
• 2:16
  Speaker 2: hij was gebleven. Geen dataverlies, geen fouten om af te handelen.
• 2:18
  Speaker 2: Ze kunnen ook onafhankelijk schalen. Als de verzender een vloedgolf
• 2:21
  Speaker 2: aan verkeer krijgt, kan deze berichten blijven versturen zo snel
• 2:23
  Speaker 2: als gewenst. De broker vangt de piek op. De ontvanger
• 2:26
  Speaker 2: verwerkt deze in zijn eigen tempo. 10 berichten per minuut
• 2:29
  Speaker 2: of 10.000. En als je één hebt moet bijwerken, kun
• 2:31
  Speaker 2: je dat doen zonder het hele systeem plat te leggen.
• 2:33
  Speaker 2: De andere kant merkt er niets van. Hier is een
• 2:35
  Speaker 2: eenvoudige manier om erover na te denken. Je bent in
• 2:37
  Speaker 2: een kantoorpand en moet een document aan iemand op de
• 2:39
  Speaker 2: derde verdieping geven, maar diegene is in vergadering. Je zou
• 2:42
  Speaker 2: buiten de vergaderruimte kunnen wachten... of het document bij de
• 2:44
  Speaker 2: receptie kunnen achterlaten. De receptionist neemt het aan, jij gaat
• 2:47
  Speaker 2: terug naar je bureau en het document wordt bezorgd wanneer
• 2:49
  Speaker 2: de persoon vrij is. De receptie is je message broker.
• 2:52
  Speaker 2: Deze accepteert het bericht, bewaart het veilig en bezorgt het
• 2:55
  Speaker 2: wanneer de ontvanger klaar is. Azure Service Bus is de
• 2:58
  Speaker 2: volledig beheerde versie van Microsoft van deze receptie. Volledig beheerd
• 3:01
  Speaker 2: betekent dat je je geen zorgen hoeft te maken over
• 3:03
  Speaker 2: de infrastructuur. Geen servers om te patchen, geen harde schijven
• 3:06
  Speaker 2: om te vervangen, geen backups om in te plannen. Microsoft
• 3:08
  Speaker 2: regelt dat allemaal. Je maakt gewoon een namespace aan, zet
• 3:10
  Speaker 2: je cues en topics op en begint berichten te versturen.
• 3:13
  Speaker 2: Het is serverless messaging. Je betaalt voor wat je gebruikt
• 3:15
  Speaker 2: en denkt nooit na over de hardware eronder. Dus, hoe
• 3:17
  Speaker 2: organiseert deze tussenpersoon de berichten? Het gebruikt twee hoofdstructuren, cues
• 3:21
  Speaker 2: en topics. Laten we beginnen met de eenvoudigste. Anatomie van
• 3:24
  Speaker 2: een bericht. We hebben de structuren behandeld. Laten we het
• 3:27
  Speaker 2: nu hebben over wat er daadwerkelijk doorheen reist. Het bericht zelf.
• 3:32
  Speaker 2: Zie een bericht in Azure Service Bus als een container
• 3:34
  Speaker 2: met twee hoofdonderdelen, de body en de metadata. De body
• 3:38
  Speaker 2: is je eigenlijke data, hetgeen wat je probeert te versturen.
• 3:41
  Speaker 2: Dit is meestal geformateerd als JSON of XML. Platte tekst
• 3:44
  Speaker 2: werkt ook en binaire data wordt ondersteund, maar in de
• 3:47
  Speaker 2: praktijk is JSON het meest gangbare formaat. Het is leesbaar
• 3:49
  Speaker 2: voor mensen, gemakkelijk om mee te werken en elke programmeertouw
• 3:52
  Speaker 2: kan ermee overweg. De metadata is waar het interessant wordt.
• 3:54
  Speaker 2: Elk bericht bevat een zet systeemeigenschappen die Service Bus automatisch toewijst.
• 3:59
  Speaker 2: Dingen zoals een uniek bericht-id, een tijdstempel die aangeeft wanneer
• 4:01
  Speaker 2: het bericht in de wachtrij is geplaatst en een volgnummer
• 4:03
  Speaker 2: dat de positie in de wachtrij aangeeft. Deze worden door
• 4:06
  Speaker 2: het systeem beheerd. Jij stelt ze niet in, ze zijn
• 4:08
  Speaker 2: er gewoon. Maar je kunt ook je eigen aangepaste eigenschappen toevoegen.
• 4:11
  Speaker 2: Dit zijn sleutelwaardeparen die je zelf definieert, zoals klantregio met
• 4:15
  Speaker 2: een waarde van Europa of order totaal met een waarde
• 4:17
  Speaker 2: van 29.999 of prioriteit met een waarde van hoog. Deze
• 4:21
  Speaker 2: aangepaste eigenschappen zijn cruciaal voor het filteren in onderwerp. Herinner
• 4:25
  Speaker 2: je je die abonnementsfilters nog waar we het over hadden?
• 4:27
  Speaker 2: Ze werken door deze aangepaste eigenschappen te matchen. Je stelt
• 4:30
  Speaker 2: het filter in dat zegt, ontvang alleen berichten waarbij de
• 4:32
  Speaker 2: klantregio gelijk is aan Europa. En het abonnement gebruikt de
• 4:35
  Speaker 2: aangepaste eigenschap om te beslissen of het bericht wordt geaccepteerd.
• 4:38
  Speaker 2: Er gelden limieten voor de berichtgrootte. In de standaardlaag kan
• 4:41
  Speaker 2: een bericht maximaal 256 kilobyte groot zijn. Dat is voldoende
• 4:44
  Speaker 2: voor de meeste bedrijfsgegevens, een orderrecord, een klantprofiel, een betalingsbevestiging,
• 4:48
  Speaker 2: allemaal ruim onder die limiet. Als je meer nodig hebt,
• 4:50
  Speaker 2: ondersteunt de premiumlaag berichten tot 1 megabyte. Maar als je
• 4:53
  Speaker 2: regelmatig gegevens verstuurt die groter zijn dan dat, moet je
• 4:55
  Speaker 2: ze waarschijnlijk niet in een bericht stoppen. Sla de grote
• 4:57
  Speaker 2: gegevens ergens anders op en zet een verwijzing in het bericht.
• 5:00
  Speaker 2: Dat is het gangbare patroon. Geplande bezorging is een nuttige functie.
• 5:03
  Speaker 2: Je verstuurt nu een bericht, maar vertelt Servicebus om het
• 5:05
  Speaker 2: pas op een specifiek tijdstip in de toekomst zichtbaar te maken.
• 5:08
  Speaker 2: Stel je voor dat je over 24 uur een herinneringsmail
• 5:10
  Speaker 2: wilt sturen. Je verstuurt het bericht nu met een geplande
• 5:12
  Speaker 2: wachtrijtijd ingesteld op morgen. Servicebus houdt het vast, het blijft onzichtbaar,
• 5:16
  Speaker 2: niemand kan het lezen. Vervolgens verschijnt het op het exacte
• 5:18
  Speaker 2: geplande tijdstip in de wachtrij alsof het zojuist is verzonden.
• 5:21
  Speaker 2: Dit is perfect voor tijdsgebonden workflows, herinneringen, time-outs en vertraagde verwerking.
• 5:25
  Speaker 2: De levenscyclus van een bericht verloopt als volgt. Eerst wordt
• 5:27
  Speaker 2: het naar de wachtrij of het onderwerp verzonden. Servicebus slaat
• 5:30
  Speaker 2: het duurzaam op, geschreven naar drievoudig redundante opslag. Vervolgens vraagt
• 5:33
  Speaker 2: een ontvanger om een bericht. Servicebus vergrendelt het, zodat geen
• 5:36
  Speaker 2: enkele andere ontvanger het kan pakken. De ontvanger verwerkt het bericht.
• 5:39
  Speaker 2: Als alles goed gaat, roept de ontvanger Complete aan. Servicebus
• 5:42
  Speaker 2: verwijdert het bericht. Als er iets misgaat, kan de ontvanger
• 5:45
  Speaker 2: Abandon aanroepen. De vergrendeling wordt vrijgegeven en het bericht gaat
• 5:48
  Speaker 2: terug naar de wachtrij voor een nieuwe poging. Als het
• 5:49
  Speaker 2: bericht blijft falen, wordt het uiteindelijk verplaatst naar de Dead
• 5:52
  Speaker 2: Letter wachtrij. Daar gaan we het nu over hebben. Het
• 5:54
  Speaker 2: belangrijkste is, berichten zijn duurzaam. Ze verdwijnen niet als een
• 5:57
  Speaker 2: ontvanger crash. Ze gaan niet verloren als het netwerk uitvalt.
• 6:00
  Speaker 2: Ze blijven in servicebus, veilig opgeslagen, totdat ze succesvol zijn
• 6:03
  Speaker 2: verwerkt of expliciet zijn verplaatst naar de dead letter wachtrij.
• 6:05
  Speaker 2: Die betrouwbaarheid is precies de reden om überhaupt een message
• 6:08
  Speaker 2: broker te gebruiken. Geavanceerde functies die het verschil maken. Laten
• 6:12
  Speaker 2: we nu praten over de functies die van een eenvoudige
• 6:14
  Speaker 2: berichtenwachtrij een platform maken waar je op kunt vertrouwen, te
• 6:16
  Speaker 2: beginnen met de dead letter wachtrij. We noemden eerder al
• 6:19
  Speaker 2: dat berichten die blijven falen uiteindelijk ergens anders naartoe worden verplaatst.
• 6:22
  Speaker 2: Die andere plek is de dead letter Q. Zie het
• 6:25
  Speaker 2: als een wachtruimte. Wanneer een bericht het maximaal aantal bezorgpogingen
• 6:28
  Speaker 2: overschrijdt of verloopt omdat de time to live is verstreken,
• 6:30
  Speaker 2: verdwijnt het niet zomaar. Het wordt verplaatst naar een aparte
• 6:32
  Speaker 2: subwachtrij binnen dezelfde wachtrij of hetzelfde abonnement. Je kunt die
• 6:36
  Speaker 2: berichten inspecteren, achterhalen wat er misging en beslissen wat je doet.
• 6:39
  Speaker 2: Misschien was de data onjuist en moet je dit corrigeren.
• 6:41
  Speaker 2: Misschien bevat de verwerkingslogica een fout. Misschien was het downstream
• 6:44
  Speaker 2: systeem offline en wil je het later opnieuw proberen. De
• 6:46
  Speaker 2: dead letter queue biedt je een backup plan. Niets gaat
• 6:49
  Speaker 2: stilletjes verloren. Laten we nu een veel voorkomend misverstand over
• 6:52
  Speaker 2: sessies ophelderen. Standaard garandeert Azure Service Bus niet dat berichten
• 6:55
  Speaker 2: in volgorde worden verwerkt. Ik weet dat we zeiden dat
• 6:58
  Speaker 2: wachtrijen FIFO zijn, first in first out, en dat klopt
• 7:00
  Speaker 2: voor hoe berichten aankomen, maar de verwerkingsvolgorde is een ander verhaal.
• 7:03
  Speaker 2: Als je meerdere consumenten hebt die uit dezelfde wachtrij trekken
• 7:06
  Speaker 2: en het ene bericht kost meer tijd om te verwerken
• 7:08
  Speaker 2: dan het andere, kan het tweede bericht eerder klaar zijn
• 7:10
  Speaker 2: dan het eerste. De volgorde gaat verloren. Sessies lossen dit op.
• 7:13
  Speaker 2: Een sessie groepeert gerelateerde berichten bij elkaar. Je wijst een
• 7:16
  Speaker 2: sessie-id toe aan elk bericht, zoals een klantordernummer of een workflow-instantie-id.
• 7:20
  Speaker 2: Alle berichten met dezelfde sessie-id worden door dezelfde consument verwerkt,
• 7:24
  Speaker 2: één voor één, op volgorde. Geen enkele andere consument kan
• 7:27
  Speaker 2: ze aanraken. Dit geeft je strikte FIFO-verwerking binnen die sessie.
• 7:30
  Speaker 2: Verschillende sessies kunnen nog steeds parallel door verschillende consumenten worden verwerkt.
• 7:34
  Speaker 2: Zo behoud je je doorvoer terwijl de volgorde gewaarborgd blijft
• 7:36
  Speaker 2: waar dat nodig is. Dubbele detectie is een andere geweldige functie.
• 7:39
  Speaker 2: Soms hapert het netwerk. Je applicatie verstuurt een bericht, maar
• 7:42
  Speaker 2: het antwoord gaat verloren. Dus stuurt je app het opnieuw
• 7:44
  Speaker 2: in de veronderstelling dat het eerste nooit is aangekomen. Zonder
• 7:47
  Speaker 2: dubbele detectie wordt dat bericht twee keer verwerkt. Met deze
• 7:50
  Speaker 2: functie onthoudt Servicebus de bericht-ID gedurende een configureerbaar venster, meestal
• 7:54
  Speaker 2: tot 30 dagen. Als het dezelfde bericht-ID opnieuw ziet, wordt
• 7:57
  Speaker 2: de dubbele invoer stilletjes verwijderd. De ontvanger weet nooit dat
• 8:00
  Speaker 2: er een herhaling was. Met transacties kun je meerdere operaties
• 8:03
  Speaker 2: groeperen tot één atomische eenheid. Misschien moet je een bericht
• 8:05
  Speaker 2: uit een wachtrij halen? Verwerken en het resultaat naar een
• 8:07
  Speaker 2: andere wachtrij sturen. Als een stap mislukt, wil je dat
• 8:10
  Speaker 2: alles terugdraait. Het bericht gaat terug naar de eerste wachtrij.
• 8:13
  Speaker 2: Het resultaat wordt nooit verzonden. Alles blijft consistent. Dit is
• 8:16
  Speaker 2: cruciaal voor financiële systemen waar gedeeltelijke verwerking erger is dan
• 8:19
  Speaker 2: helemaal geen verwerking. Met automatisch doorsturen kun je wachtrijen aan
• 8:22
  Speaker 2: elkaar koppelen. Berichten komen aan in de ene wachtrij en
• 8:24
  Speaker 2: worden automatisch doorgestuurd naar een andere. Dit is handig voor
• 8:26
  Speaker 2: het bouwen van verwerkingspijplijnen. Een onbewerkt bericht komt binnen, wordt
• 8:29
  Speaker 2: gevalideerd en vervolgens doorgestuurd naar een andere wachtrij voor het
• 8:31
  Speaker 2: eigenlijke werk. De eerste wachtrij blijft schoon. De tweede wachtrij
• 8:34
  Speaker 2: verwerkt het zware werk. En uitstel stelt je in staat
• 8:37
  Speaker 2: een bericht tijdelijk over te slaan. Misschien ontvang je een bericht,
• 8:39
  Speaker 2: maar zijn de gegevens waarnaar het verwijst nog niet klaar.
• 8:41
  Speaker 2: Je kunt het uitstellen. Het blijft in de wachtrij staan,
• 8:44
  Speaker 2: maar is onzichtbaar. Later kun je het met het volgnummer
• 8:46
  Speaker 2: ophalen en verwerken wanneer de tijd rijp is. Deze functies
• 8:49
  Speaker 2: onderscheiden een eenvoudige wachtrij van een systeem waarop je je
• 8:51
  Speaker 2: bedrijf kunt bouwen. Servicebus vergeleken met de alternatieven. Dus, wanneer
• 8:55
  Speaker 2: kies je voor Servicebus in plaats van iets anders? Ik
• 8:58
  Speaker 2: zal het uiteenzetten. Azure Storage Queues zijn de eenvoudigste optie, goedkoop,
• 9:02
  Speaker 2: snel en makkelijk in te stellen. Maar ze zijn beperkt.
• 9:04
  Speaker 2: Berichten hebben een limiet van 64 kilobyte en je hebt
• 9:07
  Speaker 2: geen topics, sessies, dead lettering of transacties. Ze zijn geweldig
• 9:11
  Speaker 2: voor eenvoudige achtergrond taken waarbij je werk wilt ontlasten, maar
• 9:14
  Speaker 2: als je een van de geavanceerde functies nodig hebt die
• 9:17
  Speaker 2: we bespraken, ontgroei je ze snel. Event Hubs is gebouwd
• 9:20
  Speaker 2: voor iets heel anders, event streaming met een hoge doorvoer.
• 9:23
  Speaker 2: Denk aan miljoenen gebeurtenissen per seconde van IoT apparaten of applicatielog.
• 9:27
  Speaker 2: Het is geen message broker, het is een data-innamepijplijn. Je
• 9:30
  Speaker 2: zou het dus niet gebruiken voor transactionele workflows. Je gebruikt
• 9:33
  Speaker 2: het wanneer je enorme datastromen moet vastleggen en verwerken. EventGrid
• 9:37
  Speaker 2: is de lichtgewicht optie, een pub-subsysteem voor event-driven triggers. Wanneer
• 9:41
  Speaker 2: een blog wordt geüpload naar opslag, kan EventGrid een Azure-function activeren.
• 9:45
  Speaker 2: Wanneer een resource wordt aangemaakt, kan het andere services op
• 9:47
  Speaker 2: de hoogte stellen. Het is snel, goedkoop en perfect voor
• 9:49
  Speaker 2: reactieve scenario's, maar het is geen wachtrij. Het bewaart geen
• 9:52
  Speaker 2: berichten voor latere verwerking, dus als de ontvanger offline is,
• 9:55
  Speaker 2: gaat de gebeurtenis verloren. Nu, Servicebus zit daar precies tussenin.
• 9:58
  Speaker 2: Het heeft de rijke functies van een end-to-end. broker zonder
• 10:01
  Speaker 2: de complexiteit van het beheer ervan. Als je dead letter wachtrijen, sessies, transacties,
• 10:05
  Speaker 2: topics met filters of gegarandeerde aflevering nodig hebt, is Servicebus
• 10:08
  Speaker 2: de juiste keuze. Hoe zit het met Kafka? Dat is
• 10:10
  Speaker 2: een heel ander gesprek. Servicebus is voor commando's en bedrijfsworkflows,
• 10:14
  Speaker 2: terwijl Kafka voor event streaming en analytics is. Veel grote
• 10:17
  Speaker 2: systemen gebruiken beide. Servicebus regelt de operationele berichtgeving. Kafka regelt
• 10:21
  Speaker 2: de datapipelijn. Ze zijn complementair, niet concurrerend. Hier is een
• 10:24
  Speaker 2: eenvoudige vuistregel. Als je vraagt, is dit bericht correct verwerkt?
• 10:28
  Speaker 2: Gebruik dan Servicebus. Als je vraagt, kan ik de stroom
• 10:31
  Speaker 2: gebeurtenissen van vorige week opnieuw afspelen? Gebruik dan Kafka. Verschillende
• 10:34
  Speaker 2: tools voor verschillende taken. Gebruik scenario's uit de praktijk. Laten
• 10:38
  Speaker 2: we dit concreet maken met wat voorbeelden. Zo werkt Servicebus
• 10:40
  Speaker 2: in de productieomgeving. Beginnen bij e-commerce. Een klant plaatst een
• 10:43
  Speaker 2: bestelling op een website. De webserver neemt de bestelling aan,
• 10:46
  Speaker 2: plaatst direct één bericht in een Servicebus wachtrij en zegt
• 10:49
  Speaker 2: tegen de klant, bedankt, uw bestelling is bevestigd. De klant
• 10:52
  Speaker 2: krijgt snel antwoord zonder te wachten. Op de achtergrond haalt
• 10:55
  Speaker 2: een groep werkservices berichten uit die wachtrij. De ene verwerkt
• 10:58
  Speaker 2: de betaling, de andere controleert de voorraad en weer een
• 11:00
  Speaker 2: andere maakt het verzendlabel aan. Elke worker pakt het volgende bericht,
• 11:04
  Speaker 2: doet zijn werk en gaat door. De klant ziet daar
• 11:06
  Speaker 2: helemaal niets van. Zij zien alleen de bevestiging. Dat is
• 11:09
  Speaker 2: het klassieke asynchrone verwerkingspatroon. Directe feedback voor de gebruiker, zwaar
• 11:13
  Speaker 2: werk op de achtergrond. Financiële systemen gaan nog een stap verder.
• 11:16
  Speaker 2: Betalingsverwerking vereist gegarandeerde aflevering. Je mag geen transactie verliezen of
• 11:20
  Speaker 2: dubbel verwerken. Je hebt volgordelijkheid en transacties nodig. Servicebus biedt
• 11:23
  Speaker 2: je dat allemaal. Een betaling komt binnen, wordt verwerkt en
• 11:26
  Speaker 2: het resultaat gaat naar een andere wachtrij. Als er iets misgaat,
• 11:29
  Speaker 2: wordt alles teruggedraaid, zodat geld nooit onterecht verplaatst wordt. Dit
• 11:32
  Speaker 2: is waar Servicebus uitblinkt. Niet alleen data verplaatsen, maar het
• 11:36
  Speaker 2: veilig doen. Denk nu eens aan Multiservice Fanout. Een nieuwe
• 11:39
  Speaker 2: klant registreert zich op je platform. Je wilt dat het
• 11:41
  Speaker 2: CRM systeem het weet, het marketing systeem een welkomstmail stuurt
• 11:43
  Speaker 2: en het support team een ticket aanmaakt. In plaats van
• 11:45
  Speaker 2: drie verschillende services aan te roepen, plaats je één bericht
• 11:48
  Speaker 2: op een onderwerp genaamd klant geregistreerd. Elke service heeft zijn
• 11:51
  Speaker 2: eigen abonnement. Het CRM abonnement ontvangt elk bericht. Het marketing
• 11:55
  Speaker 2: abonnement filtert alleen op nieuwe klanten. Het support abonnement filtert
• 11:58
  Speaker 2: alleen op premium klanten. Eén bericht. 3 reacties. En als
• 12:01
  Speaker 2: je later een vierde service toevoegt, maak je gewoon een
• 12:03
  Speaker 2: nieuw abonnement aan. De afzender verandert nooit. Logistieke bedrijven gebruiken
• 12:07
  Speaker 2: dit op enorme schaal. Stel je een pakketvolgsysteem voor waar
• 12:10
  Speaker 2: honderdduizenden bezorgwagens elke paar seconden locatie-updates sturen. Elke update is
• 12:14
  Speaker 2: een bericht en de updates van elk pakket moeten op
• 12:16
  Speaker 2: volgorde worden verwerkt. Je kunt de bezorgd update niet verwerken
• 12:19
  Speaker 2: voor de onderweg update. Sessies regelen dit. Elk pakket krijgt
• 12:23
  Speaker 2: een eigen sessie-ID en alle updates voor dat pakket verlopen
• 12:25
  Speaker 2: in volgorde via dezelfde sessie. Verschillende pakketten kunnen nog steeds
• 12:29
  Speaker 2: parallel worden verwerkt. Miljoenen pakketten, miljarden updates, allemaal betrouwbaar afgehandeld.
• 12:33
  Speaker 2: Microservices-architecturen gebruiken Servicebus als hun communicatieruggegraat. Services roepen elkaar niet
• 12:39
  Speaker 2: rechtstreeks aan. Ze wisselen berichten uit. Service A stuurt een
• 12:42
  Speaker 2: opdracht naar een wachtrij, Service B pakt deze op en
• 12:45
  Speaker 2: voert het werk uit. Service C publiceert een event naar
• 12:47
  Speaker 2: een topic en Services D en E reageren elk op
• 12:50
  Speaker 2: hun eigen manier. Geen directe aanroepen, geen sterke koppeling. Elke
• 12:53
  Speaker 2: service kan worden bijgewerkt, geschaald of vervangen zonder de anderen
• 12:56
  Speaker 2: te beïnvloeden. En hier is een patroon dat je bij
• 12:58
  Speaker 2: oudere bedrijven ziet. Ze hebben een legacy systeem on-premises draaien
• 13:01
  Speaker 2: dat niet makkelijk te vervangen is, maar ze willen moderne
• 13:02
  Speaker 2: cloud services gebruiken. Dus overbruggen ze de kloof met Servicebus.
• 13:06
  Speaker 2: Het legacy systeem stuurt berichten naar een wachtrij en cloud
• 13:08
  Speaker 2: applicaties verwerken deze. Het oude systeem weet nooit dat het
• 13:11
  Speaker 2: met de cloud praat en de cloud weet nooit dat
• 13:13
  Speaker 2: hij met een oud systeem praat. Servicebus zit in het
• 13:15
  Speaker 2: midden te vertalen en door te sturen. Geplande aflevering regelt
• 13:18
  Speaker 2: de tijdsgebonden taken. Stuur een herinneringsmail over 24 uur. Laat
• 13:22
  Speaker 2: deze reservering over 30 minuten verlopen als deze niet is bevestigd.
• 13:25
  Speaker 2: Genereer elke maandag om 8 uur zochtens een weekrapport. Je
• 13:28
  Speaker 2: verstuurt het bericht nu met een toekomstige bezorgdheid en Servicebus
• 13:31
  Speaker 2: houdt het vast en geeft het precies op het juiste
• 13:32
  Speaker 2: moment vrij. Geen cronjobs, geen achtergrondtimers, alleen een bericht met
• 13:36
  Speaker 2: een timer. De rode draad in al deze voorbeelden is hetzelfde.
• 13:39
  Speaker 2: De zender wacht niet op de ontvanger en de ontvanger
• 13:41
  Speaker 2: hoeft niet online te zijn wanneer het bericht wordt verstuurd.
• 13:44
  Speaker 2: Ze zijn ontkoppeld en die ontkoppeling maakt het hele systeem veerkrachtiger...
• 13:47
  Speaker 2: schaalbaarder en makkelijker aan te passen. Het grote plaatje waarom
• 13:51
  Speaker 2: het allemaal samenkomt. Dus, wat is Service Bus precies? Het
• 13:54
  Speaker 2: is de ruggengraat die onafhankelijke services betrouwbaar laat communiceren zonder
• 13:57
  Speaker 2: van elkaar afhankelijk te zijn. Drie woorden vatten het samen ontkoppelen,
• 14:00
  Speaker 2: bufferen en routeren. Ontkoppelen betekent dat services niet van elkaar
• 14:04
  Speaker 2: hoeven te weten. Ze weten alleen van de wachtrij of
• 14:06
  Speaker 2: het tabak. Dat betekent dat je één service kunt wijzigen
• 14:09
  Speaker 2: zonder de andere te breken, één kunt schalen zonder de
• 14:11
  Speaker 2: rest te beïnvloeden en updates kunt implementeren terwijl de rest
• 14:13
  Speaker 2: blijft draaien. Bufferen betekent dat de wachtrij de belasting opvangt
• 14:16
  Speaker 2: bij piekverkeer. De zender blijft op volle snelheid sturen terwijl
• 14:20
  Speaker 2: de ontvanger op eigen tempo verwerkt, dus niemand crasht of
• 14:23
  Speaker 2: raakt over belast en de buffer vlakt de pieken af
• 14:25
  Speaker 2: en vult de dalen. Routeren betekent dat wachtrijen berichten naar
• 14:28
  Speaker 2: één ontvanger sturen terwijl topics naar velen uitzenden, en filters
• 14:31
  Speaker 2: zorgen dat elke ontvanger alleen krijgt wat nodig is, zodat
• 14:34
  Speaker 2: het bericht automatisch de juiste plek vindt. Wachtrijen regelen de
• 14:37
  Speaker 2: verdeling van werk van punt naar punt en topics regelen
• 14:39
  Speaker 2: de uitzending naar vele ontvangers. Geavanceerde functies behandelen de uitzonderingsgevallen.
• 14:44
  Speaker 2: Fouten gaan naar de dead letter wachtrij, gebruikersessies ordenen, duplicaten
• 14:48
  Speaker 2: worden gedetecteerd, transacties houden alles consistent en