Latest / M365.FM – Microsoft 365, Copilot & KI Podcast auf Deutsch / API-Gateway einfach erklärt: Routing, Sicherheit und Ratenbegrenzung für Microservices – brauchen Sie eines? (KI-Synchronfassung)

Transcript

API-Gateway einfach erklärt: Routing, Sicherheit und Ratenbegrenzung für Microservices – brauchen Sie eines? (KI-Synchronfassung) · M365.FM – Microsoft 365, Copilot & KI Podcast auf Deutsch

• 0:00
  Bereit für 10 Tage voller Microsoft 365, Co-Pilot, KI-Azure und den Menschen, die die Zukunft der Arbeit gestalten?
• 0:07
  Diesen Januar ist die M3 655-Con zurück und wir legen noch einen drauf.
• 0:12
  Seien Sie bei Live-Sessions, Praxis-Demos und Expertenwissen von MVPs und Branchenprofis aus aller Welt dabei.
• 0:18
  Keine generischen Folien. Kein endloses Buzzword-Bingo.
• 0:21
  Wir gehen die echten Herausforderungen an.
• 0:23
  Co-Pilot Studio, KI-Agenten, Fabric, Sicherheit, Governance und Automatisierung.
• 0:28
  Egal ob IT-Profi, Entwickler oder Führungskraft, es gibt Sessions, die speziell für Sie gemacht sind.
• 0:35
  An 10 vollen Tagen können Sie zahlreiche Technologien erkunden und sich mit einer globalen Community vernetzen.
• 0:40
  Schauen Sie live zu und nehmen Sie praktische Erkenntnisse mit in Ihr Unternehmen.
• 0:45
  Januar 2027. 10 Tage. Eine Microsoft-Community.
• 0:49
  Die Registrierung ist jetzt eröffnet.
• 0:51
  Gehen Sie auf m3 65.con.net und sichern Sie sich noch heute Ihren Platz.
• 0:55
  Das ist m3 65.con.net.
• 1:00
  Melden Sie sich jetzt unter m3 65.con.net an. Wir sehen uns live im Januar.
• 1:05
  Sie haben eine funktionierende App gebaut. Dann kommt ein Service hinzu, dann noch einer.
• 1:08
  Und plötzlich wird die Verkehrsleitung dazwischen zum Albtraum.
• 1:11
  Was genau ist also ein API-Gateway und brauchen Sie überhaupt eines?
• 1:14
  Am Ende dieser Folge werden Sie verstehen, was ein API-Gateway tut.
• 1:18
  Warum ist das Chaos bei der Verwaltung mehrerer Services löst und wie Sie wissen, ob Sie eines brauchen.
• 1:21
  Fangen wir mit dem Problem an. Dann den Komponenten und wie alles zusammenpasst.
• 1:27
  Das Problem. Zu viele Türen.
• 1:29
  Stellen Sie sich vor, Sie leiten ein schnell wachsendes Unternehmen.
• 1:32
  Sie haben ein Vertriebsteam im dritten Stock, die Buchhaltung im Keller und die IT im hinteren Flügel.
• 1:36
  Äh.
• 1:37
  Stellen Sie sich nun vor, jede dieser Abteilungen hat Ihre eigene Eingangstür, Ihre eigene Telefonnummer und einen eigenen Sicherheitsmann, der nicht mit den anderen spricht.
• 1:43
  Wenn Sie als Besucher ein Paket abgeben wollen, viel Glück.
• 1:45
  Sie müssen genau wissen, welche Tür Sie nehmen, mit welchem Wachmann Sie sprechen müssen und was zu tun ist, wenn der gerade Pause macht.
• 1:51
  Genau das passiert, wenn Ihre App mehrere Backend-Services hat und jeder Client jeden Einzelnen direkt anspricht.
• 1:56
  Der Client, egal ob Mobile, App, Website oder ein anderer Service, muss wissen, wo jeder Service zu finden ist, wie die Authentifizierung funktioniert und was bei Fehlern zu tun ist.
• 2:05
  Jeder einzelne Service muss sich um seine eigene Sicherheit, das Rate-Limiting und die Fehlerbehandlung kümmern.
• 2:09
  Das ist doppelte Arbeit und es führt leicht zu Inkonsistenzen.
• 2:12
  Nehmen wir eine Bank als Beispiel.
