Hey. Herzlich Willkommen zu einer
neuen Folge vom Typ Do Developer Podcast diesmal endlich wieder
mit einem technischen Thema Malte diese Folge geht es um API
Gateways. Geht es dir gut?
Mir geht es wunderbar und ich freue mich auf diese Folge,
insbesondere weil wir in letzter Zeit so viel Feedback bekommen,
und da sind wir natürlich auch ganz gespannt, was ihr zum Thema
API Management sagt. Weil gerade diese Interaktion
mit euch euer Feedback sind super wertvoll, um uns auch
Rückmeldungen zu geben. Ja, können wir uns bevor wir
anfangen? Wir wollten erstmal ein ganz
fettes Danke sagen, die das Feedback zur letzten Folge, wo
wir über die Layoffs in der Tech Branche gesprochen haben, war
offen gestanden. Überwältigend für uns.
Wir waren sehr berührt von den ganz vielen Dankes und ihr habt
uns auch super viele Kaffees ausgegeben und ganz viele von
euch nochmal privat geschrieben und wir haben wirklich sehr viel
sehr rührendes, positives Feedback bekommen und das
möchten wir hier nicht erwähnt lassen.
Also vielen vielen Dank an die Kaffeespenden Danke an Marco für
3 Kaffee Tim für 2 Kaffee Carsten 5 Kaffee roh ist
komplett verrückt, uns Kaffee gespendet.
Vielen Lieben dank Kalle für 4 Kaffee, Sebastian für 2 Kaffee,
also vielen, vielen, vielen Lieben Dank.
Wenn ihr uns auch was Gutes tun wollt, Kaffee spenden wollt,
findet ihr ganz unten in der Beschreibung von diesem Podcast
n Link zu bei mir Coffee. Aber das hat uns wirklich schon
natürlich zusammen mit Euren ganz lieben Worten sehr gerührt
so viel Feedback wie zuletzt in Folge haben wir noch nie
bekommen. Und haben auch daraufhin beide
sowohl Kollegen als auch im Freundeskreis auch nochmal
Gespräche geführt, die ja von dieser Folge inspiriert waren?
Also ganz, ganz herzlichen Dank dann noch eine Mitteilung, die
wir auf jeden Fall noch nachreichen wollten, nämlich zu
den Weihnachtsgeschenken, die wir im Rahmen unserer Umfrage
vergeben haben und zwar, da zunächst der Aufruf an Jan Jörg
und Julia Wir brauchen noch eure Adresse, sonst bekommt ihr euer
Geschenk nicht meldet euch bitte zurück Matthias Max, Marco,
Georg und Rene haben ihr Geschenk schon bekommen.
Viel Spaß damit und wir freuen uns auch weiterhin über euer
Feedback. Und natürlich wird es bei.
Gegebenem Anlass wieder ne neue Runde geben und wir freuen uns
immer über die Interaktion mit euch.
Apropos Interaktion Rene hat uns auch noch Feedback gegeben zu
seinem aktuellen Arbeitgeber, der Halt gar nicht plant.
Mitarbeiterinnen und Mitarbeiter abzubauen, sondern tatsächlich
immer noch viele Leute einstellt.
Das heißt gerade bei kleinen und mittelständischen Unternehmen
ist nicht der Fall, was wir bei den großen Tech Unternehmen
sehen, dass dort Personal abgebaut wird, sondern in der
ganzen Tech Branche. Da ist es immer noch.
Sehr gut einen neuen Job zu finden das heißt auch wenn ihr
jetzt betroffen seid, weil ihr vielleicht bei irgendwelchen
Startups oder großen Tech Unternehmen arbeitet, schaut
euch mal die kleineren Unternehmen im Markt an, die
suchen immer noch gute Leute und freuen sich natürlich, wenn da
Leute von anderswo kommen, die viel Erfahrung mitbringen auch
aus anderen Technologiebereichen.
Außerdem hat Kalle uns zurückgemeldet, dass er auch als
positiv sieht, dass sich durch diese Entlastung bei den ganz
großen so ein bisschen die Gehälter wieder normalisieren,
was natürlich auch mit dem zusammenhängt, was sie gesagt
hat. Gerade kleinere Unternehmen
werden wieder wettbewerbsfähig und bekommen auch wieder gute
Leute. Und ich glaube, das hilft auch
gerade die Innovation aus dem Mittelstand, von kleinen
Unternehmen in Deutschland voranzubringen, so viel zu eurem
Feedback und den Mitteilungen aus unserem Hause.
Aber damit können wir, glaube ich, dann auch endlich ins Thema
einsteigen und das Thema hast du dieses Mal mitgebracht und
nämlich sind das die API Gateways und Möglichkeiten, APIS
zu managen und komfortabel? Bereitzustellen, um zum einen
natürlich die eigene Anwendung besser zu organisieren und
natürlich auch Last von der eigenen Anwendung zu nehmen, was
natürlich gerade bei vielen Services Microservices spannend
ist, aber erzähl einfach mal wie bist du auf das Thema gekommen?
Wie siehst du das ein und warum brauche ich das eigentlich?
Ich brauche in der Regel dann, wenn ich wieder Name schon sagt,
APIS verwende und die irgendwo noch nach draußen bereitstelle.
Das kann sein, dass man Frontend APS konsumiert.
Das kann auch sein, dass ich Partnerfirmen.
Habe die apis konsumieren, das kann auch sein, dass ich meine
Services anderen Entwicklerinnen und Entwicklern anbieten möchte.
Die dann meine APS konsumieren. Und was ich dann halt ne in der
Regel Scheiße habe, wenn ich nicht so eine Zwischenschicht
wie I Gateway benutze, dann habe ich einen neuen Service, der
eine Web Schnittstelle einfach bereitstellt und den Expose ich
dann mehr oder weniger. Ungeschützt ins Internet und ich
sag jetzt mehr oder weniger ungeschützt natürlich habe ich
da irgendwie eine Form der Authentifizierung drauf, dass
vielleicht jeder darauf zugreifen kann aber.
Ich laufe in Probleme rein, wenn meine Anwendungen.
Entweder aus mehreren Microservices besteht, weil ich
dann entweder mehrere einzelne kleine A irgendwie zur Verfügung
stelle, wobei ich vielleicht gar nicht will, dass die, die die
Außenwelt weiß, ob ich jetzt 5 oder 10 oder nur einen Micro
Service habe. Ich will mir das vielleicht
vorhalten können das nochmal ändern nochmal auf kleinere
Services aufzuteilen, aber auch wenn ich einen großen Monolithen
habe, will ich vielleicht trotzdem nicht, dass meine
Anwendungen von API Calls. Ungeschützt bombardiert werden
kann. Und wenn ich da einen
Zwischenlayer einziehe, dann spricht man in der Regel von
API. Gateways ist eigentlich ein ein
Hardware Layer, der zwischen der Außenwelt und meinem meiner
Anwendung sitzt und der DAPI, die meine Anwendung
bereitstellt, im Prinzip zur Außenwelt durchschleift und dann
mit mit verschiedenen Regeln. Versieht und das läuft in der
Regel so, dass ich halt einen API Gateway als eigenen Service
irgendwo deployer oder eben bei einem Cloud Anbieter einkaufe
und denen eigentlich ja nach außen öffne, sodass Entwickler
und Entwicklerinnen diesen PI serviceanfragen schicken können
und der leitet die dann weiter intern an meine Services, die
von meinen Entwicklerinnen und Entwickler erstellt werden.
Das heißt also API Gateways kann ich verwenden, sowohl für meine
eigenen internen. GPS spricht, wenn ich viele
verschiedene Services hab Microservices, die miteinander
kommunizieren. Ich kann diese API Gateways aber
auch sehr sinnvoll einsetzen, wenn ich externe EPS hab dich
anderen developern anderen Unternehmen zur Verfügung
stellen möchte ich dann vielleicht andere Anforderungen
habe als bei internen APIS. Bei externen APS möchte ich
vielleicht ein noch stärkeres Raid Limiting drauf haben.
Ich möchte eine Abrechnungsmöglichkeit haben und
bei internen habe ich dann vielleicht eher
Herausforderungen darüber, dass ich die ganzen.
Sachen gestrichen muss ich n Katalog haben muss, welche EPS
überhaupt zur Verfügung stehen, damit natürlich Service
Developer im Unternehmen wissen was gibt es eigentlich?
Sprich API Gateway ist in beiden Welten relevant brauche ich auch
API Gateways für rein interne APIS, sprich wenn ich an
Servicebau, der zwar nach außen hin vielleicht ne
Webschnittstelle bietet, aber im Backend letzten Endes vielleicht
die Services die miteinander kommunizieren, gar nicht nach
außen freigibt. Du hast gerade gesagt meine
Services werden. Expost nach draußen aber muss
das immer ein ne Verfügbarkeit im Internet sein, dass man von
extern darauf zugreifen kann oder auch innerhalb meiner
Infrastruktur, zum Beispiel beim Cluster, in dem diese ganzen
Microsoft laufen, das ist im Prinzip dir überlassen lässt ja
gerade schon eines der Vorteile von API Gateway gesagt du sagst
gerade throttling, da gehen wir gleich nochmal darauf ein.
Aber wenn du natürlich möchtest du vielleicht deine
Microservices innerhalb von deinem Cluster oder von deinem
System auch über ein solches AP it miteinander kommunizieren,
weil du vielleicht die Vorteile darin siehst, dann lässt sich
das natürlich auch so konfigurieren, dass du das von
intern zu interner Kommunikation nutzt.
Wo ich auf jeden Fall empfehlen würde, ist wenn du mehrere
interne Services, die aber in sich irgendwie geschlossen sind,
sagen wir mal, du hast irgendwie seiner und stellt jetzt gar
nicht im Internet zur Verfügung, sondern stellt sie in einem ganz
anderen Service zur Verfügung, den vielleicht auch gar nicht
kontrollieren kannst. Dann würde ich das auf jeden
Fall verwenden und spätestens im Internet aber sonst noch über
das also du hast gerade gesagt Riding throttling und sowas
gesprochen was so AI denn eigentlich dann so so so
spannend macht und das ist, das ist nämlich eigentlich die Logik
Layer, den ich dann auf. Das Netzwerk lege, bevor ein API
Call, der gegen dieses API dann gemacht wurde, von der externen
Welt. Zu meinem Service nicht
weitergereicht wird. Und neben der Konsolidierung
also, dass ich meine ganzen Services an einem zentralen
Punkt unter einer AB zusammenstellen kann ich dir
auch viele andere spannende Dinge machen.
Unter anderem und wahrscheinlich das erste, was Spannendes ist,
nämlich Reading und Throttling und das bedeutet eigentlich nur,
dass ich regeln auch sehr auf Stelle, wie häufig denn eine
einzelne Instanz meine PS aufrufen darf, da kann ich zum
Beispiel sagen hey, ich möchte, dass anonyme User meine API
maximal weiß ich nicht zehnmal pro Minute aufrufen können.
Mich hat vor, zu viel Traffic zu schützen, kann aber sagen aber
ich möchte, dass andere Konsumenten meiner API
vielleicht die sich angemeldet haben oder weil die mir Geld
bezahlen oder weil das ein Partner von mir ist meinst du
hundert mal pro Minute aufrufen können, also da kann ich so
verschiedene Sachen oder ich kann sagen, dass sie über einen
gewissen Zeitraum nur eine gewisse Anzahl von Requests
machen können und so weiter und das mache ich in der Regel, um
mein System vor zu hoher Last zu schützen.
Also ich kann ja sowohl irgendwie automatische
Skalierung unter meinen Services haben, aber dennoch möchte ich
vielleicht auch nicht, dass eine einzelne Instanz die komplette
Last, die mein System abfangen kann erzeugt.
Das bedeutet gerade in so einem wenn ich eine Multi
mandantensystem bin, also Multitalent C Anwendungen, da
ist das durchaus sehr sinnvoll, wie das technisch funktioniert
eigentlich folgendermaßen ich vergebe dann API Keys.
Meistens kennt man das, wenn man sich irgendeiner externen PI wie
solche B oder sowas. Gemeldet dann bekommt man,
nachdem man sich identifiziert API Key und dieser API Key dient
eigentlich nur dem API Gateway, um mich als Konsumenten ganz
klar zuzuweisen und dann kann ich sagen o jemand, der mit
diesem API Key zu mir kommt, der ist offenbar der Konsument malte
und hat heute schon 10 request geschickt, den er sich heute
nicht mehr durch und dann kriegt man auch entsprechende Antwort
von diesem API Gateway ich glaub 429 ist der T Code für die
Quests und da steht doch meistens immer drin wie lange
man warten muss nochmal neu. Scharf.
Das heißt aber mein Service unten drunter vielleicht im
Cluster steht oder vielleicht auf meinem Server steht, der
bekommt davon gar nichts mit, wenn der API Call nicht
durchgeleitet wird. Das heißt, der muss gar nicht
drauf reagieren, der muss gar nicht irgendwie skalieren, der
muss sich um dieses Ding gar nicht kümmern.
Eigentlich müssen wir schon eine Stufe vorher einsetzen bei dem
ganzen Thema Authentifizierung und Autorisierung.
Wenn ich jetzt auf ne API zugreife, muss ich mich
natürlich zunächst authentifizieren.
Ich muss sagen, wer ich bin und ich muss sagen, dass ich dies.
Zugriffsrecht auf diese PI habe du hast gerade solche API Keys
angesprochen, die können für beides verwendet werden.
Ich kann aber auch andere Kriterien nutzen, die gerade
vielleicht nachher fürs Rad limiting interessant sind wie
zum Beispiel so und so viele Anfragen von der gleichen IP
Adresse. Das funktioniert.
Diese Prüfung funktioniert ja dann quasi schon in dieser
authentifizierungs autorisierungs Phase und das
sind natürlich Funktionalitäten, die alle meine Services
implementieren müssen. Das heißt, ich könnte dort
geteilte Libraries verwenden, die dann aber von jedem Team
implementiert werden müssen. Das heißt, jedes Team müsste in
seinen eigenen Services, gerade wenn wir jetzt in Microservices
denken, die gleichen Funktionalitäten implementieren,
und wir müssen auch sichergehen, dass alle Teams diese Dinge
implementieren und natürlich hilft mir dann, wenn ich so
einen EPI Gateway verwende, um solche Dinge zu zentralisieren
und da fortzusetzen, dass auch diese Funktionalitäten für alle
Teams verfügbar zu machen und natürlich da auch zu
standardisieren und gerade das Thema was du angesprochen
hattest mit dem Rating ist ein extrem wichtiges Thema.
Wenn wir solche Services Internet exposé.
Dass wir sicherstellen, dass nur berechtigte Personen dort
zugreifen können, unterteilt, je nachdem, wie ich dann nachher
auch autorisiert bin, wenn ich anonym, habe ich mich
authentifiziert, bin ich für den Service vielleicht als zahlender
Nutzer autorisiert, je nachdem, wieviel ich vielleicht auch
zahle, habe ich unterschiedliche Zugriffsrechte.
Ich hab vielleicht mehr API Calls pro Minute oder hab auch
vielleicht unterschiedliche Funktionalitäten und genau.
Das setzt natürlich auf dieser ersten Stufe der
Authentifizierung und Autorisierung auf und kann dann
gemeinsam dort in so einem Gateway auch gebündelt werden,
weil wir natürlich sonst extrem große Herausforderungen haben,
das über alles Services hinweg auszurollen, gerade in einer
gewachsenen Infrastruktur. Ich sehe es halt auch an vielen
Beispielen in meinem Alltag, dass gerade, wenn Unternehmen
sehr stark gewachsene Servicearchitekturen hat.
Das ist dann natürlich nachher schwierig.
Wird solche Dinge dann über alles Services hinweg?
Implementieren und in dem Thema Raid Limiting ist natürlich auch
das ganze Thema Missbrauch der EPIS oder PS wichtiges Thema Wir
wollen natürlich auch sichergehen, dass dort zum
Beispiel die of Service Attacken abgefangen werden, das
vielleicht, wenn ich eine kostenfreie EPI anbiete, dass
diese vielleicht nicht exzessiv für irgendwelche kommerziellen
Dienste genutzt wird, also alle diese Themen brauche ich in
meinen APIS und kann das dann an einer Stelle zentralisieren und
das hilft natürlich meinen Teams sich auch über solche Dinge
keine Gedanken mehr machen zu müssen.
Das heißt, ich habe einmal diese Funktionalität, die wird
entweder als Service bereitgestellt, den ich selber
implementiert habe oder als Service, den ich natürlich dazu
kaufen kann. Ja genau, ich glaube gerade
dieses den die Last von den einzelnen Teams nehmen müssen so
wichtiger Punkt weil es ist vielleicht wenn man baue, dann
kann ich dann einen noch selber irgendwo einbauen, dann habe ich
auch weiß ich nicht irgendeine Middleware, die die IP request
irgendwie durch leitet und die hat in der Regel dann auch die
Möglichkeit wieder zu betreiben. Aber für mich ist das eigentlich
auch schon zu spät, wenn sie dann am Service ankommt, der
request dann, dann musst du ja schon irgendwie responsive sein
und installiert sein, das wichtig ist aber auch wie du
sagst Chill, du hast verschiedene Microservices, die
in verschiedenen Programmiersprachen umgesetzt
werden jetzt müsste ich wirklich sichergehen, dass die gleiche
Rate limiting Logik auch wirklich in vielleicht über
verschiedene Frameworks hinweg, trotzdem mit allen
Programmiersprache umgesetzt wird.
Darüber hinaus ist auch Quatsch das zum Beispiel du hast
irgendwas hier super wichtiges Thema Authentifizierung, dass
mein Jason Web Token Meine JT muss wirklich von meinem von
meinem Microsoft validiert werden.
Muss wirklich alle Microservices validiert werden auf dem Weg
oder ist das, was ich einmal machen, bevor die Quest
überhaupt in meinen Infrastruktur reinkommt und wenn
der n ungültigen J Reality hat, dann lass ich den Rest gar nicht
erst durch und ja, da gibt es eine ganze Menge Sachen, die ich
eben auf dieser API ebene Ebene betreiben kann.
Und das andere ist, dass es auch ganz viele Firmen gibt, die
gerade bei größeren Kunden die sagen wir möchten, an einer
zentralen Stelle. Als.it Operations Team managen.
Wie Traffic in unsere Infrastruktur überhaupt
reinkommt und dafür stellen wir einen API Gateway bereit,
irgendwo und Teams oder Abteilungen, die etwas gebaut
haben, was wir nach außen veröffentlichen wollen, die
müssen sich an diesem einen API Gateway registrieren, wo das IT
Operations Team dann zentrale Regeln dafür auch hinterlegen
kann. Und das finde ich eigentlich
auch eine sehr sinnvolle Geschichte, dass man einfach
sagt Hey ne, ich hab ja nicht irgendwie absoluten Wildwuchs
wär alles also ich bin mir nicht die Löcher in meine Firewall und
guck, dass jeder irgendwie was freie Internet explosion darf,
sondern eine zentrale Anlaufstelle.
Und in dieser zentralen Anlaufstelle kann ich dann halt
eben ganz viele von diesen Regeln definieren.
Und dazu gehören ja auch so Sachen, wie dass ich
zentralisiertes Logging habe, oder?
Analytics welche APS werden überhaupt wie häufig verwendet?
Da gibt es mittleres für sowas wie bot Detection, dass ich es
vielleicht ein menschlicher da kommt es irgendwie ne Attacke in
weiß? Ich kann auch in die Requests
reingucken und sehen ob ich vielleicht irgendwie a Action,
die ich gar nicht haben will. Ich kann auch Legacy Anwendungen
anbinden und sagen nicht transformiere Quests nehme ich
vielleicht Jason Reinkriege und das XML schreibe, weil ich
irgendwie ne haben möchte. Das Weiterschicken also, da kann
ich ja alles Mögliche machen, bevor der Request dann
tatsächlich Anwendung kommt und die Entwickler und
Entwicklerinnen draußen liegen dieses I kommunizieren kriegen
das gar nicht mit. Das heißt prinzipiell kann ich
dann als Team, was eine neue API bereitstellt, mich darauf
verlassen, dass alle diese Funktionalitäten implementiert
werden und ich kann mich auf meine Businesslogik
konzentrieren. Ich muss mir keine Gedanken mehr
machen, um das ganze Thema Rate limiting logging ich brauch
mich. Keine Gedanken darüber machen
wie wird das dann gegebenenfalls nachher abgerechnet, sondern
dass wir dann einer Stelle zentralisiert, das heißt, ich
baue meine Funktionalität und weiß dann wenig gegebenenfalls
im Unternehmen ansprechen muss oder kann mich selber dort
registrieren mit meinem Service und kann bestimmte Dinge einfach
nur konfigurieren, statt sie jedes Mal zu implementieren und
ich glaube, der erste Schritt ist dann immer die Frage ist das
ein interner oder externer Service?
Wenn externer Service ist? Welche Funktionalitäten sollen
dort zur Verfügung stehen? Halte ich mich vielleicht an
für. Das gesamte Unternehmen geltende
Rate Limits zum Beispiel gibt es dort bestimmte Payment
Mechanismen, die vermeiden Service gelten, die vielleicht
für andere nicht gelten, und das kann dann wiederum anderes Team
steuern. Was genau für diese Bereiche zum
Beispiel Bios Protection, Drake, Limiting oder vielleicht auch
für den kommerziellen Bereich verantwortlich ist, das heißt
man kann das komplett entkoppeln, das eine Team
konzentriert sich wirklich nur auf seinen Service und ein
anderes Steam kann sich darüber Gedanken machen wie kann ich
dieses Services vielleicht monetarisieren?
Wie kann ich das ganze Schützen? Von außen bei den Zugriffen von
externen Usern o ich finde das sehr schön gesagt, also
konfigurieren anstatt zu implementieren, weil das ist
genau das ist genau der Punkt ich kann natürlich trotzdem
Konfiguration mitgeben für meine APS, aber ich muss halt nicht
mehr selber implementieren dass dieser springende Punkt und da
sieht man auch schon, dass API Gateway sowohl für für große
Enterprise Firmen Benefits haben können, dass es diese
Konsolidierung oder diese Kontrolle, da sich an einer
zentralen Stelle vielleicht nur irgendwie mein Ding.
Reise, aber auch für ganz kleine Anwendungen, die vielleicht aus
mehreren Microservices bestehen viele kleinere Monolithen, nicht
h Interesse, dass gerade in einem Multitalent Bereich nicht
einer meiner Tendence mir so viele Requests schickt, dass ich
entweder meine Skalierende stoße oder gar keine anderen
entgegennehmen kann. Da muss ich ja irgendwie drüber
balancieren und dafür ist API war eigentlich immer ja die die
Go to Variante und einen Punkt, den ich vorhin ja schon am Rande
erwähnt hatte. Das ganze Thema API Katalog
intern oder extern n Portal für meine Developer, um halt zu
wissen welche EPS gibt es, welche Funktionalitäten bieten
die an und wie kann ich diese auch nutzen?
Wir hatten ja in einer der vergangenen Folgen über das
ganze Thema EPI Dokumentation gesprochen und das muss ich
natürlich mit den entsprechenden Tools für jede API machen.
Ich muss dort mich darauf einigen, in welchem Format ich
das mache. Ich muss das Ganze entsprechend
an einer Stelle publishen und auch dort helfen mir solche API
Gateways, weil ja dort die APS über einen.
Definierten Contract angebunden werden und dann können diese EPI
Gateways auch so einen Katalog oder ein developer Portal einen
vielleicht auch einen kommerziellen Katalog
automatisch generieren. Das heißt, ich muss mir selber
auch vielleicht gar keine Gedanken mehr darüber machen,
dass das ganze standardisiert ist, weil wir nicht natürlich
viele verschiedene Teams haben, die sehr unabhängig voneinander
die Services entwickeln. Wir hatten ja in unserer in
unserer Folge über das Thema EPI Dokumentation darüber
gesprochen, ja, ich hab hier vielleicht irgendwie eine
Technologie, ich hab irgendwie alles Internet oder ich hab
vielleicht auch einen. Monolithisches Backend.
Was verschiedene es anbietet, dieses vielleicht noch einfach,
wenn ich mir jetzt vorstelle ich hier diverse Teams, die jeweils
ihre API entwickeln, pflegen, dokumentieren dann müssen diese
natürlich auch die verschiedenen Tools benutzen, die dann am Ende
das gleiche Output Format liefern, damit ich das in diesem
zentralen Portal auch anbieten kann und auch hier hilft mir so
ein Gateway wäre das nochmal nachhören möchte.
Das war die Folge 31 wo wir uns über die Dokumentation von EPS
ausgetauscht haben und passend dazu ist auch die Folge. 40 wohl
über API Versionierung gesprochen haben denn genau auch
das ist ja was wir sagen API Gateway bieten kann, dass ich
sage Hey der neuen Version meiner APIS wird der Traffic
vielleicht auch gegen einen anderen Service geroutet oder
wird anders transformiert und ich möchte dann vielleicht auch
in so einem developer Portal anbieten, dass man gegen
verschiedene Versionen seines schicken kann und dann die
Version vielleicht in Form von einer oder von einem Parameter
angeben. Also das sind auch wichtige
Punkte. Und gerade dieses Developer
Portal. An sich ist natürlich auch zum
einen Teil Margot von einer guten Dokumentation wir alle
kennen das, wenn das Macht immer Spaß, wenn irgendwie ne Doku
arbeiten direkt interaktiv ist, wo ich irgendwie Quest
ausprobieren kann, also wie man Paradebeispiel ist, der Strippe.
Ich finde die beste Developer Experience haben, die ich je
gesehen habe, wirklich tolle Doku.
Ich kann direkt in der Doku dann request abschicken und da wird
direkt an die Customize auf auf meinen Account auch angepasst
also. Das war natürlich Spaß und zum
anderen natürlich auch ein super cooles Feature von vielen A,
dass sie ebenso ein solches developer Portal generieren, wo
ich meine registrieren kann diese Ganzen aus Tanz einmal
machen kann. Das natürlich immer schon eine
coole Sache, wenn ich mir jetzt so ein API Gateway zulegen
möchte, dass in meinem Unternehmen einführen möchte,
vielleicht auch für ein kleineres Projekt von Anfang an
nutzen möchte, habe ich natürlich die Wahl zwischen
einer selbst gehosteten Variante, sprich ich betreibe
selber dieses Gateway selber oder ich nehme Variante, die von
einem Cloud Provider bereitgestellt wird und beide
Varianten kann ich sowohl verwenden, wenn ich in der.
Cloud laufe, wenn ich in der Public Cloud laufe, als auch in
der Variante, wenn eigentlich meine Services irgendwo in einem
eigenen Data Center auf einem eigenen Server oder bei einem
Dienstleister laufen. Hast du da ein paar Beispiele,
die wir unseren Hörerinnen und Hörern an die Hand geben können,
wenn sie sich jetzt mit dem Thema beschäftigen wollen?
Ja gerne, ich würde sogar behaupten ich hab die irgendwann
angeschaut, also ich hab. Wir haben bei uns ein Projekt,
haben wir mittlerweile auch damit gestartet, dass OI 3
selber gebaut haben, weil es klingt jetzt auch nicht komplex,
ich irgendwo e ich nenne x oder irgendwie was auch immer und sag
einfach pass auf das ist mein Gateway.
Oder ich programmiere mir selber irgendwas was einfach wo man EPS
registrieren kann, Routen generiert und lege halt regeln
auf diese Routen. Aber haben dann relativ schnell
gemerkt das wird dann doch ziemlich komplex und ich will
vielleicht die Last gar nicht innerhalb von meinem eigenen.
In meiner eigenen Infrastruktur haben, weil ich will eigentlich
eine Infrastruktur der Schützen. Und Hagel haben uns dann eben
auch in der Cloud gehostete API Gateways angeschaut.
Das bedeutet im Fall der Cloud Provider stellt mir einfach als
Managed Service ein solches I bereit, wo ich meine APIS dran
registrieren kann und muss dann dem Provider natürlich sagen Hey
mein mein Service an denen die APIG dann weiterleiten soll, den
findest du entweder auch hier und da in der Cloud oder hier
und da in meinem on premise Netzwerk, da muss ich natürlich
eine Verbindung zwischen. Der Cloud und dem Preis Netzwerk
haben. Und kann dann entsprechend
konfigurieren. Und ja, eigentlich stellt jeder
große Cloud Provider einen fertigen Service bereit, also in
der Welt ist das API Management in der Google Cloud Welt ist das
Apple G es ist auch deren API Gateway.
Die haben alle ein sehr ähnliches Set an Features und
funktionieren alle ähnlich. Heißt schon bisschen anders,
scheint aber vom Prinzip her ist das eigentlich immer dasselbe?
Und was auch ganz cool ist bei vielen kann ich aber auch sagen
ich möchte das in der Cloud irgendwie konfigurieren und dann
aber trotzdem deployen in meine eigene Infrastruktur und das
mache ich halt vor allem dann, wenn ich eine sehr geschätzte
Infrastruktur habe, die vielleicht aus erreichbar ist,
kann ich aber trotzdem diese Konfiguration dieses developer
Portal diese Regel und sowas alles alles nehmen und die
synchronisieren sich dann mit einem Service, der bei mir in
der eigenen Infrastruktur läuft. Der Nachteil davon so n bisschen
ist, dass ich das sehr schwer lokal testen kann.
Also nehmen wir irre viel Arbeit ab und in der Regel auch
wirklich coole Services. Aber wenn ich das lokal teste
oder wenn ich mich super unabhängig von einem dieser
Provider machen möchte, dann natürlich n Problem und deswegen
gibt es auch andere Lösungen, die eben nicht von einem
bestimmten Programmen, sondern die ich selber konfigurieren und
hosten kann und ich glaube, die populärste draußen, die ich sehr
gerne mag ist Kong. Übrigens hier verlinken all
diese Lösungen auch unten in den Shows, weil ich das mal in Ruhe
angucken möchte, aber Kong ist ein Open Source API Gateway und
zumindest ein Opencore. AB, dass ich da schon vor Free
starten und mir das selber irgendwohin deployen und dann
noch selber irgendwo konfigurieren und kann dann,
wenn ich so ein bisschen weiterführende Features nutzen
möchte, wie zum Beispiel die Generierung eines
Entwicklerportals. Auch Balkon die Lizenz kaufen
oder kann auch sagen Hey Kong, Hostel?
Doch dieses API Gateway für mich und ich zeig dir dann, wo du
meine Services findest in bei meinem Provider der Wahl oder on
Prem oder wo auch immer also das fand ich eigentlich ne sehr
spannende Variante und damit kann man auch sehr gut anfangen.
Kong integriert zum Beispiel fantastisch in Kubernetes
Cluster also wer Kubernetes einsetzt, wahrscheinlich
spätestens nach Paris Folge n Paar von euch das freut mich
immer, wenn Leute mich zunächst fragen.
Das heißt aber, das werde ich bin großer Fan.
Dann lässt sich auch sehr nativ mit Kubernetes Board mitteln
konfigurieren, erweitern und man kann quasi auch mit
Qualitätsressourcen sein API Gateway konfigurieren und seinen
Services heißt das ja auch in Inkopolis, dann auch sagen hey,
ich möchte, dass du so und so gespottet wirst du vielleicht
ein bisschen anders, aber du bist ja vielleicht meine meine
Webseite will ich gar nicht teln und wie gesagt es geht nicht nur
um Throttling, sondern auch ganz viel so um request
Transformationen für zentrales Logging nicht wieder sehen.
Wer von meinen Wer von meinen Konsumenten, wie oft meine APS
überhaupt verwendet, um den dann vielleicht auch irgendwie ein
besseres Paket anbieten zu können?
Und wie gesagt, ich kann sowohl die von den Cloud Providern
empfehlen, also API Management P und API Gateway.
Als auch Kong ist auf jeden Fall, was man sich angucken kann
und wie gesagt, dann ist man eben auch komplett kostenlos
starten das einfach als Container lokal installiert und
so ein bisschen damit rumspielt hat dann keine Fans die
Oberfläche wo ich irgendwas einstellen kann, sondern alles
irgendwie über Konfigurationen hat mir großen Spaß gemacht,
damit zu arbeiten, was dann für mich die richtige Variante ist,
hängt auch ein bisschen vom eigenen Use Case ab.
Natürlich wenn man in einem der großen Public Cloud Provider
läuft ich das natürlich nahe sich mal diese Varianten
anzugucken. Generell muss man, glaube ich
erstmal entscheiden. Sind SAPIS, die nur intern
genutzt werden, verwende ich das nur innerhalb meines
Unternehmens, dann s vielleicht auch sinnvoll.
Direkt diesen API Gateway im gleichen Cluster zu betreiben,
wenn ich diese Services gar nicht nach außen anbieten
möchte, brauche ich vielleicht gar nicht so einen developer
Portal, was auch vielleicht abrechnungs und Billing
Funktionalitäten bietet und das ist auch ein Faktor, wo dann
natürlich so ein Dienstleister ins Spiel kommen kann.
Wenn ich jetzt meine Services anfange zu monetarisieren und
habe solche subscription. Modelle da drauf und sagt hier
du kannst wir haben, es glaube ich alle uns mal angeguckt bei
Chat GT, da kann ich hingehen und sagen ich hol mir da so EIK
und erlaubt es mir so viele Requests zu machen und ich muss
dafür so viele Monat zahlen und genau das gleiche kann ich ja
auch für meine eigenen APIS anbieten und gerade an dem Punkt
brauche ich dann ne Abrechnungsmethode.
Ich muss halt vielleicht ein Billiganbieter anbieten, wo sich
die Leute nicht nur registrieren können, sondern auch ihre
Zahlungsdaten hinterlegen. Ich brauch irgendwie eine Art
von Rechnungsstellung, was natürlich relativ.
Komplex ist man kann natürlich über API solche Billiganbieter
wie Stripes selber einbinden, aber die großen Cloud Provider
bieten wir dann teilweise direkt auch
Abrechnungsfunktionalitäten, wo dann vielleicht andere Kunden
dieses Cloud Providers einfach mit ihrem existierenden Account,
den sie bei diesem Cloud Provider haben, über so ne Art
Marketplace Modell sich dort anmelden und registrieren und
auch abrechnen können, muss ich natürlich entsprechend
Provisionen zahlen. An diese Anbieter Arbeit das
nimmt natürlich hier viel ab. Das heißt ich muss mir gleich
erstmal einfach Gedanken machen wofür.
Berücksichtigen I Gateway nutze ich den auch für externe Nutzer
nur intern möchte ich die Anwendung komplett in der Cloud
betreiben und möchte ich das vielleicht auch am Ende
monetarisieren und dann grenzt sich das n bisschen ein aber ich
glaub, die erste Entscheidung ist halt wo läuft meine
Anwendung und wofür verwende ich diesen API?
Gateway ganz genau vielleicht noch eine letzte Sache, die mir
wichtig ist, ist, dass wir noch ganz gut da Security schauen,
weil ich auf jeden Fall nicht unerwähnt lassen möchte ist
natürlich müssen irgendwo diese Microservices, die ich habe.
Auf meinem API Gateway vertrauen.
Weil die ja dann mehr oder weniger oder so auf jeden Fall
weniger geschützt unterwegs sind, weil sie sich auf den
Schutz von diesem PI Gateway verlassen.
Das heißt, ich muss natürlich sicherstellen, dass die nur von
dem API Gateway angesprochen werden können, am besten über
wenn nicht kann mache ich das über das Netzwerk fest, dass wir
hier im privaten Netzwerk sich einfach nur befinden und gar
nicht von außen irgendwie erreichbar sind und nur von den
EIG erreichbar sind. Und das lässt sich natürlich
aber auch da sind lässt sich so Trust Relationship auch
herstellen, indem zum Beispiel die Verbindungen verschlüsselt
oder mit einem Zertifikat arbeite, was das API Management
hinterlegt bekommt und was dann die meine Microservices oder
meine Services generell akzeptieren also das ist ein
ganz wichtiger Punkt ist natürlich dann auch das Ganze so
konfigurieren muss, dass wenn ich den ganzen Schutz als i Gay
auslagern, die Microservices System API vertrauen oder auch
nur dem API Gateway vertrauen. Das noch als kleinen Security
Disclaimer wunderbar ich glaube, dann haben wir sowohl die
technischen Aspekte die Hintergründe beleuchtet, warum
man sowas braucht, haben ein paar Varianten besprochen, wie
man sowas bereitstellen kann. Uns würde natürlich
interessieren habt ihr selber Erfahrungen mit solchen
Gateways? Welche verwendet ihr?
Da könnt ihr vielleicht auch bestimmte Dinge empfehlen,
schreibt uns da gerne eine Email, sind wir natürlich wie
immer sehr daran interessiert und wenn wir da Feedback
bekommen, teilen wir das natürlich auch gerne mit der
Community im Rahmen einer. In den nächsten Folgen
beleuchtet Podcast gefallen hat dann lasst uns auch gerne
Bewertung, da ihr können sich sowohl auf Spotify auf Apple
Podcast Daumen Sternchen weiß, auch immer geben.
Wir freuen uns immer, wenn die Kommentare hinterlassen können,
das natürlich aber auch über die E Mail Adresse, die unten in der
Beschreibung von diesem Podcast steht privat machen, wenn ihr
uns so Feedback hinterlassen wollt oder ne Frage habt oder
was auch immer, dann freuen wir uns immer sehr über die
Diskussionen. Lasst uns also gerne wissen und
ansonsten freuen wir uns, wenn ihr auch in 2 Wochen wieder
dabei seid. Denn der Lukas erscheint alle 2
Wochen. Bis dahin schreibt ganz viel
Code ab ganz viel Spaß auf 2 tolle Wochen und bis ganz bald
bis dahin.