Latest / M365.FM – Microsoft 365, Copilot & AI podcast in het Nederlands / API-gateway uitgelegd: routing, beveiliging en rate limiting voor microservices – heb je er een nodig? (AI-nasynchronisatie)

Transcript

API-gateway uitgelegd: routing, beveiliging en rate limiting voor microservices – heb je er een nodig? (AI-nasynchronisatie) · M365.FM – Microsoft 365, Copilot & AI podcast in het Nederlands

• 0:00
  Klaar voor 10 dagen Microsoft 365, Copilot, AI, Azure en de mensen die de toekomst van werk vormgeven?
• 0:07
  Deze januari is M365, kom terug en we pakken groter uit.
• 0:12
  Doe mee voor live sessies, praktijkdemos en praktische kennis van MVP's en experts uit de hele wereld.
• 0:18
  Geen algemene dia's, geen eindeloos jargon.
• 0:21
  We pakken de echte uitdagingen aan Copilot Studio, AI Agents, Fabric, Beveiliging, Governance en Automatisering.
• 0:28
  Automatisering. Of je nu een IT-professional, ontwikkelaar of zakelijk leider bent, er zijn sessies speciaal voor jou.
• 0:35
  Met 10 volle dagen kun je diverse technologieën verkennen en in contact komen met een wereldwijde community.
• 0:40
  Kijk live mee en neem praktische inzichten mee terug naar je organisatie.
• 0:44
  Januari 2027, 10 dagen, 1 Microsoft Community.
• 0:49
  De registratie is nu geopend.
• 0:51
  Ga naar M365.com.net en verzeker je vandaag nog van een plek.
• 0:55
  Dat is M365.com.net.
• 1:00
  Meld je nu aan op M365.com.net en we zien je live in januari.
• 1:05
  Je hebt een app gebouwd die werkt, dan voeg je een andere service toe en nog een...
• 1:08
  ...en plotseling wordt het verkeer daartussen een nachtmerrie.
• 1:11
  Dus, wat is nu precies een API Gateway en heb je er echt een nodig?
• 1:14
  Aan het einde van deze aflevering begrijp je wat een API Gateway doet,
• 1:18
  waarom het de chaos van het beheren van meerdere services oplost en hoe je weet of je er een nodig hebt.
• 1:22
  Laten we beginnen met het probleem, dan de onderdelen en vervolgens hoe alles samenkomt.
• 1:27
  Het probleem, te veel deuren.
• 1:29
  Stel je voor dat je een bedrijf runt dat snel groeit.
• 1:32
  Je hebt een salesteam op de derde verdieping, de boekhouding in de kelder en IT in de achtervleugel.
• 1:37
  Stel je nu voor dat elk van die afdelingen zijn eigen voordeur, eigen telefoonnummer en eigen beveiliger heeft die niet met de andere praat.
• 1:43
  Als je een bezoeker bent die een pakketje wil afleveren, veel succes.
• 1:46
  Je moet precies weten welke deur je moet gebruiken, welke beveiliger je moet spreken en wat je moet doen als die beveiliger pauze heeft.
• 1:51
  Dat is precies wat er gebeurt wanneer je app meerdere back-end services heeft en elke client zijn rechtstreeks aanroept.
• 1:56
  De client, of het nu een mobiele app, een website of een andere service is, moet weten waar elke service zich bevindt, hoe je bij elk moet verifiëren en wat je moet doen als er iets misgaat.
• 2:04
  Elke afzonderlijke service moet zijn eigen beveiliging, eigen rate limiting en eigen foutafhandeling afhandelen.
• 2:09
  Dat is dubbel werk en het is makkelijk voor zaken om inconsistent te worden.
• 2:12
  Neem bijvoorbeeld een bank.
• 2:13
  Zij hebben aparte services voor rekeningen, betalingen, leningen en fraudedetectie.
• 2:17
  Op de oude manier wordt elk daarvan rechtstreeks blootgesteld.
• 2:19
  Een mobiele app moet vier verschillende URL's, vier verschillende authenticatie methoden en vier verschillende manieren voor foutafhandeling kennen.
• 2:25
  Dat is vier keer de complexiteit en vier keer zoveel kans dat er iets misgaat en dat is de chaos die een API Gateway moet oplossen.
• 2:32
  Dus, wat is de oplossing?
• 2:34
  Wat is een API Gateway?
• 2:35
  Zie een API Gateway voor je als de receptie van een hotel.
• 2:38
  Wanneer je binnenkomt, hoef je niet te weten op welke verdieping de schoonmaak is, waar de keuken is of hoe je de onderhoudsdienst bereikt.