• 2:13
  Sie haben separate Services für Konten, Zahlungen, Kredite und Betrugserkennung.
• 2:17
  Nach alter Methode ist jeder Einzelnen direkt erreichbar.
• 2:19
  Eine mobile App muss vier verschiedene URLs, vier verschiedene Authentifizierungsmethoden und vier verschiedene Arten der Fehlerbehandlung kennen.
• 2:25
  Das bedeutet vierfache Komplexität und vierfache Angriffsfläche für Fehler.
• 2:29
  Genau das Chaos, das ein API-Gateway beheben soll.
• 2:32
  Was ist also die Lösung?
• 2:33
  Was ist ein API-Gateway?
• 2:35
  Stellen Sie sich ein API-Gateway wie die Rezeption eines Hotels vor.
• 2:37
  Wenn Sie reinkommen, müssen Sie nicht wissen, auf welcher Etage der Zimmerservice ist, wo die Küche ist oder wie man den Wartungsdienst erreicht.
• 2:44
  Sie gehen einfach zur Rezeption, sagen, was Sie brauchen und die kümmern sich um den Rest.
• 2:48
  Sie leiten Ihre Anfrage an die richtige Person weiter, prüfen, ob Sie dort sein dürfen und erledigen einfache Anfragen sogar selbst.
• 2:54
  Ein API-Gateway macht das Gleiche für Ihre Software.
• 2:57
  Es ist ein zentraler Einstiegspunkt, der zwischen Ihren Clients und Ihren Backenddiensten liegt.
• 3:00
  Jede Anfrage läuft zuerst durch das Gateway.
• 3:03
  Es entscheidet, wohin sie geleitet wird, ob sie erlaubt ist und was zurückgeschickt wird.
• 3:07
  Das ist keine neue Idee.
• 3:09
  Reverse-Proxies gibt es schon seit Jahrzehnten.
• 3:11
  Aber das API-Gateway ist bei Microservices unverzichtbar geworden.
• 3:14
  Wenn Sie Ihre App in viele kleine Dienste aufteilen, haben Sie plötzlich viele Türen.
• 3:17
  Das Gateway bietet Ihnen eine einzige Fördertür.
• 3:19
  In der Azure-Welt ist Azure API Management die vollständige Plattform.
• 3:22
  Und das Gateway ist die Kernkomponente, die den Datenverkehr steuert.
• 3:25
  Aber das Prinzip ist überall gleich.
• 3:26
  Ein Einstiegspunkt, zentrale Kontrolle.
• 3:28
  Jede Anfrage kommt herein.
• 3:29
  Das Gateway prüft Sie, leitet Sie weiter und sendet die Antwort zurück.
• 3:33
  Der Client kommuniziert nie direkt mit Ihren Backenddiensten.
• 3:35
  Er kommuniziert nur mit dem Gateway.
• 3:37
  Schlüsseln wir auf, was das eigentlich bedeutet.
• 3:39
  Beginnen wir mit der grundlegendsten Aufgabe, dem Routing.
• 3:42
  Teil 1 Traffic Routing
• 3:43
  Die einfachste Aufgabe eines API-Gateways ist das Routing, also die Weiterleitung jeder Anfrage an den richtigen Diensten.
• 3:49
  Denken Sie daran, wie es heute funktioniert.
• 3:50
  Wenn Sie auf einen Link klicken, sendet Ihr Browser eine Anfrage.
• 3:53
  Diese Anfrage empfährt.
• 3:54
  Ist der Pfad Users, weiß das Gateway, dass es Ihnen einen Benutzerdienst senden muss.
• 3:57
  Bei Orders geht es an den Bestelldienst.
• 3:59
  Das Gateway liest den Pfad, bestimmt das Ziel und leitet die Anfrage weiter.
• 4:03
  Ohne ein Gateway müssen Ihre Clients jede einzelne Dienst-URL kennen.
• 4:07
  Die mobile App benötigt die Adresse des Benutzerdienstes, des Bestelldienstes, des Zahlungsdienstes und des Katalogdienstes.
• 4:12
  Das sind eine Menge URLs, die verwaltet werden müssen.
• 4:14
  Und wenn sich eine dieser Adressen ändert, müssen Sie jeden Client aktualisieren.
