1 00:00:01,980 --> 00:00:06,070 Hey. Herzlich Willkommen zu einer 2 00:00:06,080 --> 00:00:10,660 neuen Folge vom Typ Do Developer Podcast diesmal endlich wieder 3 00:00:10,670 --> 00:00:14,430 mit einem technischen Thema Malte diese Folge geht es um API 4 00:00:14,440 --> 00:00:16,200 Gateways. Geht es dir gut? 5 00:00:16,660 --> 00:00:19,150 Mir geht es wunderbar und ich freue mich auf diese Folge, 6 00:00:19,160 --> 00:00:22,410 insbesondere weil wir in letzter Zeit so viel Feedback bekommen, 7 00:00:22,420 --> 00:00:25,490 und da sind wir natürlich auch ganz gespannt, was ihr zum Thema 8 00:00:25,500 --> 00:00:28,590 API Management sagt. Weil gerade diese Interaktion 9 00:00:28,600 --> 00:00:31,900 mit euch euer Feedback sind super wertvoll, um uns auch 10 00:00:31,940 --> 00:00:34,120 Rückmeldungen zu geben. Ja, können wir uns bevor wir 11 00:00:34,130 --> 00:00:36,850 anfangen? Wir wollten erstmal ein ganz 12 00:00:36,860 --> 00:00:40,480 fettes Danke sagen, die das Feedback zur letzten Folge, wo 13 00:00:40,490 --> 00:00:42,990 wir über die Layoffs in der Tech Branche gesprochen haben, war 14 00:00:43,220 --> 00:00:45,030 offen gestanden. Überwältigend für uns. 15 00:00:45,590 --> 00:00:49,570 Wir waren sehr berührt von den ganz vielen Dankes und ihr habt 16 00:00:49,580 --> 00:00:52,830 uns auch super viele Kaffees ausgegeben und ganz viele von 17 00:00:52,840 --> 00:00:56,800 euch nochmal privat geschrieben und wir haben wirklich sehr viel 18 00:00:56,840 --> 00:00:59,150 sehr rührendes, positives Feedback bekommen und das 19 00:00:59,160 --> 00:01:00,510 möchten wir hier nicht erwähnt lassen. 20 00:01:01,350 --> 00:01:05,600 Also vielen vielen Dank an die Kaffeespenden Danke an Marco für 21 00:01:05,610 --> 00:01:09,180 3 Kaffee Tim für 2 Kaffee Carsten 5 Kaffee roh ist 22 00:01:09,190 --> 00:01:11,020 komplett verrückt, uns Kaffee gespendet. 23 00:01:11,030 --> 00:01:14,640 Vielen Lieben dank Kalle für 4 Kaffee, Sebastian für 2 Kaffee, 24 00:01:14,650 --> 00:01:17,120 also vielen, vielen, vielen Lieben Dank. 25 00:01:18,090 --> 00:01:20,160 Wenn ihr uns auch was Gutes tun wollt, Kaffee spenden wollt, 26 00:01:20,170 --> 00:01:23,960 findet ihr ganz unten in der Beschreibung von diesem Podcast 27 00:01:23,970 --> 00:01:27,140 n Link zu bei mir Coffee. Aber das hat uns wirklich schon 28 00:01:27,180 --> 00:01:30,720 natürlich zusammen mit Euren ganz lieben Worten sehr gerührt 29 00:01:30,970 --> 00:01:32,960 so viel Feedback wie zuletzt in Folge haben wir noch nie 30 00:01:32,970 --> 00:01:36,980 bekommen. Und haben auch daraufhin beide 31 00:01:37,290 --> 00:01:39,230 sowohl Kollegen als auch im Freundeskreis auch nochmal 32 00:01:39,240 --> 00:01:42,720 Gespräche geführt, die ja von dieser Folge inspiriert waren? 33 00:01:43,340 --> 00:01:47,430 Also ganz, ganz herzlichen Dank dann noch eine Mitteilung, die 34 00:01:47,440 --> 00:01:50,150 wir auf jeden Fall noch nachreichen wollten, nämlich zu 35 00:01:50,160 --> 00:01:53,630 den Weihnachtsgeschenken, die wir im Rahmen unserer Umfrage 36 00:01:53,640 --> 00:01:58,700 vergeben haben und zwar, da zunächst der Aufruf an Jan Jörg 37 00:01:58,710 --> 00:02:01,990 und Julia Wir brauchen noch eure Adresse, sonst bekommt ihr euer 38 00:02:02,000 --> 00:02:06,230 Geschenk nicht meldet euch bitte zurück Matthias Max, Marco, 39 00:02:06,240 --> 00:02:08,340 Georg und Rene haben ihr Geschenk schon bekommen. 40 00:02:08,639 --> 00:02:12,490 Viel Spaß damit und wir freuen uns auch weiterhin über euer 41 00:02:12,500 --> 00:02:14,180 Feedback. Und natürlich wird es bei. 42 00:02:14,600 --> 00:02:17,780 Gegebenem Anlass wieder ne neue Runde geben und wir freuen uns 43 00:02:17,790 --> 00:02:19,440 immer über die Interaktion mit euch. 44 00:02:20,200 --> 00:02:25,010 Apropos Interaktion Rene hat uns auch noch Feedback gegeben zu 45 00:02:25,020 --> 00:02:29,040 seinem aktuellen Arbeitgeber, der Halt gar nicht plant. 46 00:02:29,080 --> 00:02:32,450 Mitarbeiterinnen und Mitarbeiter abzubauen, sondern tatsächlich 47 00:02:32,500 --> 00:02:34,070 immer noch viele Leute einstellt. 48 00:02:34,080 --> 00:02:36,970 Das heißt gerade bei kleinen und mittelständischen Unternehmen 49 00:02:37,380 --> 00:02:39,960 ist nicht der Fall, was wir bei den großen Tech Unternehmen 50 00:02:39,970 --> 00:02:42,720 sehen, dass dort Personal abgebaut wird, sondern in der 51 00:02:42,730 --> 00:02:45,080 ganzen Tech Branche. Da ist es immer noch. 52 00:02:45,390 --> 00:02:47,960 Sehr gut einen neuen Job zu finden das heißt auch wenn ihr 53 00:02:47,970 --> 00:02:50,680 jetzt betroffen seid, weil ihr vielleicht bei irgendwelchen 54 00:02:50,870 --> 00:02:53,280 Startups oder großen Tech Unternehmen arbeitet, schaut 55 00:02:53,290 --> 00:02:56,770 euch mal die kleineren Unternehmen im Markt an, die 56 00:02:56,780 --> 00:02:59,490 suchen immer noch gute Leute und freuen sich natürlich, wenn da 57 00:02:59,500 --> 00:03:02,800 Leute von anderswo kommen, die viel Erfahrung mitbringen auch 58 00:03:02,810 --> 00:03:04,680 aus anderen Technologiebereichen. 59 00:03:05,070 --> 00:03:08,700 Außerdem hat Kalle uns zurückgemeldet, dass er auch als 60 00:03:08,710 --> 00:03:11,360 positiv sieht, dass sich durch diese Entlastung bei den ganz 61 00:03:11,370 --> 00:03:13,660 großen so ein bisschen die Gehälter wieder normalisieren, 62 00:03:13,900 --> 00:03:16,470 was natürlich auch mit dem zusammenhängt, was sie gesagt 63 00:03:16,480 --> 00:03:17,730 hat. Gerade kleinere Unternehmen 64 00:03:17,740 --> 00:03:20,270 werden wieder wettbewerbsfähig und bekommen auch wieder gute 65 00:03:20,280 --> 00:03:21,510 Leute. Und ich glaube, das hilft auch 66 00:03:21,520 --> 00:03:24,630 gerade die Innovation aus dem Mittelstand, von kleinen 67 00:03:24,640 --> 00:03:29,570 Unternehmen in Deutschland voranzubringen, so viel zu eurem 68 00:03:29,580 --> 00:03:34,270 Feedback und den Mitteilungen aus unserem Hause. 69 00:03:34,550 --> 00:03:37,380 Aber damit können wir, glaube ich, dann auch endlich ins Thema 70 00:03:37,390 --> 00:03:40,720 einsteigen und das Thema hast du dieses Mal mitgebracht und 71 00:03:40,730 --> 00:03:46,390 nämlich sind das die API Gateways und Möglichkeiten, APIS 72 00:03:46,400 --> 00:03:50,870 zu managen und komfortabel? Bereitzustellen, um zum einen 73 00:03:50,880 --> 00:03:54,980 natürlich die eigene Anwendung besser zu organisieren und 74 00:03:54,990 --> 00:03:57,920 natürlich auch Last von der eigenen Anwendung zu nehmen, was 75 00:03:57,930 --> 00:04:02,090 natürlich gerade bei vielen Services Microservices spannend 76 00:04:02,100 --> 00:04:04,490 ist, aber erzähl einfach mal wie bist du auf das Thema gekommen? 77 00:04:04,500 --> 00:04:07,730 Wie siehst du das ein und warum brauche ich das eigentlich? 78 00:04:07,840 --> 00:04:10,390 Ich brauche in der Regel dann, wenn ich wieder Name schon sagt, 79 00:04:10,400 --> 00:04:14,130 APIS verwende und die irgendwo noch nach draußen bereitstelle. 80 00:04:14,140 --> 00:04:16,649 Das kann sein, dass man Frontend APS konsumiert. 81 00:04:16,660 --> 00:04:18,589 Das kann auch sein, dass ich Partnerfirmen. 82 00:04:20,019 --> 00:04:22,990 Habe die apis konsumieren, das kann auch sein, dass ich meine 83 00:04:23,000 --> 00:04:25,290 Services anderen Entwicklerinnen und Entwicklern anbieten möchte. 84 00:04:26,340 --> 00:04:30,490 Die dann meine APS konsumieren. Und was ich dann halt ne in der 85 00:04:30,500 --> 00:04:33,260 Regel Scheiße habe, wenn ich nicht so eine Zwischenschicht 86 00:04:33,270 --> 00:04:37,260 wie I Gateway benutze, dann habe ich einen neuen Service, der 87 00:04:37,270 --> 00:04:39,860 eine Web Schnittstelle einfach bereitstellt und den Expose ich 88 00:04:39,870 --> 00:04:44,550 dann mehr oder weniger. Ungeschützt ins Internet und ich 89 00:04:44,560 --> 00:04:46,440 sag jetzt mehr oder weniger ungeschützt natürlich habe ich 90 00:04:46,450 --> 00:04:49,490 da irgendwie eine Form der Authentifizierung drauf, dass 91 00:04:49,500 --> 00:04:53,110 vielleicht jeder darauf zugreifen kann aber. 92 00:04:54,640 --> 00:04:57,570 Ich laufe in Probleme rein, wenn meine Anwendungen. 93 00:04:58,320 --> 00:05:01,060 Entweder aus mehreren Microservices besteht, weil ich 94 00:05:01,070 --> 00:05:04,370 dann entweder mehrere einzelne kleine A irgendwie zur Verfügung 95 00:05:04,380 --> 00:05:09,620 stelle, wobei ich vielleicht gar nicht will, dass die, die die 96 00:05:09,630 --> 00:05:12,670 Außenwelt weiß, ob ich jetzt 5 oder 10 oder nur einen Micro 97 00:05:12,680 --> 00:05:14,390 Service habe. Ich will mir das vielleicht 98 00:05:14,400 --> 00:05:17,240 vorhalten können das nochmal ändern nochmal auf kleinere 99 00:05:17,250 --> 00:05:20,610 Services aufzuteilen, aber auch wenn ich einen großen Monolithen 100 00:05:20,620 --> 00:05:24,290 habe, will ich vielleicht trotzdem nicht, dass meine 101 00:05:24,300 --> 00:05:30,550 Anwendungen von API Calls. Ungeschützt bombardiert werden 102 00:05:30,560 --> 00:05:33,170 kann. Und wenn ich da einen 103 00:05:33,180 --> 00:05:35,260 Zwischenlayer einziehe, dann spricht man in der Regel von 104 00:05:35,270 --> 00:05:38,320 API. Gateways ist eigentlich ein ein 105 00:05:38,900 --> 00:05:43,050 Hardware Layer, der zwischen der Außenwelt und meinem meiner 106 00:05:43,060 --> 00:05:47,050 Anwendung sitzt und der DAPI, die meine Anwendung 107 00:05:47,060 --> 00:05:51,550 bereitstellt, im Prinzip zur Außenwelt durchschleift und dann 108 00:05:51,560 --> 00:05:56,350 mit mit verschiedenen Regeln. Versieht und das läuft in der 109 00:05:56,360 --> 00:05:59,710 Regel so, dass ich halt einen API Gateway als eigenen Service 110 00:05:59,760 --> 00:06:02,850 irgendwo deployer oder eben bei einem Cloud Anbieter einkaufe 111 00:06:03,440 --> 00:06:08,870 und denen eigentlich ja nach außen öffne, sodass Entwickler 112 00:06:08,880 --> 00:06:11,490 und Entwicklerinnen diesen PI serviceanfragen schicken können 113 00:06:11,500 --> 00:06:15,310 und der leitet die dann weiter intern an meine Services, die 114 00:06:15,320 --> 00:06:17,710 von meinen Entwicklerinnen und Entwickler erstellt werden. 115 00:06:17,720 --> 00:06:21,850 Das heißt also API Gateways kann ich verwenden, sowohl für meine 116 00:06:21,860 --> 00:06:26,030 eigenen internen. GPS spricht, wenn ich viele 117 00:06:26,040 --> 00:06:28,710 verschiedene Services hab Microservices, die miteinander 118 00:06:29,270 --> 00:06:32,580 kommunizieren. Ich kann diese API Gateways aber 119 00:06:32,590 --> 00:06:35,780 auch sehr sinnvoll einsetzen, wenn ich externe EPS hab dich 120 00:06:35,790 --> 00:06:38,480 anderen developern anderen Unternehmen zur Verfügung 121 00:06:38,490 --> 00:06:41,310 stellen möchte ich dann vielleicht andere Anforderungen 122 00:06:41,320 --> 00:06:44,320 habe als bei internen APIS. Bei externen APS möchte ich 123 00:06:44,330 --> 00:06:47,580 vielleicht ein noch stärkeres Raid Limiting drauf haben. 124 00:06:47,590 --> 00:06:49,600 Ich möchte eine Abrechnungsmöglichkeit haben und 125 00:06:49,990 --> 00:06:52,630 bei internen habe ich dann vielleicht eher 126 00:06:52,670 --> 00:06:54,860 Herausforderungen darüber, dass ich die ganzen. 127 00:06:55,650 --> 00:06:58,840 Sachen gestrichen muss ich n Katalog haben muss, welche EPS 128 00:06:58,850 --> 00:07:01,480 überhaupt zur Verfügung stehen, damit natürlich Service 129 00:07:01,490 --> 00:07:04,250 Developer im Unternehmen wissen was gibt es eigentlich? 130 00:07:04,290 --> 00:07:08,750 Sprich API Gateway ist in beiden Welten relevant brauche ich auch 131 00:07:08,790 --> 00:07:13,040 API Gateways für rein interne APIS, sprich wenn ich an 132 00:07:13,050 --> 00:07:15,530 Servicebau, der zwar nach außen hin vielleicht ne 133 00:07:15,540 --> 00:07:19,250 Webschnittstelle bietet, aber im Backend letzten Endes vielleicht 134 00:07:19,260 --> 00:07:22,350 die Services die miteinander kommunizieren, gar nicht nach 135 00:07:22,360 --> 00:07:25,050 außen freigibt. Du hast gerade gesagt meine 136 00:07:25,060 --> 00:07:28,120 Services werden. Expost nach draußen aber muss 137 00:07:28,130 --> 00:07:32,510 das immer ein ne Verfügbarkeit im Internet sein, dass man von 138 00:07:32,520 --> 00:07:35,740 extern darauf zugreifen kann oder auch innerhalb meiner 139 00:07:35,750 --> 00:07:39,270 Infrastruktur, zum Beispiel beim Cluster, in dem diese ganzen 140 00:07:39,310 --> 00:07:43,180 Microsoft laufen, das ist im Prinzip dir überlassen lässt ja 141 00:07:43,190 --> 00:07:46,900 gerade schon eines der Vorteile von API Gateway gesagt du sagst 142 00:07:46,910 --> 00:07:49,550 gerade throttling, da gehen wir gleich nochmal darauf ein. 143 00:07:50,280 --> 00:07:52,080 Aber wenn du natürlich möchtest du vielleicht deine 144 00:07:52,090 --> 00:07:54,480 Microservices innerhalb von deinem Cluster oder von deinem 145 00:07:54,490 --> 00:07:57,690 System auch über ein solches AP it miteinander kommunizieren, 146 00:07:58,140 --> 00:08:01,570 weil du vielleicht die Vorteile darin siehst, dann lässt sich 147 00:08:01,580 --> 00:08:03,450 das natürlich auch so konfigurieren, dass du das von 148 00:08:03,500 --> 00:08:05,770 intern zu interner Kommunikation nutzt. 149 00:08:06,760 --> 00:08:09,200 Wo ich auf jeden Fall empfehlen würde, ist wenn du mehrere 150 00:08:09,210 --> 00:08:11,870 interne Services, die aber in sich irgendwie geschlossen sind, 151 00:08:11,880 --> 00:08:15,240 sagen wir mal, du hast irgendwie seiner und stellt jetzt gar 152 00:08:15,250 --> 00:08:17,710 nicht im Internet zur Verfügung, sondern stellt sie in einem ganz 153 00:08:17,720 --> 00:08:20,050 anderen Service zur Verfügung, den vielleicht auch gar nicht 154 00:08:20,060 --> 00:08:22,040 kontrollieren kannst. Dann würde ich das auf jeden 155 00:08:22,050 --> 00:08:25,490 Fall verwenden und spätestens im Internet aber sonst noch über 156 00:08:25,500 --> 00:08:28,380 das also du hast gerade gesagt Riding throttling und sowas 157 00:08:28,390 --> 00:08:31,920 gesprochen was so AI denn eigentlich dann so so so 158 00:08:31,930 --> 00:08:35,150 spannend macht und das ist, das ist nämlich eigentlich die Logik 159 00:08:35,159 --> 00:08:40,110 Layer, den ich dann auf. Das Netzwerk lege, bevor ein API 160 00:08:40,120 --> 00:08:44,510 Call, der gegen dieses API dann gemacht wurde, von der externen 161 00:08:44,520 --> 00:08:47,290 Welt. Zu meinem Service nicht 162 00:08:47,300 --> 00:08:50,320 weitergereicht wird. Und neben der Konsolidierung 163 00:08:50,330 --> 00:08:52,700 also, dass ich meine ganzen Services an einem zentralen 164 00:08:52,710 --> 00:08:55,300 Punkt unter einer AB zusammenstellen kann ich dir 165 00:08:55,310 --> 00:08:57,620 auch viele andere spannende Dinge machen. 166 00:08:58,630 --> 00:09:01,200 Unter anderem und wahrscheinlich das erste, was Spannendes ist, 167 00:09:01,210 --> 00:09:04,020 nämlich Reading und Throttling und das bedeutet eigentlich nur, 168 00:09:04,030 --> 00:09:07,540 dass ich regeln auch sehr auf Stelle, wie häufig denn eine 169 00:09:07,550 --> 00:09:11,060 einzelne Instanz meine PS aufrufen darf, da kann ich zum 170 00:09:11,070 --> 00:09:15,540 Beispiel sagen hey, ich möchte, dass anonyme User meine API 171 00:09:15,550 --> 00:09:18,790 maximal weiß ich nicht zehnmal pro Minute aufrufen können. 172 00:09:18,940 --> 00:09:23,190 Mich hat vor, zu viel Traffic zu schützen, kann aber sagen aber 173 00:09:23,200 --> 00:09:26,920 ich möchte, dass andere Konsumenten meiner API 174 00:09:27,480 --> 00:09:30,600 vielleicht die sich angemeldet haben oder weil die mir Geld 175 00:09:30,610 --> 00:09:33,790 bezahlen oder weil das ein Partner von mir ist meinst du 176 00:09:33,800 --> 00:09:36,160 hundert mal pro Minute aufrufen können, also da kann ich so 177 00:09:36,170 --> 00:09:39,650 verschiedene Sachen oder ich kann sagen, dass sie über einen 178 00:09:39,660 --> 00:09:43,290 gewissen Zeitraum nur eine gewisse Anzahl von Requests 179 00:09:43,300 --> 00:09:46,320 machen können und so weiter und das mache ich in der Regel, um 180 00:09:46,330 --> 00:09:49,140 mein System vor zu hoher Last zu schützen. 181 00:09:49,210 --> 00:09:51,140 Also ich kann ja sowohl irgendwie automatische 182 00:09:51,150 --> 00:09:54,630 Skalierung unter meinen Services haben, aber dennoch möchte ich 183 00:09:54,640 --> 00:09:58,710 vielleicht auch nicht, dass eine einzelne Instanz die komplette 184 00:09:59,160 --> 00:10:01,740 Last, die mein System abfangen kann erzeugt. 185 00:10:02,080 --> 00:10:04,060 Das bedeutet gerade in so einem wenn ich eine Multi 186 00:10:04,070 --> 00:10:08,090 mandantensystem bin, also Multitalent C Anwendungen, da 187 00:10:08,140 --> 00:10:11,110 ist das durchaus sehr sinnvoll, wie das technisch funktioniert 188 00:10:11,120 --> 00:10:14,330 eigentlich folgendermaßen ich vergebe dann API Keys. 189 00:10:14,340 --> 00:10:17,870 Meistens kennt man das, wenn man sich irgendeiner externen PI wie 190 00:10:17,880 --> 00:10:20,330 solche B oder sowas. Gemeldet dann bekommt man, 191 00:10:20,580 --> 00:10:25,480 nachdem man sich identifiziert API Key und dieser API Key dient 192 00:10:25,490 --> 00:10:28,090 eigentlich nur dem API Gateway, um mich als Konsumenten ganz 193 00:10:28,100 --> 00:10:30,530 klar zuzuweisen und dann kann ich sagen o jemand, der mit 194 00:10:30,540 --> 00:10:34,490 diesem API Key zu mir kommt, der ist offenbar der Konsument malte 195 00:10:34,960 --> 00:10:38,190 und hat heute schon 10 request geschickt, den er sich heute 196 00:10:38,200 --> 00:10:40,610 nicht mehr durch und dann kriegt man auch entsprechende Antwort 197 00:10:40,620 --> 00:10:45,740 von diesem API Gateway ich glaub 429 ist der T Code für die 198 00:10:45,750 --> 00:10:48,150 Quests und da steht doch meistens immer drin wie lange 199 00:10:48,160 --> 00:10:49,910 man warten muss nochmal neu. Scharf. 200 00:10:51,360 --> 00:10:53,650 Das heißt aber mein Service unten drunter vielleicht im 201 00:10:53,660 --> 00:10:56,160 Cluster steht oder vielleicht auf meinem Server steht, der 202 00:10:56,170 --> 00:11:00,140 bekommt davon gar nichts mit, wenn der API Call nicht 203 00:11:00,150 --> 00:11:01,690 durchgeleitet wird. Das heißt, der muss gar nicht 204 00:11:01,700 --> 00:11:04,970 drauf reagieren, der muss gar nicht irgendwie skalieren, der 205 00:11:04,980 --> 00:11:06,750 muss sich um dieses Ding gar nicht kümmern. 206 00:11:07,100 --> 00:11:09,730 Eigentlich müssen wir schon eine Stufe vorher einsetzen bei dem 207 00:11:09,740 --> 00:11:12,510 ganzen Thema Authentifizierung und Autorisierung. 208 00:11:12,550 --> 00:11:15,070 Wenn ich jetzt auf ne API zugreife, muss ich mich 209 00:11:15,080 --> 00:11:17,830 natürlich zunächst authentifizieren. 210 00:11:17,840 --> 00:11:21,120 Ich muss sagen, wer ich bin und ich muss sagen, dass ich dies. 211 00:11:21,360 --> 00:11:24,570 Zugriffsrecht auf diese PI habe du hast gerade solche API Keys 212 00:11:24,720 --> 00:11:27,200 angesprochen, die können für beides verwendet werden. 213 00:11:27,530 --> 00:11:29,880 Ich kann aber auch andere Kriterien nutzen, die gerade 214 00:11:29,890 --> 00:11:32,590 vielleicht nachher fürs Rad limiting interessant sind wie 215 00:11:32,600 --> 00:11:35,450 zum Beispiel so und so viele Anfragen von der gleichen IP 216 00:11:35,460 --> 00:11:36,660 Adresse. Das funktioniert. 217 00:11:36,670 --> 00:11:39,220 Diese Prüfung funktioniert ja dann quasi schon in dieser 218 00:11:39,700 --> 00:11:42,980 authentifizierungs autorisierungs Phase und das 219 00:11:42,990 --> 00:11:45,530 sind natürlich Funktionalitäten, die alle meine Services 220 00:11:45,540 --> 00:11:47,630 implementieren müssen. Das heißt, ich könnte dort 221 00:11:47,760 --> 00:11:50,630 geteilte Libraries verwenden, die dann aber von jedem Team 222 00:11:50,640 --> 00:11:54,090 implementiert werden müssen. Das heißt, jedes Team müsste in 223 00:11:54,100 --> 00:11:56,730 seinen eigenen Services, gerade wenn wir jetzt in Microservices 224 00:11:56,740 --> 00:11:59,730 denken, die gleichen Funktionalitäten implementieren, 225 00:11:59,900 --> 00:12:02,270 und wir müssen auch sichergehen, dass alle Teams diese Dinge 226 00:12:02,680 --> 00:12:05,690 implementieren und natürlich hilft mir dann, wenn ich so 227 00:12:05,700 --> 00:12:08,850 einen EPI Gateway verwende, um solche Dinge zu zentralisieren 228 00:12:08,860 --> 00:12:11,690 und da fortzusetzen, dass auch diese Funktionalitäten für alle 229 00:12:11,700 --> 00:12:14,090 Teams verfügbar zu machen und natürlich da auch zu 230 00:12:14,100 --> 00:12:17,130 standardisieren und gerade das Thema was du angesprochen 231 00:12:17,140 --> 00:12:19,570 hattest mit dem Rating ist ein extrem wichtiges Thema. 232 00:12:19,580 --> 00:12:22,030 Wenn wir solche Services Internet exposé. 233 00:12:22,410 --> 00:12:24,950 Dass wir sicherstellen, dass nur berechtigte Personen dort 234 00:12:24,960 --> 00:12:28,070 zugreifen können, unterteilt, je nachdem, wie ich dann nachher 235 00:12:28,080 --> 00:12:30,920 auch autorisiert bin, wenn ich anonym, habe ich mich 236 00:12:30,930 --> 00:12:34,030 authentifiziert, bin ich für den Service vielleicht als zahlender 237 00:12:34,040 --> 00:12:39,020 Nutzer autorisiert, je nachdem, wieviel ich vielleicht auch 238 00:12:39,030 --> 00:12:40,500 zahle, habe ich unterschiedliche Zugriffsrechte. 239 00:12:40,510 --> 00:12:45,440 Ich hab vielleicht mehr API Calls pro Minute oder hab auch 240 00:12:45,450 --> 00:12:47,500 vielleicht unterschiedliche Funktionalitäten und genau. 241 00:12:48,710 --> 00:12:52,600 Das setzt natürlich auf dieser ersten Stufe der 242 00:12:53,020 --> 00:12:55,900 Authentifizierung und Autorisierung auf und kann dann 243 00:12:55,910 --> 00:12:59,000 gemeinsam dort in so einem Gateway auch gebündelt werden, 244 00:12:59,310 --> 00:13:01,600 weil wir natürlich sonst extrem große Herausforderungen haben, 245 00:13:01,610 --> 00:13:04,320 das über alles Services hinweg auszurollen, gerade in einer 246 00:13:04,330 --> 00:13:06,600 gewachsenen Infrastruktur. Ich sehe es halt auch an vielen 247 00:13:06,610 --> 00:13:09,730 Beispielen in meinem Alltag, dass gerade, wenn Unternehmen 248 00:13:09,990 --> 00:13:14,320 sehr stark gewachsene Servicearchitekturen hat. 249 00:13:14,330 --> 00:13:16,060 Das ist dann natürlich nachher schwierig. 250 00:13:16,070 --> 00:13:19,000 Wird solche Dinge dann über alles Services hinweg? 251 00:13:19,350 --> 00:13:23,720 Implementieren und in dem Thema Raid Limiting ist natürlich auch 252 00:13:23,730 --> 00:13:29,660 das ganze Thema Missbrauch der EPIS oder PS wichtiges Thema Wir 253 00:13:29,670 --> 00:13:32,520 wollen natürlich auch sichergehen, dass dort zum 254 00:13:32,530 --> 00:13:35,320 Beispiel die of Service Attacken abgefangen werden, das 255 00:13:35,330 --> 00:13:38,120 vielleicht, wenn ich eine kostenfreie EPI anbiete, dass 256 00:13:38,130 --> 00:13:40,970 diese vielleicht nicht exzessiv für irgendwelche kommerziellen 257 00:13:40,980 --> 00:13:43,740 Dienste genutzt wird, also alle diese Themen brauche ich in 258 00:13:43,750 --> 00:13:48,140 meinen APIS und kann das dann an einer Stelle zentralisieren und 259 00:13:48,150 --> 00:13:50,620 das hilft natürlich meinen Teams sich auch über solche Dinge 260 00:13:50,630 --> 00:13:52,060 keine Gedanken mehr machen zu müssen. 261 00:13:52,130 --> 00:13:54,580 Das heißt, ich habe einmal diese Funktionalität, die wird 262 00:13:54,590 --> 00:13:58,330 entweder als Service bereitgestellt, den ich selber 263 00:13:58,340 --> 00:14:00,810 implementiert habe oder als Service, den ich natürlich dazu 264 00:14:00,820 --> 00:14:02,750 kaufen kann. Ja genau, ich glaube gerade 265 00:14:02,760 --> 00:14:05,650 dieses den die Last von den einzelnen Teams nehmen müssen so 266 00:14:05,660 --> 00:14:09,310 wichtiger Punkt weil es ist vielleicht wenn man baue, dann 267 00:14:09,520 --> 00:14:12,600 kann ich dann einen noch selber irgendwo einbauen, dann habe ich 268 00:14:12,610 --> 00:14:17,650 auch weiß ich nicht irgendeine Middleware, die die IP request 269 00:14:17,660 --> 00:14:20,250 irgendwie durch leitet und die hat in der Regel dann auch die 270 00:14:20,260 --> 00:14:23,870 Möglichkeit wieder zu betreiben. Aber für mich ist das eigentlich 271 00:14:23,880 --> 00:14:26,520 auch schon zu spät, wenn sie dann am Service ankommt, der 272 00:14:26,530 --> 00:14:29,060 request dann, dann musst du ja schon irgendwie responsive sein 273 00:14:29,070 --> 00:14:32,180 und installiert sein, das wichtig ist aber auch wie du 274 00:14:32,190 --> 00:14:34,320 sagst Chill, du hast verschiedene Microservices, die 275 00:14:34,330 --> 00:14:35,610 in verschiedenen Programmiersprachen umgesetzt 276 00:14:35,990 --> 00:14:38,720 werden jetzt müsste ich wirklich sichergehen, dass die gleiche 277 00:14:38,730 --> 00:14:41,720 Rate limiting Logik auch wirklich in vielleicht über 278 00:14:41,730 --> 00:14:44,480 verschiedene Frameworks hinweg, trotzdem mit allen 279 00:14:44,530 --> 00:14:45,820 Programmiersprache umgesetzt wird. 280 00:14:46,780 --> 00:14:49,510 Darüber hinaus ist auch Quatsch das zum Beispiel du hast 281 00:14:49,520 --> 00:14:52,130 irgendwas hier super wichtiges Thema Authentifizierung, dass 282 00:14:52,140 --> 00:14:55,710 mein Jason Web Token Meine JT muss wirklich von meinem von 283 00:14:55,720 --> 00:14:57,350 meinem Microsoft validiert werden. 284 00:14:57,360 --> 00:15:00,020 Muss wirklich alle Microservices validiert werden auf dem Weg 285 00:15:00,060 --> 00:15:02,490 oder ist das, was ich einmal machen, bevor die Quest 286 00:15:02,500 --> 00:15:05,170 überhaupt in meinen Infrastruktur reinkommt und wenn 287 00:15:05,180 --> 00:15:09,120 der n ungültigen J Reality hat, dann lass ich den Rest gar nicht 288 00:15:09,130 --> 00:15:13,160 erst durch und ja, da gibt es eine ganze Menge Sachen, die ich 289 00:15:13,170 --> 00:15:16,870 eben auf dieser API ebene Ebene betreiben kann. 290 00:15:17,570 --> 00:15:20,820 Und das andere ist, dass es auch ganz viele Firmen gibt, die 291 00:15:20,830 --> 00:15:24,620 gerade bei größeren Kunden die sagen wir möchten, an einer 292 00:15:24,630 --> 00:15:30,130 zentralen Stelle. Als.it Operations Team managen. 293 00:15:30,850 --> 00:15:33,530 Wie Traffic in unsere Infrastruktur überhaupt 294 00:15:33,540 --> 00:15:36,300 reinkommt und dafür stellen wir einen API Gateway bereit, 295 00:15:36,310 --> 00:15:40,730 irgendwo und Teams oder Abteilungen, die etwas gebaut 296 00:15:40,740 --> 00:15:43,500 haben, was wir nach außen veröffentlichen wollen, die 297 00:15:43,510 --> 00:15:47,300 müssen sich an diesem einen API Gateway registrieren, wo das IT 298 00:15:47,310 --> 00:15:50,580 Operations Team dann zentrale Regeln dafür auch hinterlegen 299 00:15:50,590 --> 00:15:52,900 kann. Und das finde ich eigentlich 300 00:15:52,940 --> 00:15:55,660 auch eine sehr sinnvolle Geschichte, dass man einfach 301 00:15:55,670 --> 00:15:58,130 sagt Hey ne, ich hab ja nicht irgendwie absoluten Wildwuchs 302 00:15:58,140 --> 00:16:01,430 wär alles also ich bin mir nicht die Löcher in meine Firewall und 303 00:16:01,440 --> 00:16:04,720 guck, dass jeder irgendwie was freie Internet explosion darf, 304 00:16:04,760 --> 00:16:07,160 sondern eine zentrale Anlaufstelle. 305 00:16:08,000 --> 00:16:10,450 Und in dieser zentralen Anlaufstelle kann ich dann halt 306 00:16:10,460 --> 00:16:12,470 eben ganz viele von diesen Regeln definieren. 307 00:16:13,200 --> 00:16:15,320 Und dazu gehören ja auch so Sachen, wie dass ich 308 00:16:15,330 --> 00:16:17,070 zentralisiertes Logging habe, oder? 309 00:16:17,080 --> 00:16:19,910 Analytics welche APS werden überhaupt wie häufig verwendet? 310 00:16:20,340 --> 00:16:23,950 Da gibt es mittleres für sowas wie bot Detection, dass ich es 311 00:16:23,960 --> 00:16:27,860 vielleicht ein menschlicher da kommt es irgendwie ne Attacke in 312 00:16:27,870 --> 00:16:29,770 weiß? Ich kann auch in die Requests 313 00:16:29,780 --> 00:16:32,510 reingucken und sehen ob ich vielleicht irgendwie a Action, 314 00:16:32,520 --> 00:16:35,310 die ich gar nicht haben will. Ich kann auch Legacy Anwendungen 315 00:16:35,320 --> 00:16:37,990 anbinden und sagen nicht transformiere Quests nehme ich 316 00:16:38,000 --> 00:16:41,220 vielleicht Jason Reinkriege und das XML schreibe, weil ich 317 00:16:41,230 --> 00:16:45,360 irgendwie ne haben möchte. Das Weiterschicken also, da kann 318 00:16:45,370 --> 00:16:48,040 ich ja alles Mögliche machen, bevor der Request dann 319 00:16:48,050 --> 00:16:51,310 tatsächlich Anwendung kommt und die Entwickler und 320 00:16:51,320 --> 00:16:54,550 Entwicklerinnen draußen liegen dieses I kommunizieren kriegen 321 00:16:54,560 --> 00:16:56,860 das gar nicht mit. Das heißt prinzipiell kann ich 322 00:16:56,870 --> 00:17:00,690 dann als Team, was eine neue API bereitstellt, mich darauf 323 00:17:00,700 --> 00:17:04,380 verlassen, dass alle diese Funktionalitäten implementiert 324 00:17:04,390 --> 00:17:07,500 werden und ich kann mich auf meine Businesslogik 325 00:17:07,510 --> 00:17:09,450 konzentrieren. Ich muss mir keine Gedanken mehr 326 00:17:09,460 --> 00:17:14,130 machen, um das ganze Thema Rate limiting logging ich brauch 327 00:17:14,140 --> 00:17:15,740 mich. Keine Gedanken darüber machen 328 00:17:15,750 --> 00:17:17,920 wie wird das dann gegebenenfalls nachher abgerechnet, sondern 329 00:17:17,930 --> 00:17:20,200 dass wir dann einer Stelle zentralisiert, das heißt, ich 330 00:17:20,210 --> 00:17:25,160 baue meine Funktionalität und weiß dann wenig gegebenenfalls 331 00:17:25,200 --> 00:17:27,700 im Unternehmen ansprechen muss oder kann mich selber dort 332 00:17:27,710 --> 00:17:30,890 registrieren mit meinem Service und kann bestimmte Dinge einfach 333 00:17:30,900 --> 00:17:34,560 nur konfigurieren, statt sie jedes Mal zu implementieren und 334 00:17:34,570 --> 00:17:36,890 ich glaube, der erste Schritt ist dann immer die Frage ist das 335 00:17:36,900 --> 00:17:38,700 ein interner oder externer Service? 336 00:17:38,710 --> 00:17:41,680 Wenn externer Service ist? Welche Funktionalitäten sollen 337 00:17:41,690 --> 00:17:44,310 dort zur Verfügung stehen? Halte ich mich vielleicht an 338 00:17:44,830 --> 00:17:47,210 für. Das gesamte Unternehmen geltende 339 00:17:47,740 --> 00:17:50,760 Rate Limits zum Beispiel gibt es dort bestimmte Payment 340 00:17:50,770 --> 00:17:53,150 Mechanismen, die vermeiden Service gelten, die vielleicht 341 00:17:53,160 --> 00:17:56,350 für andere nicht gelten, und das kann dann wiederum anderes Team 342 00:17:56,360 --> 00:17:59,290 steuern. Was genau für diese Bereiche zum 343 00:17:59,300 --> 00:18:03,230 Beispiel Bios Protection, Drake, Limiting oder vielleicht auch 344 00:18:03,240 --> 00:18:05,830 für den kommerziellen Bereich verantwortlich ist, das heißt 345 00:18:05,840 --> 00:18:08,030 man kann das komplett entkoppeln, das eine Team 346 00:18:08,040 --> 00:18:10,230 konzentriert sich wirklich nur auf seinen Service und ein 347 00:18:10,240 --> 00:18:12,970 anderes Steam kann sich darüber Gedanken machen wie kann ich 348 00:18:12,980 --> 00:18:15,130 dieses Services vielleicht monetarisieren? 349 00:18:15,140 --> 00:18:18,170 Wie kann ich das ganze Schützen? Von außen bei den Zugriffen von 350 00:18:18,180 --> 00:18:21,470 externen Usern o ich finde das sehr schön gesagt, also 351 00:18:21,480 --> 00:18:24,610 konfigurieren anstatt zu implementieren, weil das ist 352 00:18:24,620 --> 00:18:27,740 genau das ist genau der Punkt ich kann natürlich trotzdem 353 00:18:27,750 --> 00:18:31,870 Konfiguration mitgeben für meine APS, aber ich muss halt nicht 354 00:18:31,880 --> 00:18:35,370 mehr selber implementieren dass dieser springende Punkt und da 355 00:18:35,380 --> 00:18:39,290 sieht man auch schon, dass API Gateway sowohl für für große 356 00:18:39,300 --> 00:18:42,000 Enterprise Firmen Benefits haben können, dass es diese 357 00:18:42,010 --> 00:18:44,690 Konsolidierung oder diese Kontrolle, da sich an einer 358 00:18:44,700 --> 00:18:46,560 zentralen Stelle vielleicht nur irgendwie mein Ding. 359 00:18:46,630 --> 00:18:50,150 Reise, aber auch für ganz kleine Anwendungen, die vielleicht aus 360 00:18:50,160 --> 00:18:54,070 mehreren Microservices bestehen viele kleinere Monolithen, nicht 361 00:18:54,080 --> 00:18:57,990 h Interesse, dass gerade in einem Multitalent Bereich nicht 362 00:18:58,040 --> 00:19:01,430 einer meiner Tendence mir so viele Requests schickt, dass ich 363 00:19:01,440 --> 00:19:05,250 entweder meine Skalierende stoße oder gar keine anderen 364 00:19:05,260 --> 00:19:07,590 entgegennehmen kann. Da muss ich ja irgendwie drüber 365 00:19:07,600 --> 00:19:11,210 balancieren und dafür ist API war eigentlich immer ja die die 366 00:19:11,220 --> 00:19:16,070 Go to Variante und einen Punkt, den ich vorhin ja schon am Rande 367 00:19:16,080 --> 00:19:19,350 erwähnt hatte. Das ganze Thema API Katalog 368 00:19:19,390 --> 00:19:23,740 intern oder extern n Portal für meine Developer, um halt zu 369 00:19:23,750 --> 00:19:27,090 wissen welche EPS gibt es, welche Funktionalitäten bieten 370 00:19:27,100 --> 00:19:28,820 die an und wie kann ich diese auch nutzen? 371 00:19:29,070 --> 00:19:31,430 Wir hatten ja in einer der vergangenen Folgen über das 372 00:19:31,440 --> 00:19:34,890 ganze Thema EPI Dokumentation gesprochen und das muss ich 373 00:19:34,900 --> 00:19:38,590 natürlich mit den entsprechenden Tools für jede API machen. 374 00:19:38,600 --> 00:19:41,350 Ich muss dort mich darauf einigen, in welchem Format ich 375 00:19:41,360 --> 00:19:42,990 das mache. Ich muss das Ganze entsprechend 376 00:19:43,000 --> 00:19:46,590 an einer Stelle publishen und auch dort helfen mir solche API 377 00:19:46,600 --> 00:19:48,900 Gateways, weil ja dort die APS über einen. 378 00:19:49,250 --> 00:19:54,090 Definierten Contract angebunden werden und dann können diese EPI 379 00:19:54,100 --> 00:19:58,020 Gateways auch so einen Katalog oder ein developer Portal einen 380 00:19:58,240 --> 00:20:00,070 vielleicht auch einen kommerziellen Katalog 381 00:20:00,080 --> 00:20:02,990 automatisch generieren. Das heißt, ich muss mir selber 382 00:20:03,000 --> 00:20:05,370 auch vielleicht gar keine Gedanken mehr darüber machen, 383 00:20:05,380 --> 00:20:08,090 dass das ganze standardisiert ist, weil wir nicht natürlich 384 00:20:08,100 --> 00:20:11,260 viele verschiedene Teams haben, die sehr unabhängig voneinander 385 00:20:11,270 --> 00:20:13,810 die Services entwickeln. Wir hatten ja in unserer in 386 00:20:13,820 --> 00:20:17,250 unserer Folge über das Thema EPI Dokumentation darüber 387 00:20:17,260 --> 00:20:19,190 gesprochen, ja, ich hab hier vielleicht irgendwie eine 388 00:20:19,200 --> 00:20:21,320 Technologie, ich hab irgendwie alles Internet oder ich hab 389 00:20:21,330 --> 00:20:23,320 vielleicht auch einen. Monolithisches Backend. 390 00:20:23,330 --> 00:20:25,830 Was verschiedene es anbietet, dieses vielleicht noch einfach, 391 00:20:26,110 --> 00:20:29,230 wenn ich mir jetzt vorstelle ich hier diverse Teams, die jeweils 392 00:20:29,240 --> 00:20:33,560 ihre API entwickeln, pflegen, dokumentieren dann müssen diese 393 00:20:33,570 --> 00:20:36,580 natürlich auch die verschiedenen Tools benutzen, die dann am Ende 394 00:20:36,590 --> 00:20:39,400 das gleiche Output Format liefern, damit ich das in diesem 395 00:20:39,410 --> 00:20:42,580 zentralen Portal auch anbieten kann und auch hier hilft mir so 396 00:20:42,590 --> 00:20:45,960 ein Gateway wäre das nochmal nachhören möchte. 397 00:20:46,000 --> 00:20:50,460 Das war die Folge 31 wo wir uns über die Dokumentation von EPS 398 00:20:50,470 --> 00:20:54,260 ausgetauscht haben und passend dazu ist auch die Folge. 40 wohl 399 00:20:54,270 --> 00:20:57,130 über API Versionierung gesprochen haben denn genau auch 400 00:20:57,140 --> 00:21:00,280 das ist ja was wir sagen API Gateway bieten kann, dass ich 401 00:21:00,290 --> 00:21:03,480 sage Hey der neuen Version meiner APIS wird der Traffic 402 00:21:03,490 --> 00:21:06,010 vielleicht auch gegen einen anderen Service geroutet oder 403 00:21:06,020 --> 00:21:09,820 wird anders transformiert und ich möchte dann vielleicht auch 404 00:21:09,830 --> 00:21:13,560 in so einem developer Portal anbieten, dass man gegen 405 00:21:13,570 --> 00:21:17,300 verschiedene Versionen seines schicken kann und dann die 406 00:21:17,310 --> 00:21:20,120 Version vielleicht in Form von einer oder von einem Parameter 407 00:21:20,130 --> 00:21:22,340 angeben. Also das sind auch wichtige 408 00:21:22,350 --> 00:21:23,580 Punkte. Und gerade dieses Developer 409 00:21:23,590 --> 00:21:25,970 Portal. An sich ist natürlich auch zum 410 00:21:25,980 --> 00:21:28,830 einen Teil Margot von einer guten Dokumentation wir alle 411 00:21:28,840 --> 00:21:32,040 kennen das, wenn das Macht immer Spaß, wenn irgendwie ne Doku 412 00:21:32,050 --> 00:21:35,220 arbeiten direkt interaktiv ist, wo ich irgendwie Quest 413 00:21:35,230 --> 00:21:38,520 ausprobieren kann, also wie man Paradebeispiel ist, der Strippe. 414 00:21:38,530 --> 00:21:41,670 Ich finde die beste Developer Experience haben, die ich je 415 00:21:41,680 --> 00:21:44,760 gesehen habe, wirklich tolle Doku. 416 00:21:44,800 --> 00:21:49,600 Ich kann direkt in der Doku dann request abschicken und da wird 417 00:21:49,610 --> 00:21:53,560 direkt an die Customize auf auf meinen Account auch angepasst 418 00:21:53,570 --> 00:21:56,260 also. Das war natürlich Spaß und zum 419 00:21:56,270 --> 00:21:59,560 anderen natürlich auch ein super cooles Feature von vielen A, 420 00:21:59,570 --> 00:22:02,320 dass sie ebenso ein solches developer Portal generieren, wo 421 00:22:02,330 --> 00:22:05,710 ich meine registrieren kann diese Ganzen aus Tanz einmal 422 00:22:05,720 --> 00:22:09,400 machen kann. Das natürlich immer schon eine 423 00:22:09,410 --> 00:22:15,140 coole Sache, wenn ich mir jetzt so ein API Gateway zulegen 424 00:22:15,680 --> 00:22:18,640 möchte, dass in meinem Unternehmen einführen möchte, 425 00:22:18,650 --> 00:22:21,370 vielleicht auch für ein kleineres Projekt von Anfang an 426 00:22:21,380 --> 00:22:23,310 nutzen möchte, habe ich natürlich die Wahl zwischen 427 00:22:24,450 --> 00:22:27,490 einer selbst gehosteten Variante, sprich ich betreibe 428 00:22:27,500 --> 00:22:31,510 selber dieses Gateway selber oder ich nehme Variante, die von 429 00:22:31,520 --> 00:22:35,510 einem Cloud Provider bereitgestellt wird und beide 430 00:22:35,520 --> 00:22:38,800 Varianten kann ich sowohl verwenden, wenn ich in der. 431 00:22:38,870 --> 00:22:42,260 Cloud laufe, wenn ich in der Public Cloud laufe, als auch in 432 00:22:42,270 --> 00:22:45,380 der Variante, wenn eigentlich meine Services irgendwo in einem 433 00:22:45,390 --> 00:22:48,170 eigenen Data Center auf einem eigenen Server oder bei einem 434 00:22:48,180 --> 00:22:51,110 Dienstleister laufen. Hast du da ein paar Beispiele, 435 00:22:51,120 --> 00:22:53,990 die wir unseren Hörerinnen und Hörern an die Hand geben können, 436 00:22:54,000 --> 00:22:56,010 wenn sie sich jetzt mit dem Thema beschäftigen wollen? 437 00:22:56,200 --> 00:22:58,600 Ja gerne, ich würde sogar behaupten ich hab die irgendwann 438 00:22:58,610 --> 00:23:02,600 angeschaut, also ich hab. Wir haben bei uns ein Projekt, 439 00:23:02,610 --> 00:23:05,180 haben wir mittlerweile auch damit gestartet, dass OI 3 440 00:23:05,190 --> 00:23:09,600 selber gebaut haben, weil es klingt jetzt auch nicht komplex, 441 00:23:09,610 --> 00:23:14,350 ich irgendwo e ich nenne x oder irgendwie was auch immer und sag 442 00:23:14,360 --> 00:23:17,060 einfach pass auf das ist mein Gateway. 443 00:23:17,730 --> 00:23:21,180 Oder ich programmiere mir selber irgendwas was einfach wo man EPS 444 00:23:21,190 --> 00:23:23,970 registrieren kann, Routen generiert und lege halt regeln 445 00:23:23,980 --> 00:23:26,640 auf diese Routen. Aber haben dann relativ schnell 446 00:23:26,650 --> 00:23:29,430 gemerkt das wird dann doch ziemlich komplex und ich will 447 00:23:29,440 --> 00:23:32,090 vielleicht die Last gar nicht innerhalb von meinem eigenen. 448 00:23:32,870 --> 00:23:35,910 In meiner eigenen Infrastruktur haben, weil ich will eigentlich 449 00:23:35,920 --> 00:23:41,180 eine Infrastruktur der Schützen. Und Hagel haben uns dann eben 450 00:23:41,190 --> 00:23:45,560 auch in der Cloud gehostete API Gateways angeschaut. 451 00:23:45,570 --> 00:23:48,850 Das bedeutet im Fall der Cloud Provider stellt mir einfach als 452 00:23:48,860 --> 00:23:52,640 Managed Service ein solches I bereit, wo ich meine APIS dran 453 00:23:53,100 --> 00:23:57,010 registrieren kann und muss dann dem Provider natürlich sagen Hey 454 00:23:57,080 --> 00:24:02,190 mein mein Service an denen die APIG dann weiterleiten soll, den 455 00:24:02,200 --> 00:24:05,190 findest du entweder auch hier und da in der Cloud oder hier 456 00:24:05,200 --> 00:24:07,630 und da in meinem on premise Netzwerk, da muss ich natürlich 457 00:24:07,640 --> 00:24:10,090 eine Verbindung zwischen. Der Cloud und dem Preis Netzwerk 458 00:24:10,100 --> 00:24:12,650 haben. Und kann dann entsprechend 459 00:24:12,660 --> 00:24:16,440 konfigurieren. Und ja, eigentlich stellt jeder 460 00:24:16,450 --> 00:24:19,290 große Cloud Provider einen fertigen Service bereit, also in 461 00:24:19,300 --> 00:24:22,770 der Welt ist das API Management in der Google Cloud Welt ist das 462 00:24:22,780 --> 00:24:26,440 Apple G es ist auch deren API Gateway. 463 00:24:27,060 --> 00:24:29,770 Die haben alle ein sehr ähnliches Set an Features und 464 00:24:29,780 --> 00:24:33,180 funktionieren alle ähnlich. Heißt schon bisschen anders, 465 00:24:33,190 --> 00:24:36,780 scheint aber vom Prinzip her ist das eigentlich immer dasselbe? 466 00:24:37,520 --> 00:24:40,320 Und was auch ganz cool ist bei vielen kann ich aber auch sagen 467 00:24:40,330 --> 00:24:44,190 ich möchte das in der Cloud irgendwie konfigurieren und dann 468 00:24:44,200 --> 00:24:47,560 aber trotzdem deployen in meine eigene Infrastruktur und das 469 00:24:47,570 --> 00:24:49,720 mache ich halt vor allem dann, wenn ich eine sehr geschätzte 470 00:24:49,730 --> 00:24:52,310 Infrastruktur habe, die vielleicht aus erreichbar ist, 471 00:24:52,590 --> 00:24:54,700 kann ich aber trotzdem diese Konfiguration dieses developer 472 00:24:54,710 --> 00:24:57,540 Portal diese Regel und sowas alles alles nehmen und die 473 00:24:57,550 --> 00:24:59,440 synchronisieren sich dann mit einem Service, der bei mir in 474 00:24:59,450 --> 00:25:04,710 der eigenen Infrastruktur läuft. Der Nachteil davon so n bisschen 475 00:25:04,750 --> 00:25:07,650 ist, dass ich das sehr schwer lokal testen kann. 476 00:25:08,420 --> 00:25:11,760 Also nehmen wir irre viel Arbeit ab und in der Regel auch 477 00:25:11,770 --> 00:25:14,570 wirklich coole Services. Aber wenn ich das lokal teste 478 00:25:14,580 --> 00:25:16,650 oder wenn ich mich super unabhängig von einem dieser 479 00:25:16,660 --> 00:25:20,490 Provider machen möchte, dann natürlich n Problem und deswegen 480 00:25:20,500 --> 00:25:23,490 gibt es auch andere Lösungen, die eben nicht von einem 481 00:25:23,500 --> 00:25:26,080 bestimmten Programmen, sondern die ich selber konfigurieren und 482 00:25:26,090 --> 00:25:29,080 hosten kann und ich glaube, die populärste draußen, die ich sehr 483 00:25:29,090 --> 00:25:32,790 gerne mag ist Kong. Übrigens hier verlinken all 484 00:25:32,800 --> 00:25:35,390 diese Lösungen auch unten in den Shows, weil ich das mal in Ruhe 485 00:25:35,400 --> 00:25:39,590 angucken möchte, aber Kong ist ein Open Source API Gateway und 486 00:25:39,600 --> 00:25:44,320 zumindest ein Opencore. AB, dass ich da schon vor Free 487 00:25:44,330 --> 00:25:47,440 starten und mir das selber irgendwohin deployen und dann 488 00:25:47,450 --> 00:25:51,400 noch selber irgendwo konfigurieren und kann dann, 489 00:25:51,410 --> 00:25:53,800 wenn ich so ein bisschen weiterführende Features nutzen 490 00:25:53,810 --> 00:25:55,560 möchte, wie zum Beispiel die Generierung eines 491 00:25:55,570 --> 00:25:59,280 Entwicklerportals. Auch Balkon die Lizenz kaufen 492 00:25:59,740 --> 00:26:01,460 oder kann auch sagen Hey Kong, Hostel? 493 00:26:01,470 --> 00:26:04,570 Doch dieses API Gateway für mich und ich zeig dir dann, wo du 494 00:26:04,580 --> 00:26:08,870 meine Services findest in bei meinem Provider der Wahl oder on 495 00:26:08,880 --> 00:26:11,920 Prem oder wo auch immer also das fand ich eigentlich ne sehr 496 00:26:11,930 --> 00:26:14,810 spannende Variante und damit kann man auch sehr gut anfangen. 497 00:26:14,820 --> 00:26:17,620 Kong integriert zum Beispiel fantastisch in Kubernetes 498 00:26:17,630 --> 00:26:21,350 Cluster also wer Kubernetes einsetzt, wahrscheinlich 499 00:26:21,360 --> 00:26:24,510 spätestens nach Paris Folge n Paar von euch das freut mich 500 00:26:24,520 --> 00:26:26,160 immer, wenn Leute mich zunächst fragen. 501 00:26:26,790 --> 00:26:29,110 Das heißt aber, das werde ich bin großer Fan. 502 00:26:30,830 --> 00:26:33,440 Dann lässt sich auch sehr nativ mit Kubernetes Board mitteln 503 00:26:33,450 --> 00:26:35,780 konfigurieren, erweitern und man kann quasi auch mit 504 00:26:35,790 --> 00:26:39,840 Qualitätsressourcen sein API Gateway konfigurieren und seinen 505 00:26:39,850 --> 00:26:42,980 Services heißt das ja auch in Inkopolis, dann auch sagen hey, 506 00:26:42,990 --> 00:26:45,050 ich möchte, dass du so und so gespottet wirst du vielleicht 507 00:26:45,060 --> 00:26:47,820 ein bisschen anders, aber du bist ja vielleicht meine meine 508 00:26:47,860 --> 00:26:51,560 Webseite will ich gar nicht teln und wie gesagt es geht nicht nur 509 00:26:51,570 --> 00:26:53,580 um Throttling, sondern auch ganz viel so um request 510 00:26:54,350 --> 00:26:58,560 Transformationen für zentrales Logging nicht wieder sehen. 511 00:26:59,270 --> 00:27:05,130 Wer von meinen Wer von meinen Konsumenten, wie oft meine APS 512 00:27:05,140 --> 00:27:07,510 überhaupt verwendet, um den dann vielleicht auch irgendwie ein 513 00:27:07,520 --> 00:27:09,210 besseres Paket anbieten zu können? 514 00:27:10,120 --> 00:27:13,120 Und wie gesagt, ich kann sowohl die von den Cloud Providern 515 00:27:13,130 --> 00:27:15,960 empfehlen, also API Management P und API Gateway. 516 00:27:16,630 --> 00:27:19,900 Als auch Kong ist auf jeden Fall, was man sich angucken kann 517 00:27:19,910 --> 00:27:22,400 und wie gesagt, dann ist man eben auch komplett kostenlos 518 00:27:22,410 --> 00:27:25,750 starten das einfach als Container lokal installiert und 519 00:27:25,760 --> 00:27:28,060 so ein bisschen damit rumspielt hat dann keine Fans die 520 00:27:28,070 --> 00:27:29,990 Oberfläche wo ich irgendwas einstellen kann, sondern alles 521 00:27:30,000 --> 00:27:33,500 irgendwie über Konfigurationen hat mir großen Spaß gemacht, 522 00:27:33,510 --> 00:27:37,650 damit zu arbeiten, was dann für mich die richtige Variante ist, 523 00:27:37,660 --> 00:27:39,960 hängt auch ein bisschen vom eigenen Use Case ab. 524 00:27:39,970 --> 00:27:42,880 Natürlich wenn man in einem der großen Public Cloud Provider 525 00:27:42,890 --> 00:27:45,370 läuft ich das natürlich nahe sich mal diese Varianten 526 00:27:45,380 --> 00:27:48,110 anzugucken. Generell muss man, glaube ich 527 00:27:48,120 --> 00:27:51,370 erstmal entscheiden. Sind SAPIS, die nur intern 528 00:27:51,380 --> 00:27:54,030 genutzt werden, verwende ich das nur innerhalb meines 529 00:27:54,040 --> 00:27:56,930 Unternehmens, dann s vielleicht auch sinnvoll. 530 00:27:57,260 --> 00:28:00,410 Direkt diesen API Gateway im gleichen Cluster zu betreiben, 531 00:28:00,700 --> 00:28:03,440 wenn ich diese Services gar nicht nach außen anbieten 532 00:28:03,450 --> 00:28:06,010 möchte, brauche ich vielleicht gar nicht so einen developer 533 00:28:06,020 --> 00:28:08,640 Portal, was auch vielleicht abrechnungs und Billing 534 00:28:08,650 --> 00:28:11,660 Funktionalitäten bietet und das ist auch ein Faktor, wo dann 535 00:28:11,670 --> 00:28:13,750 natürlich so ein Dienstleister ins Spiel kommen kann. 536 00:28:13,760 --> 00:28:16,650 Wenn ich jetzt meine Services anfange zu monetarisieren und 537 00:28:16,660 --> 00:28:19,170 habe solche subscription. Modelle da drauf und sagt hier 538 00:28:19,180 --> 00:28:22,470 du kannst wir haben, es glaube ich alle uns mal angeguckt bei 539 00:28:22,480 --> 00:28:26,310 Chat GT, da kann ich hingehen und sagen ich hol mir da so EIK 540 00:28:26,320 --> 00:28:29,320 und erlaubt es mir so viele Requests zu machen und ich muss 541 00:28:29,330 --> 00:28:32,620 dafür so viele Monat zahlen und genau das gleiche kann ich ja 542 00:28:32,630 --> 00:28:36,710 auch für meine eigenen APIS anbieten und gerade an dem Punkt 543 00:28:36,720 --> 00:28:38,950 brauche ich dann ne Abrechnungsmethode. 544 00:28:38,960 --> 00:28:42,290 Ich muss halt vielleicht ein Billiganbieter anbieten, wo sich 545 00:28:42,300 --> 00:28:44,310 die Leute nicht nur registrieren können, sondern auch ihre 546 00:28:44,320 --> 00:28:46,230 Zahlungsdaten hinterlegen. Ich brauch irgendwie eine Art 547 00:28:46,240 --> 00:28:48,060 von Rechnungsstellung, was natürlich relativ. 548 00:28:48,520 --> 00:28:51,820 Komplex ist man kann natürlich über API solche Billiganbieter 549 00:28:51,830 --> 00:28:56,140 wie Stripes selber einbinden, aber die großen Cloud Provider 550 00:28:56,150 --> 00:28:57,500 bieten wir dann teilweise direkt auch 551 00:28:57,510 --> 00:28:59,740 Abrechnungsfunktionalitäten, wo dann vielleicht andere Kunden 552 00:28:59,750 --> 00:29:02,740 dieses Cloud Providers einfach mit ihrem existierenden Account, 553 00:29:02,750 --> 00:29:05,480 den sie bei diesem Cloud Provider haben, über so ne Art 554 00:29:05,490 --> 00:29:09,110 Marketplace Modell sich dort anmelden und registrieren und 555 00:29:09,120 --> 00:29:10,980 auch abrechnen können, muss ich natürlich entsprechend 556 00:29:10,990 --> 00:29:14,240 Provisionen zahlen. An diese Anbieter Arbeit das 557 00:29:14,250 --> 00:29:16,550 nimmt natürlich hier viel ab. Das heißt ich muss mir gleich 558 00:29:16,560 --> 00:29:17,980 erstmal einfach Gedanken machen wofür. 559 00:29:18,530 --> 00:29:22,270 Berücksichtigen I Gateway nutze ich den auch für externe Nutzer 560 00:29:22,280 --> 00:29:25,610 nur intern möchte ich die Anwendung komplett in der Cloud 561 00:29:25,620 --> 00:29:28,110 betreiben und möchte ich das vielleicht auch am Ende 562 00:29:28,120 --> 00:29:32,350 monetarisieren und dann grenzt sich das n bisschen ein aber ich 563 00:29:32,360 --> 00:29:34,630 glaub, die erste Entscheidung ist halt wo läuft meine 564 00:29:34,640 --> 00:29:36,990 Anwendung und wofür verwende ich diesen API? 565 00:29:37,000 --> 00:29:40,660 Gateway ganz genau vielleicht noch eine letzte Sache, die mir 566 00:29:40,670 --> 00:29:45,080 wichtig ist, ist, dass wir noch ganz gut da Security schauen, 567 00:29:45,500 --> 00:29:47,750 weil ich auf jeden Fall nicht unerwähnt lassen möchte ist 568 00:29:47,760 --> 00:29:50,280 natürlich müssen irgendwo diese Microservices, die ich habe. 569 00:29:50,500 --> 00:29:52,330 Auf meinem API Gateway vertrauen. 570 00:29:52,960 --> 00:29:56,120 Weil die ja dann mehr oder weniger oder so auf jeden Fall 571 00:29:56,130 --> 00:29:59,180 weniger geschützt unterwegs sind, weil sie sich auf den 572 00:29:59,190 --> 00:30:00,630 Schutz von diesem PI Gateway verlassen. 573 00:30:00,640 --> 00:30:03,820 Das heißt, ich muss natürlich sicherstellen, dass die nur von 574 00:30:03,830 --> 00:30:07,680 dem API Gateway angesprochen werden können, am besten über 575 00:30:07,720 --> 00:30:10,390 wenn nicht kann mache ich das über das Netzwerk fest, dass wir 576 00:30:10,440 --> 00:30:12,770 hier im privaten Netzwerk sich einfach nur befinden und gar 577 00:30:12,780 --> 00:30:14,830 nicht von außen irgendwie erreichbar sind und nur von den 578 00:30:14,840 --> 00:30:18,420 EIG erreichbar sind. Und das lässt sich natürlich 579 00:30:18,430 --> 00:30:20,730 aber auch da sind lässt sich so Trust Relationship auch 580 00:30:20,740 --> 00:30:24,120 herstellen, indem zum Beispiel die Verbindungen verschlüsselt 581 00:30:24,130 --> 00:30:28,140 oder mit einem Zertifikat arbeite, was das API Management 582 00:30:28,180 --> 00:30:31,300 hinterlegt bekommt und was dann die meine Microservices oder 583 00:30:31,310 --> 00:30:34,440 meine Services generell akzeptieren also das ist ein 584 00:30:34,450 --> 00:30:37,520 ganz wichtiger Punkt ist natürlich dann auch das Ganze so 585 00:30:37,530 --> 00:30:40,750 konfigurieren muss, dass wenn ich den ganzen Schutz als i Gay 586 00:30:40,760 --> 00:30:45,020 auslagern, die Microservices System API vertrauen oder auch 587 00:30:45,030 --> 00:30:48,790 nur dem API Gateway vertrauen. Das noch als kleinen Security 588 00:30:48,800 --> 00:30:51,470 Disclaimer wunderbar ich glaube, dann haben wir sowohl die 589 00:30:51,480 --> 00:30:53,820 technischen Aspekte die Hintergründe beleuchtet, warum 590 00:30:53,830 --> 00:30:56,930 man sowas braucht, haben ein paar Varianten besprochen, wie 591 00:30:56,940 --> 00:30:59,930 man sowas bereitstellen kann. Uns würde natürlich 592 00:30:59,940 --> 00:31:02,410 interessieren habt ihr selber Erfahrungen mit solchen 593 00:31:02,420 --> 00:31:03,870 Gateways? Welche verwendet ihr? 594 00:31:03,880 --> 00:31:06,770 Da könnt ihr vielleicht auch bestimmte Dinge empfehlen, 595 00:31:06,780 --> 00:31:09,770 schreibt uns da gerne eine Email, sind wir natürlich wie 596 00:31:09,780 --> 00:31:13,130 immer sehr daran interessiert und wenn wir da Feedback 597 00:31:13,140 --> 00:31:15,100 bekommen, teilen wir das natürlich auch gerne mit der 598 00:31:15,110 --> 00:31:18,380 Community im Rahmen einer. In den nächsten Folgen 599 00:31:18,420 --> 00:31:20,660 beleuchtet Podcast gefallen hat dann lasst uns auch gerne 600 00:31:20,670 --> 00:31:23,740 Bewertung, da ihr können sich sowohl auf Spotify auf Apple 601 00:31:23,750 --> 00:31:26,580 Podcast Daumen Sternchen weiß, auch immer geben. 602 00:31:27,000 --> 00:31:29,680 Wir freuen uns immer, wenn die Kommentare hinterlassen können, 603 00:31:29,690 --> 00:31:32,190 das natürlich aber auch über die E Mail Adresse, die unten in der 604 00:31:32,230 --> 00:31:35,160 Beschreibung von diesem Podcast steht privat machen, wenn ihr 605 00:31:35,170 --> 00:31:37,440 uns so Feedback hinterlassen wollt oder ne Frage habt oder 606 00:31:37,450 --> 00:31:39,880 was auch immer, dann freuen wir uns immer sehr über die 607 00:31:39,890 --> 00:31:43,050 Diskussionen. Lasst uns also gerne wissen und 608 00:31:43,060 --> 00:31:45,700 ansonsten freuen wir uns, wenn ihr auch in 2 Wochen wieder 609 00:31:45,710 --> 00:31:48,090 dabei seid. Denn der Lukas erscheint alle 2 610 00:31:48,100 --> 00:31:50,300 Wochen. Bis dahin schreibt ganz viel 611 00:31:50,310 --> 00:31:53,820 Code ab ganz viel Spaß auf 2 tolle Wochen und bis ganz bald 612 00:31:53,830 --> 00:31:54,480 bis dahin.