• 2:44
  Je loopt gewoon naar de receptie, vertelt wat je nodig hebt en zij regelen de rest.
• 2:48
  Ze sturen je verzoek door naar de juiste persoon, controleren of je daar mag zijn en handelen eenvoudige verzoeken zelf af.
• 2:54
  Een API Gateway doet hetzelfde voor je software.
• 2:57
  Het is één enkel toegangspunt dat tussen je clients en je back-end services staat.
• 3:01
  Elk verzoek gaat eerst door de Gateway.
• 3:03
  Deze beslist waar het heen gaat, of het is toegestaan en wat er wordt teruggestuurd.
• 3:07
  Dit is overigens geen nieuw idee.
• 3:09
  Reverse proxies bestaan al decennia, maar de API Gateway is essentieel geworden met microservices.
• 3:13
  Wanneer je je app opdeelt in veel kleine services, heb je plotseling veel deuren.
• 3:17
  De Gateway geeft je één voordeur.
• 3:19
  In de Azure wereld is Azure API Management het volledige platform en de Gateway de kerncomponent die het verkeer afhandelt.
• 3:24
  Maar het patroon is overal hetzelfde.
• 3:26
  Eén toegangspunt, gecentraliseerde controle.
• 3:29
  Elk verzoek komt binnen.
• 3:30
  De Gateway controleert het, routeert het en stuurt het antwoord terug.
• 3:33
  De client spreekt nooit rechtstreeks met je back-end services.
• 3:36
  Deze praat alleen met de Gateway.
• 3:37
  Laten we eens kijken wat dat precies betekent.
• 3:39
  Beginnend bij de meest basale taak, routing.
• 3:42
  Deel 1. Verkeer routeren.
• 3:44
  De eenvoudigste taak van een API Gateway is routing.
• 3:47
  Elk verzoek naar de juiste service sturen.
• 3:49
  Denk eens na over hoe een website werkt.
• 3:51
  Wanneer je op een link klikt, verstuurt je browser een verzoek.
• 3:53
  Dat verzoek bevat een pad.
• 3:54
  Als het pad Users is, weet de Gateway dat het naar de gebruikerservice moet.
• 3:57
  Als het Orders is, gaat het naar de bestelservice.
• 4:00
  De Gateway leest het pad, bepaalt waar het heen moet en stuurt het door.
• 4:03
  Zonder Gateway moeten je clients elke individuele service URL kennen.
• 4:06
  De mobiele app heeft het adres nodig van de gebruikerservice, de bestelservice, de betaalservice en de katalogerservice.
• 4:12
  Dat is een heleboel URL's om te beheren.
• 4:14
  En als een van die adressen verandert, moet je elke client bijwerken.
• 4:17
  Met een Gateway kennen clients slechts één URL.
• 4:19
  Het adres van de Gateway.
• 4:20
  Het maakt ze niet uit waar de services zich daadwerkelijk bevinden.
• 4:23
  Ze sturen hun verzoek simpelweg naar de Gateway en die regelt de rest.
• 4:26
  Dit is een van de meest voorkomende API Gateway toepassingen, resource gebaseerde routing.
• 4:30
  Het onderzoek naar Apache API SIX benoemt dit expliciet.
• 4:32
  Je routeert op basis van het pad, de HTTP-methode, headers en zelfs de geolocatie van de client.
• 4:37
  Als iemand in Europa een verzoek stuurt, kun je die naar een Europees datacenter routeren.
• 4:41
  Als iemand in de VS een verzoek stuurt, gaan ze naar een Amerikaans datacenter.
• 4:44
  De client merkt helemaal niets van dit proces.
• 4:46
  Ze krijgen gewoon een snel antwoord.
• 4:48
  Routing regelt ook versiebeheer.
• 4:49
  Stel dat je een nieuwe versie van je gebruikerservice hebt.
• 4:52
  De oude clients gebruiken nog V1-users en de nieuwe clients gebruiken V2-users.
• 4:56
  De Gateway routeert ze naar verschillende backends.
• 4:58
  Oude clients blijven werken terwijl je de nieuwe versie uitrolt.
• 5:01
  Je kunt je back-end wijzigen zonder je clients te storen.
• 5:04
  Dat is erg belangrijk bij het beheren van een live applicatie met echte gebruikers.
• 5:07
  Denk aan een e-commerce platform.
• 5:09
  Je hebt aparte services voor de catalogus, het winkelwagentje, de checkout- en gebruikersaccounts.