• 4:17
  Mit einem Gateway kennen Clients nur eine URL, die Adresse des Gateways.
• 4:20
  Sie müssen nicht wissen, wo die Dienste tatsächlich liegen.
• 4:22
  Sie senden Ihre Anfrage einfach an das Gateway und dieses kümmert sich um den Rest.
• 4:25
  Dies ist einer der häufigsten Anwendungsfälle für ein API-Gateway, ressourcenbasiertes Routing.
• 4:30
  Die Untersuchung von Apache API 670 ist ausdrücklich hervor.
• 4:32
  Man routet basierend auf dem Pfad der HTTP-Methode, den Headern oder sogar der Geolokalisierung des Clients.
• 4:37
  Sendet jemand aus Europa eine Anfrage, kann man ihn an ein europäisches Rechenzentrum leiten?
• 4:41
  Sendet jemand aus den USA eine Anfrage, geht dieser an ein US-Rechenzentrum?
• 4:44
  Der Client bemerkt von alledem nichts.
• 4:46
  Erhält lediglich eine schnelle Antwort.
• 4:48
  Routing ermöglicht auch die Versionierung.
• 4:49
  Nehmen wir an, Sie haben eine neue Version Ihres Nutzerdiensten.
• 4:51
  Die alten Clients nutzen weiterhin Slash-Ur1-Users und die neuen Slash-Ur2-Users.
• 4:56
  Das Gateway leitet Sie an verschiedene Backends weiter.
• 4:58
  Alte Clients funktionieren weiter, während Sie die neue Version ausrollen.
• 5:01
  Sie können Ihr Backend ändern, ohne dass die Clients gestört werden.
• 5:04
  Das ist enorm wichtig, wenn man eine Live-Anwendung mit echten Nutzern verwaltet.
• 5:07
  Denken Sie an eine E-Commerce-Plattform.
• 5:09
  Sie haben separate Dienste für den Katalog, den Warenkorb, die Kasse und Nutzerkunden.
• 5:13
  Ohne Gateway müsste eine mobile App vier verschiedene URLs kennen.
• 5:17
  Mit einem Gateway kennt Sie nur eine.
• 5:18
  Das Gateway liest den Pfad Katalog, Warenkorb, Kasse, Konto und sendet jede Anfrage an den richtigen Dienst.
• 5:25
  Einfaches Routing ist der leichte Teil.
• 5:26
  Die nächste Aufgabe ist der wirklich nützliche Partner.
• 5:29
  Teil 2. Sicherheit am Haupteingang.
• 5:31
  Jeder API-Aufruf muss geprüft werden.
• 5:33
  Wer stellt diese Anfrage?
• 5:34
  Hat derjenige die erforderlichen Berechtigungen?
• 5:36
  Ohne Gateway muss jeder Dienst seine eigene Authentifizierung verwalten.
• 5:39
  Das bedeutet doppelte Arbeit und ist fehleranfällig.
• 5:42
  Ein Dienst prüft Tokens korrekt, ein anderer lässt einen Schritt aus und ein dritter nutzt eine völlig andere Methode.
• 5:46
  Am Ende haben Sie eine inkonsistente Sicherheit in der gesamten Anwendung.
• 5:51
  Das Gateway ändert das.
• 5:52
  Es übernimmt Authentifizierung und Autorisierung an einer zentralen Stelle.
• 5:55
  Ein Punkt zur Prüfung, ein Punkt zur Durchsetzung, ein Punkt für Updates bei Richtlinienänderungen.
• 5:59
  Das ist eine bewährte Best Practice für Sicherheit.
• 6:01
  Es validiert API-Schlüssel, JBTs, OAuth-Tokens oder Zertifikate bei jeder einzelnen Anfrage.
• 6:07
  Jede Anfrage durchläuft dieselbe Prüfung.
• 6:09
  Ohne Ausnahmen.
• 6:10
  Das Gateway kann auch Regeln durchsetzen.
• 6:12
  Sie können festlegen, dieser API-Schlüssel darf nur diese Endpunkte aufrufen.
• 6:15
  Oder dieser Client darf nur auf den Katalogdienst zugreifen, nicht auf den Zahlungsdienst.
• 6:19
  Sie definieren präzise Berechtigungen auf Gateway-Ebene und diese werden automatisch angewendet.