• 5:13
  Zonder Gateway moet een mobiele app 4 verschillende URL's kennen.
• 5:17
  Met een Gateway kent de app er slechts één.
• 5:19
  De Gateway leest het pad, catalogus, winkelwagentje, checkout, account en stuurt elk verzoek naar de juiste service.
• 5:25
  Eenvoudige routing is het makkelijke deel.
• 5:27
  De volgende taak is waar het echt nuttig wordt.
• 5:29
  Deel 2. Beveiliging bij de voordeur.
• 5:31
  Elke API-aanroep moet worden gecontroleerd.
• 5:33
  Wie doet dit verzoek?
• 5:34
  Heeft diegene de juiste rechten?
• 5:36
  Zonder Gateway moet elke service zijn eigen authenticatie regelen.
• 5:39
  Dat betekent dubbel werk en het is makkelijk om fouten te maken.
• 5:42
  De ene service controleert tokens misschien goed, een andere slaat een stap over en weer een andere gebruikt een totaal andere methode.
• 5:48
  Zo krijg je inconsistente beveiliging in je hele applicatie.
• 5:51
  De Gateway verandert dat.
• 5:52
  Het regelt authenticatie en autorisatie op één centrale plek.
• 5:55
  Eén plek om te controleren, één plek om af te dwingen, één plek om bij te werken als beleid verandert.
• 5:59
  Dat is een belangrijke beveiligingsbestpractice.
• 6:01
  Het valideert API-sleutels, JWTs, OAuth tokens of certificaten bij elk individueel verzoek.
• 6:07
  Elk verzoek doorloopt dezelfde controle.
• 6:09
  Geen uitzonderingen.
• 6:10
  De Gateway kan ook regels afdwingen.
• 6:12
  Je kunt zeggen, deze API-sleutel mag alleen de leesendpoints aanroepen.
• 6:15
  Of deze client heeft alleen toegang tot de katalige service, niet tot de betalingsservice.
• 6:19
  Je definieert gedetailleerde rechten op Gateway-niveau en ze worden automatisch toegepast.
• 6:23
  Back-end-services hoeven zich nooit zorgen te maken over autorisatie.
• 6:26
  Ze verwerken simpelweg het verzoek en sturen de gegevens terug.
• 6:28
  Hier is het punt.
• 6:30
  De Gateway is de centrale plek om toegang in te trekken als er iets misgaat.
• 6:33
  Als de API-sleutel van een klant is gecompromitteerd, trek je deze in bij de Gateway.
• 6:36
  Een wijziging, klaar.
• 6:37
  Je hoeft geen enkele service bij te werken of iets opnieuw op te starten.
• 6:40
  Het volgende verzoek van die sleutel wordt direct afgewezen.
• 6:43
  Neem een concreet voorbeeld.
• 6:44
  Een bank heeft een betalingsservice en een facturatieservice.
• 6:46
  Alleen de betalingsservice heeft schrijftoegang nodig tot het facturatiesysteem.
• 6:49
  De Gateway blinkt dit af.
• 6:50
  Als een client via het verkeerde eindpunt naar het facturatiesysteem probeert te schrijven,
• 6:54
  blokkeert de Gateway dit.
• 6:55
  De facturatieservice ziet het verzoek niet is.
• 6:57
  De Gateway ondersteunt ook Mutual, TLS en WAF integratie voor diepere beveiliging.
• 7:02
  Maar in de kern is het je eerste verdedigingslinie.
• 7:04
  Beveiliging is één ding, maar wat als er te veel verzoeken tegelijk binnenkomen?
• 7:08
  Deel 3.
• 7:09
  Verkeersbeheer
• 7:10
  Wat gebeurt er als 10.000 gebruikers tegelijkertijd je app bezoeken?
• 7:14
  Misschien heb je een flitsverkoop, een virale productlancering,
• 7:17
  of is het een normale dinsdag en besluit iedereen tegelijk in te loggen.
• 7:20
  Zonder Gateway worden je back-end services direct bestookt en kunnen ze crashen.
• 7:24
  Niet langzaam, maar allemaal tegelijk.
• 7:26
  Dat is waar verkeersbeheer om de hoek komt kijken.
• 7:28
  De Gateway kan beperken hoeveel verzoeken elke client kan indienen.
• 7:32
  Rate limiting en throttling zijn standaard functies.
• 7:34
  Jij stelt de regels in bij de Gateway en deze dwingt ze af.
• 7:37
  Je back-end services merken niets van de piek.
• 7:39
  Je kunt quota instellen per gebruiker, per API-sleutel of per IP-adres.
• 7:43
  Stel dat je een gratis versie van je API hebt.
• 7:45
  Gratis gebruikers krijgen 100 verzoeken per uur.
• 7:47
  Premium gebruikers krijgen er 10.000.
• 7:48
  De Gateway volgt elk verzoek en dwingt de limieten af bij de poort.
• 7:52
  Een gratis gebruiker bereikt de limiet en de Gateway stuurt een beleefde melding om het later opnieuw te proberen.
• 7:56
  De back-end services weten niet eens dat er een verzoek was.
• 7:59
  Ze blijven rustig doorgaan met het bedienen van de betalende klanten.
• 8:02
  De Gateway regelt ook load balancing.
• 8:04
  Als je meerdere instanties van dezelfde service hebt draaien, verdeelt de Gateway de verzoeken daarover.
• 8:09
  Instantie 1 krijgt een verzoek, instantie 2 de volgende, instantie 3 de volgende.
• 8:12
  Het gaat automatisch.
• 8:14
  En als één instantie uitvalt, leidt de Gateway het verkeer om naar een andere.
• 8:16
  Klanten merken er niets van. Ze krijgen gewoon hun antwoord.
• 8:19
  Load balancing met gezondheidschecks houdt alles soepel draaiende.
• 8:22
  De Gateway pinkt elk instantie om er zeker van te zijn dat deze actief is.
• 8:25
  Als dat niet zo is, stopt het met het sturen van verkeer daarheen.
• 8:27
  Dit is vooral belangrijk voor APIs met veel verkeer.
• 8:30
  Zonder Gateway raakt een piek in het verkeer je services direct.
• 8:33
  Met de Gateway raakt de piek eerst de Gateway.
• 8:36
  Deze vangt het op, verspreidt het en beschermt je services tegenover belasting.
• 8:39
  Oké, maar wat als de data niet klopt wanneer deze aankomt?
• 8:44
  Deel 4, datatransformatie.
• 8:46
  Soms komt de data die je client verstuurt niet overeen met wat je bekend verwacht.
• 8:50
  Misschien verstuurt de client JSON, maar begrijpt je bekend alleen XML.
• 8:54
  Misschien komen de veldnamen niet overeen.
• 8:55
  De client gebruikt, first name, en je bekend verwacht, voornaam.
• 8:59
  Deze verschillen maken dingen kapot.
• 9:00
  Op de oude manier moest je elke client aanpassen of de bekend herschrijven.
• 9:04
  Niet ideaal.
• 9:05
  De Gateway kan de data transformeren voordat deze de bekend bereikt.
• 9:08
  Zie het als een vertaler.
• 9:09
  Hij zit in het midden en kan de data wijzigen bij binnenkomst, bij vertrek, of beide.
• 9:13
  Dat is verzoek en responstransformatie in een notendop.
• 9:15
  Laat me je een echt voorbeeld geven.
• 9:17
  Stel, je hebt een legacy systeem dat XML verwacht.
• 9:19
  Het draait al 15 jaar.
• 9:21
  Het werkt prima.
• 9:22
  Maar nu bouw je een nieuwe mobiele app.
• 9:23
  En mobiele apps spreken JSON.
• 9:25
  Zonder Gateway zou je het legacy systeem moeten herschrijven of de app dwingen XML te sturen.
• 9:29
  Met een Gateway hoef je geen van beide te doen.
• 9:31
  De mobiele app verstuurt JSON.
• 9:33
  De Gateway zet dit om naar XML.
• 9:34
  Het systeem ontvangt wat het verwacht.
• 9:36
  De mobiele app krijgt een antwoord terug, al in JSON.
• 9:39
  Niemand hoefde iets te herschrijven.
• 9:40
  Dat is het mooie ervan.
• 9:41
  De Gateway kan ook headers toevoegen of verwijderen, URL's wijzigen of gevoelige data maskeren.
• 9:46
  Stel je voor dat een antwoord een creditcardnummer bevat.
• 9:48
  Je wilt niet dat dit teruggaat naar de client.
• 9:50
  De Gateway kan het eruit filteren voordat het antwoord vertrekt, of het vervangen door een gmaskeerde versie.
• 9:54
  De bekend hoeft nooit te veranderen.
• 9:56
  De Gateway regelt het.
• 9:57
  Dit is vooral handig bij het moderniseren van oude systemen.
• 9:59
  Je hoeft de bekend niet te herschrijven.
• 10:01
  Je hoeft clients niet te dwingen tot wijzigingen.