• 6:23
  Die Backend-Dienste müssen sich nie um die Autorisierung kümmern.
• 6:26
  Sie verarbeiten einfach die Anfrage und senden die Daten zurück.
• 6:28
  Ist der Punkt.
• 6:29
  Das Gateway ist der zentrale Ort, um Zugriffe bei Problemen zu widerrufen.
• 6:33
  Wenn der API-Schlüssel eines Clients kompromittiert ist, sperren Sie ihn am Gateway.
• 6:36
  Eine Änderung fertig.
• 6:37
  Sie müssen keinen Dienst aktualisieren oder irgendetwas neu starten.
• 6:40
  Die nächste Anfrage mit diesem Schlüssel wird sofort abgelehnt.
• 6:43
  Nehmen wir ein praktisches Beispiel.
• 6:44
  Eine Bank hat einen Zahlungsdienst und einen Abrechnungsdienst.
• 6:46
  Nur der Zahlungsdienst benötigt Schreibzugriff auf das Abrechnungssystem.
• 6:49
  Das Gateway setzt dies durch.
• 6:50
  Wenn ein Client versucht, über den falschen Endpunkt in das Abrechnungssystem zu schreiben,
• 6:54
  blockt das Gateway dies.
• 6:55
  Der Abrechnungsdienst sieht die Anfrage nicht einmal.
• 6:57
  Das Gateway kann auch gegenseitiges TLS- und WAF-Integration für tieferen Schutz unterstützen.
• 7:02
  Im Kern ist es jedoch ihre erste Verteidigungslinie.
• 7:04
  Sicherheit ist das eine.
• 7:05
  Aber was passiert bei zu vielen Anfragen gleichzeitig?
• 7:07
  Was passiert, wenn 10.000 Nutzer gleichzeitig auf ihre App zugreifen?
• 7:14
  Vielleicht haben sie einen Flash-Sale, eine Produkteinführung geht viral oder es ist einfach
• 7:17
  ein normaler Dienstag und alle melden sich gleichzeitig an.
• 7:20
  Ohne ein Gateway werden ihre Backend-Dienste direkt überflutet und könnten abstürzen.
• 7:25
  Nicht langsam, sondern alles auf einmal.
• 7:26
  Hier kommt das Traffic-Management ins Spiel.
• 7:28
  Das Gateway kann begrenzen, wie viele Anfragen jeder Client stellen darf.
• 7:32
  Ratenbegrenzung und Drosselung sind Standardfunktion.
• 7:34
  Sie legen die Regeln am Gateway fest und es setzt sie durch.
• 7:37
  Ihre Backend-Dienste bekommen die Lastspitze nie zu spüren.
• 7:39
  Sie können Kontingente, Probenutzer, APE-Schlüssel oder IP-Adresse festlegen.
• 7:43
  Angenommen, Sie haben ein kostenloses Level für Ihre App.
• 7:45
  Kostenlose Nutzer erhalten 100 Anfragen pro Stunde.
• 7:47
  Premium-Nutzer erhalten 10.000.
• 7:48
  Das Gateway verfolgt jede Anfrage und setzt diese Limits direkt am Eingang durch.
• 7:51
  Erreicht ein kostenloser Nutzer sein Limit, sendet das Gateway eine höfliche Nachricht,
• 7:55
  es später zu versuchen.
• 7:57
  Die Backend-Dienste erfahren nicht einmal, dass eine Anfrage stattfand.
• 7:59
  Sie laufen einfach weiter und bedienen die zahlenden Kunden.
• 8:01
  Das Gateway übernimmt auch das Load-Balancing.
• 8:04
  Wenn mehrere Instanzen desselben Dienstes laufen, verteilt das Gateway die Anfragen auf diese.
• 8:09
  Instanz 1 erhält eine Anfrage, Instanz 2 die nächste, Instanz 3 die darauf folgende.
• 8:12
  Das geschieht automatisch.
• 8:14
  Und wenn eine Instanz ausfällt, leitet das Gateway den Verkehr auf eine andere um.
• 8:16
  Die Clients merken davon.
• 8:18
  Sie erhalten einfach ihre Antworten.
• 8:19
  Load-Balancing mit Gesundheitscheckstock für einen reibungslosen Betrieb.
• 8:22
  Das Gateway pingt jede Instanz an, um sicherzustellen, dass sie läuft.
• 8:25
  Ist sie nicht erreichbar, leidet es kein Traffic mehr dorthin.
• 8:27
  Dies ist besonders wichtig für APIs mit hohem Datenverkehr.
• 8:29
  Ohne Gateway trifft eine Verkehrsspitze ihre Dienste direkt.
• 8:33
  Mit dem Gateway trifft die Spitze zuerst auf das Gateway, das sie absorbiert, verteilt und ihre Dienste vor einer Überlastung schützt.
• 8:40
  Aber was ist, wenn die Daten bei der Ankunft nicht korrekt aussehen?
• 8:44
  Teil 4. Datentransformation
• 8:46
  Manchmal entsprechen die vom Client gesendeten Daten nicht dem, was ihr Backend erwartet.
• 8:50
  Vielleicht sendet der Client JSON, aber ihr Backend versteht nur XML.
• 8:54
  Vielleicht stimmen die Feldnamen nicht überein.
• 8:55
  Der Client verwendet Vorname so und ihr Backend erwartet ebenfalls Vorname.
• 8:59
  Diese Diskrepanzen führen zu fehlen.
• 9:00
  Früher mussten Sie jeden einzelnen Client reparieren oder das Backend umschreiben.
• 9:04
  Ich kann ideal.
• 9:05
  Das Gateway kann die Daten transformieren, bevor Sie das Backend erreichen.
• 9:08
  Trachten Sie es als ein Übersetzer.
• 9:09
  Es sitzt in der Mitte und kann die Daten auf dem Weg hinein, hinaus oder beides ändern.
• 9:13
  Das ist Anforderungs- und Antworttransformation in Kürze.
• 9:15
  Lassen Sie mich ein echtes Beispiel geben.
• 9:17
  Nehmen wir an, Sie haben ein Altsystem, das XML erwartet.
• 9:19
  Es läuft seit 15 Jahren.
• 9:21
  Es funktioniert einmal.
• 9:22
  Aber jetzt bauen Sie eine neue mobile App und mobile Apps sprechen JSON.
• 9:25
  Ohne Gateway müssten Sie das Altsystem umschreiben oder die App zwingen, XML zu senden.
• 9:29
  Mit einem Gateway müssen Sie keines verwendet.
• 9:31
  Die mobile App sendet JSON.
• 9:33
  Das Gateway konvertiert es in XML.
• 9:34
  Das System erhält, was es erwartet.
• 9:36
  Die mobile App erhält eine Antwort zurück, die bereits in JSON vorliegt.
• 9:38
  Niemand muss da etwas umschreiben.
• 9:40
  Das ist das Schöne daran.
• 9:41
  Das Gateway kann auch Header hinzufügen oder entfernen, URLs ändern oder sensible Daten maskieren.
• 9:46
  Stellen Sie sich vor, eine Antwort enthält eine Kritik ab.
• 9:48
  Sie möchten nicht, dass diese an den Client zurückgeht.
• 9:50
  Das Gateway kann Sie entfernen, bevor die Antwort das System verlässt oder durch eine maskierte Version ersetzen.
• 9:54
  Das Backend muss sich nie ändern.
• 9:56
  Das Gateway kümmert sich darum.
• 9:57
  Dies ist besonders nützlich, wenn Sie alte Systeme modernisieren.
• 9:59
  Sie müssen das Backend nicht umschreiben.
• 10:01
  Sie müssen Clients nicht zur Änderung zwingen.
• 10:03
  Wir ändern öfters Gateway.
• 10:04
  Es ist wie ein Dolmetscher bei einer internationalen Konferenz.
• 10:06
  Jeder spricht seine eigene Sprache, aber der Dolmetscher stellt sicher, dass jeder jeden versteht.
• 10:10
  Das Gateway ist dieser Dolmetscher für Ihre Software.
• 10:12
  Also Routing, Sicherheit, Drosselung, Transformation, das ist eine ganze Menge.
• 10:15
  Aber es sind keine vier getrennten Dinge.
• 10:17
  Lassen Sie mich zeigen, wie sie zusammenhängt.
• 10:18
  Wie alles zusammenhängt.
• 10:20
  Hier ist die Sache.
• 10:21
  Diese vier Aufgaben sind nicht voneinander getrennt.