• 10:03
  Je past alleen de Gateway aan.
• 10:04
  Het is als een talk op een internationale conferentie.
• 10:07
  Iedereen spreekt zijn eigen taal, maar de talk zorgt ervoor dat iedereen elkaar begrijpt.
• 10:10
  De Gateway is die talk voor je software.
• 10:12
  Dus, routering, beveiliging, throttling, transformatie, dat is een hoop.
• 10:15
  Maar het zijn geen vier losse dingen.
• 10:17
  Laat me zien hoe ze met elkaar verbonden zijn.
• 10:19
  Hoe alles samenkomt.
• 10:20
  Het zit zo.
• 10:21
  Deze vier taken staan niet op zichzelf.
• 10:23
  Ze werken samen bij elk verzoek, telkens wanneer er een verzoek binnenkomt.
• 10:26
  De Gateway controleert de authenticatie.
• 10:28
  Hij valideert de snelheidslimiet.
• 10:29
  Hij routeert naar de juiste service.
• 10:31
  Het transformeert de data indien nodig.
• 10:32
  Het ontvangt de respons terug.
• 10:34
  Het transformeert die ook indien nodig.
• 10:36
  Vervolgens stuurt het alles terug naar de client.
• 10:38
  Een pipeline.
• 10:38
  Elke stap gebeurt automatisch, op volgorde, zonder dat een service erover na hoeft te denken.
• 10:42
  De echte kracht is niet één specifieke functie.
• 10:44
  Het is de integratie.
• 10:46
  Je kunt een nieuw beveiligingsbeleid toevoegen zonder de routing aan te passen.
• 10:49
  De bekend service wijzigen zonder de client aan te passen.
• 10:52
  Je kunt de snelheidslimieten updaten zonder iets opnieuw te hoeven deployen.
• 10:54
  Elk onderdeel is onafhankelijk, maar ze werken allemaal in dezelfde pipeline.
• 10:58
  En omdat alles door één plek gaat, krijg je volledig inzicht in wat er gebeurt.
• 11:01
  Logs, statistieken, analytics, allemaal vanaf één punt.
• 11:05
  Je kunt zien hoeveel verzoeken er binnenkwamen, welke mislukten, welke traag waren, welke clients de meeste resources gebruiken.
• 11:10
  Zonder gateway zou je die data van elke service afzonderlijk moeten verzamelen.
• 11:13
  Met een gateway is het daar allemaal aanwezig.
• 11:15
  Dat is het grote inzicht.
• 11:16
  De gateway is niet zomaar een router.
• 11:18
  Het is een controlecentrum voor je volledige API-platform.
• 11:20
  Elk verzoek, elke respons, elke fout, alles stroomt door één plek.
• 11:24
  Je hebt één centraal overzicht voor alles wat er gebeurt.
• 11:26
  Dus, hoe gebruik je dit eigenlijk?
• 11:27
  Laten we bespreken wat je hier nu mee kunt doen.
• 11:30
  Praktische inzichten.
• 11:31
  Laten we eerlijk zijn.
• 11:32
  Als je één of twee services hebt, heb je waarschijnlijk nog geen API-gateway nodig.
• 11:35
  Je kunt de routing zelf afhandelen.
• 11:37
  Authenticatie beheren in elke service.
• 11:38
  Het is niet elegant, maar het werkt.
• 11:40
  Maar zodra je drie services hebt of APIs blootstelt aan externe clients, neemt de complexiteit snel toe.
• 11:45
  De gateway verdient zichzelf snel terug.
• 11:47
  Dus, wat is je beste eerste zet?
• 11:49
  Centraliseer authenticatie bij de gateway.
• 11:51
  Doe dat voor alles anders.
• 11:52
  Kies één service.
• 11:53
  Verplaats de authenticatie-check naar de gateway.
• 11:54
  Je zult direct merken dat je service code schoner wordt.
• 11:57
  Geen logica voor tokenvalidatie meer die overal verspreid staat.
• 12:00
  Niet meer afvragen of je het in elke service op dezelfde manier hebt geïmplementeerd.
• 12:03
  De gateway regelt het één keer en elke service profiteert ervan.
• 12:07
  Volgende stap.
• 12:07
  Rate limiting.
• 12:08
  Zelfs een simpele limiet beschermt je bekend tegenover belasting.
• 12:11
  Begin met iets bazaals, zoals 100 verzoeken per minuut per client.
• 12:14
  Dat voorkomt dat een op hol geslagen client je services platlegt.
• 12:16
  Je kunt praten.