• 10:23
  Sie arbeiten bei jeder einzelnen Anfrage zusammen.
• 10:25
  Jedes Mal, wenn eine Frage eingeht.
• 10:26
  Das Gateway prüft die Authentifizierung.
• 10:28
  Es validiert das Ratenlimit.
• 10:29
  Es leitet einen richtigen Dienstwart.
• 10:31
  Es transformiert die Daten, falls nötig.
• 10:32
  Es empfängt die Antwort.
• 10:33
  Es transformiert auch diese, falls erforderlich.
• 10:36
  Dann setzt es alles an den Client zurück.
• 10:37
  Eine Pipeline.
• 10:38
  Jeder Schritt erfolgt automatisch der Reihe nach, ohne dass ein Dienst daran denken muss.
• 10:42
  Die wahre Stärke liegt nicht in einzelnen Funktionen.
• 10:44
  Es ist die Integration.
• 10:46
  Sie können eine neue Sicherheitsrichtlinie hinzufügen, ohne das Routing anzupassen.
• 10:49
  Den Backend-Dienst ohne den Client zu ändern.
• 10:51
  Sie können die Ratenbegrenzung aktualisieren, ohne etwas neu bereitzustellen.
• 10:54
  Jeder Teil ist unabhängig, arbeitet aber in derselben Pipeline.
• 10:57
  Und weil alles durch eine Stelle läuft, erhalten Sie volle Transparenz über die Vorgänge.
• 11:02
  Logs, Metriken, Analysen, alles aus einem Punkt.
• 11:05
  Sie sehen, wie viele Anfragen eingingen, welche fehlschlugen, welche langsam waren, welche Clients die meisten Ressourcen nutzen.
• 11:10
  Ohne Gateway müssten Sie diese Daten von jedem Dienst einzeln sammeln.
• 11:13
  Mit einem Gateway ist alles direkt verfügbar.
• 11:15
  Das ist die wichtige Erkenntnis.
• 11:16
  Das Gateway ist nicht nur ein Router.
• 11:18
  Es ist eine Kontrollzentrale für Ihre gesamte API-Plattform.
• 11:20
  Jede Anfrage, jede Antwort, jeder Fehler, alles fließt durch eine Stelle.
• 11:24
  Sie haben eine zentrale Übersicht für alles, was passiert.
• 11:26
  Wie nutzt man das nun konkret?
• 11:28
  Lassen Sie uns darüber sprechen, was Sie jetzt damit tun.
• 11:30
  Konkrete Handlungsempfehlung.
• 11:31
  Wenn Sie nur ein oder zwei Dienste haben, brauchen Sie wahrscheinlich noch kein API-Gateway.
• 11:35
  Sie können das Routing selbst übernehmen und die Authentifizierung in jedem Dienst verweilen.
• 11:38
  Das ist nicht elegant, aber es funktioniert.
• 11:40
  Aber sobald Sie drei Dienste haben oder APIs für externe Clients freigeben, nimmt die Komplexität schnell zu.
• 11:46
  Das Gateway zahlt sich schnell aus.
• 11:47
  Was ist also Ihr bester Schritt?
• 11:49
  Zentralisieren Sie die Authentifizierung am Gateway.
• 11:50
  Tun Sie das vor allem anderen.
• 11:52
  Wählen Sie einen Dienst und verlagern Sie dessen Authentifizierungsprüfung zum Geld.
• 11:54
  Sie werden sofort bemerken, dass Ihr Dienstcode sauberer wird.
• 11:57
  Keine überall verstreute Logik zur Tokenvalidierung mehr.
• 12:00
  Kein Rätselraten mehr, ob Sie es in jedem Dienst gleich implementiert haben.
• 12:03
  Das Gateway erledigt es einmal und jeder Dienst profitiert davon.
• 12:06
  Nächster Schritt, Ratenbegrenzung.
• 12:09
  Selbst ein einfaches Limit schützt Ihr Backend vor Überlastung.
• 12:11
  Beginnen Sie mit etwas Grundlegendem wie 100 Anfragen pro Minute pro Client.
• 12:14
  Das verhindert, dass ein außer Kontrolle geratener Client Ihre Dienste langlegt.
• 12:17
  Das war die K heinstell!
• 12:18
  Bis zum nächsten Mal.
• 12:19
  Tschüss.