Od integracji do inteligencji API Management w transformacji AI

Cześć, witamy w Powered By Protopia. Ja jestem Szymon Warda, ze mną jest Marek Grabasz i porozmawiamy dzisiaj o API Management. Cześć wszystkim. Tak, to jest drugi odcinek naszej serii o agentach. No i Marku, na poprzednim odcinku Łukasz i Mikołaj rozmawiali o agentach. Mówiliśmy jak je ustawić, po co są i cały kontekst w ogóle agentowy. Nagle mamy taki przeskok i mówimy nagle o API Management. Czemu właściwie? Czemu się tym interesujemy i czemu tak wcześnie wprowadzamy go? Na poprzednim odcinku Łukasz podkreślił, że API Management jest de facto sercem tych wszystkich systemów agentowych, tych platform agentowych. W rzeczywistości tak mamy do czynienia z pewnymi źródłami danych. No i agent sam w sobie, czy też LLM przede wszystkim będzie generował pewne treści w oparciu o dane, które mu dostarczymy.

Oczywiście możemy powiedzieć, że API samo w sobie nie będzie wymagane, jeżeli budujemy jednego agenta, ponieważ te dane, które będą mu potrzebne, być może jesteśmy w stanie wygenerować, wyekstrahować, wyciągnąć z tych systemów i je po prostu dostarczyć w formie takiej powiedziałbym statycznej. Jeżeli potrzebujemy jakieś dynamiki, czyli te dane gdzieś tam pod spodem się nam dynamicznie zmieniają i te akcje, które będziemy wykonywać są też de facto dynamiczne, to tutaj API będzie takim elementem powiedziałbym krytycznym i kluczowym, ale to jest jeden aspekt. Drugi aspekt to jest to, czy my budujemy jednego agenta, dwóch, czy budujemy ich całą masę, czy budujemy taką powiedziałbym fabrykę agentów, które będą służyć naszej organizacji. Jeżeli mamy do czynienia z tym drugim przypadkiem, to ja bym powiedział, takim elementem kluczowym będzie właśnie platforma API Management, o której dzisiaj będziemy troszkę jeszcze więcej rozmawiać.

Dlaczego? Bo tak naprawdę mamy w sposób ustandaryzowany, usystematyzowany, dostarczamy te API do agentów, tak? Oczywiście. Dobrze, ale teraz tak jeszcze tutaj popytam cię. No bo ustandaryzujemy to API. W kontekście naszej fabryki agentów, czyli mówimy o większej skali, to ta wartość płynie z czego? Że mogę w apps archować? Mogę tą złożoność tych systemów ukryć, z którymi ci agenci komunikują? Gdzie wartość wynika wprowadzenia API w management? Tak, to... Też na pewno wejdziemy w temat samego API Management, jak on działa, jak jest skonstruowany. Natomiast troszkę wyprzedzając te detale, moglibyśmy powiedzieć, że API Management robi to w sposób taki, powiedziałbym, standardowy. Czyli każdorazowo, kiedy chcemy się zintegrować z API danym, na przykład budujemy coś w e-commerce, chcielibyśmy mieć dane produktów i tak dalej.

Moglibyśmy z poziomu każdego agenta się integrować do tego API. To może skutkować tym, że poszczególne grupy twórców tych agentów będą wykonywać tę samą mrówczą pracę, czyli tę samą integrację, te same, że tak powiem, dane będziemy się stali wyciągnąć w różnych miejscach, w różnych systemach, prawda? API to systematyzuje, a API Management sprawia, że możemy reużywać tego API w różnych miejscach. To jest jeden z argumentów, powiedziałbym. Natomiast jest cała masa rzeczy dodatkowych, które są istotne z punktu widzenia szczególnie organizacji dużych, dużych firm, powiedziałbym takich Enterprise'ów. To jest wspólna fasada bezpieczeństwa, wspólna fasada ogarnięcia tego w sposób sieciowy, gdzieś tam zamknięty. Czyli te API nie są wystawione raz tu, raz tam, do publicznego internetu, gdzieś tam do wnętrza.

Mamy ten API Management i on to w sposób ustandaryzowany sieciowo i bezpiecznikowo wystawia. Czyli chcę powiedzieć, że robimy w tym momencie integrację każdego API raz, a dobrze. Skoro podłączamy do API, to API daje nam w tym momencie wspólny interfejs, mimo że pod spodem systemy rozwijałem po różnych protokołach, mogą być różne protokoły, różne sposoby uwierzytelniania, bardzo wiele różnych rzeczy, a w tym momencie nasza fabryka agentów ma jeden spójny protokół, komunikację, API do komunikacji. Tutaj się pojawia ciekawy aspekt, ponieważ taka platforma jak API Management jest w stanie wystawiać te API nie tylko w takiej formie powiedziałbym typowo REST na przykład, czy gier PC, czy być może inaczej, ale jest w stanie wystawić te API w sposób zrozumiały dla agentów, czyli w postaci tak zwanych serwerów MCP.

Czyli naszym zadaniem dla API będzie wystawić to na fasadzie w taki sposób i opisać te wszystkie endpointy, wszystkie poszczególne, że tak powiem, operacje, akcje, czy też wywołania, które będziemy robić, w sposób zrozumiały dla agentów. No bo zadajmy sobie takie pytanie. Gdybym ja wystawił jakieś API, nie wiem, getCustomer, getProduct i tak dalej, brzmi to dość naturalnie dla mnie, dla ciebie. Natomiast jeżeli te operacje biznesowe wystawione przez API będą nieco bardziej skomplikowane, No to ani ja, ani ty na podstawie samej nazwy tego endpointa nie jesteś w stanie zdeterminować, co to API będzie robić, co ten endpoint będzie robić. Teraz jak my to opiszemy w takim API Management i dostarczymy do agenta nie tylko końcówki tych API, ale również pełny opis zrozumiały dla agenta.

To w dużym stopniu jest prawda, natomiast warto też pamiętać, że API Management jest taką fasadą, punktem wejścia, gdzie mamy wspólny monitoring, wspólne bezpieczeństwo, rozliczanie tak naprawdę. Natomiast nie zawsze jest tak, że API Management wchodzi gdzieś tam głęboko do jakiegoś SAPa, do bazy danych i tak dalej. Do tego w dalszym ciągu potrzebujemy gdzieś pod spodem czegoś, co my w tej nomenklaturze chmurowej nazywamy Integration Platform as a Service. O tym też będziemy jeszcze chwilę mówić dzisiaj. Natomiast rzeczywiście to jest tak, to jest ten wspólny punkt wejścia, wspólny ustrukturyzowany i powiedziałbym ustandaryzowany sposób komunikacji agentów z naszymi wewnętrznymi systemami. Trochę zaczęłaś właśnie mówić o tym, że API to nie tylko są agenci tak naprawdę.

Jak mi jeszcze wartość daje wdrożenie API w organizację API Management? Generalnie można powiedzieć, że pojawił się taki koncept, no myślę, że już 10 lat jest z nami, takie pojęcie API Economy, ekonomia API i to jest takie powiedziałbym typowo zarządcze, menedżerskie określenie tego, co API jest nam w stanie dostarczać, tak? Jak sobie patrzymy na te systemy, możemy o nich myśleć w sposób właśnie jakiejś wartości, która została wybudowana wewnątrz organizacji, prawda? I teraz tę wartość chcielibyśmy w jakiś sposób monetyzować. I nie mam na myśli tutaj wystawiania API jako, nie wiem, software as a service gdzieś tam na zewnątrz i sobie tam sprzedajemy za użycie tego API. Bardziej monetyzujemy je wewnętrznie w naszej firmie, czyli

Dzięki niemu, dzięki tej API Economy jesteśmy, znaczy ta koncepcja to tak to opisuje, że jesteśmy w stanie wystawiać pewne dane i później na nich budować kolejne systemy i kolejne, kolejne gdzieś tam nadbudówki, dzięki któremu budujemy jakieś tam dodatkową wartość wewnątrz firmy. I nie tylko, również zewnątrz. Ale to teraz trochę żebyś to wybrzmiało. Czemu właściwie... Komunikując się z takim serwisem, który mamy w organizacji, który, jak powiedziałeś, dostarcza pewną wartość, pewną wiedzę, to czemu mamy korzystać właśnie z API Management w tym momencie, tak komunikować się przez niego, a nie z tym serwisem bezpośrednio? Co taką wartość niesie w tym momencie API? Myślę, że zanim odpowiem na to pytanie, chwilę bym powiedział, czym jest API Management, bo myślę, że to jest kluczowe do tego, żebyśmy mniej więcej zrozumieli, co ten API Management nam będzie wnosił.

Więc w dużym uproszczeniu, jeżeli mówimy konkretnie o usłudze Azure API Management, możemy powiedzieć, że ona się składa z trzech takich głównych komponentów, w dużym uproszczeniu. Z jednej strony mamy portal do zarządzania, my to technicznie nazywamy takim powiedziałbym control planem, czyli takim miejscem, gdzie my definiujemy te API, a raczej je importujemy, raczej je konfigurujemy, bo te API gdzieś tam istnieją wewnątrz firmy, prawda? Więc tam je dokładamy, tam je w odpowiedni sposób za pomocą polityk opisujemy, czyli na przykład, że można wejść tylko wtedy, gdy się jest w jakiejś tam grupie Active Directory na przykład, albo że one są w jakiś sposób zabezpieczone. Definiujemy tam monitoring, definiujemy tam różne mechanizmy, nie wiem, rate-limitingowe, czyli na przykład ile razy w ciągu minuty czy sekundy takie API dany system może zawołać i tak dalej i tak dalej.

gdzie dowiadujemy się, jak to wszystko wygląda. I trzecia rzecz to jest samo to API. Tutaj mówimy bardziej o tym, że taką końcówkę gdzieś tam wystawiamy i te systemy, czy to agentowe, ale nie tylko, bo tak naprawdę o agentach mówimy od raptem roku. Systemy takie jak API Management istnieją już od lat. I się wdrażaliśmy. I się wdrażaliśmy niejednokrotnie w różnych branżach. Więc mamy aplikacje na przykład mobilne, mamy wewnętrzne aplikacje line of business, mamy jakieś portale, mamy nawet aplikacje desktopowe, które są na koniec dnia gotowe do tego API dzwonić. Dostawać, czy też produkować jakąś wartość poprzez to API. Ok, czyli tak właściwie wartość, którą to API nam dostarczy, to jest to, że mamy widoczność tego, co jest w naszym systemie.

Co ja widzę, jeszcze taki powtarzający się, powiedziałbym, wzorzec zachowań albo użycia tego API Management, mianowicie często firmy, z którymi współpracujemy, No to też jest branża regulowana. Mają dość mocno powiedziałbym skonfigurowane i dokręcone. Zasady security, bezpieczeństwa i zasady sieciowe. Co to oznacza? To znaczy, że jeżeli mamy jakieś systemy w jednym miejscu i mamy jakieś API w innym miejscu, to dość ciężko będzie przejść całą ścieżkę, powiedziałbym, taką dyskusji z działem bezpieczeństwa, z siecią, z compliance i tak dalej i tak dalej. Kto z kim może rozmawiać w tej naszej siateczce połączeń? Kiedy wystawimy pewną wspólną część między nimi, jesteśmy w stanie dość łatwo z wyprzedzeniem wybudować pewne przejścia sieciowe, pewne zgody, pewne kontrakty bezpieczeństwa i dzięki temu mówimy agenci do API, API do poszczególnych API i te dwie ścieżki są wytrasowane.

Czyli to jest taki whitelisting naszych API wewnętrznych, kto z kim może konsumować. W pewnym sensie tak. Załóżmy, jakie staw danych może konsumować, kto co widzi, dokładniej widzimy, nasz compliance w organizacji jest bardzo prosty, jest to w jednym miejscu. No i mamy rozliczanie, mamy widoczność, mamy monitoring, mamy zgodę bezpieczeństwa, że tak to jest wystawione. Natomiast to jest jeden z przypadków. Drugi przypadek to jest, kiedy API Management, nie mówię całościowo, może częściowo, wystawiamy również na zewnątrz. To nam otwiera jeszcze inne perspektywy w organizacji, to znaczy wystawiamy API do integracji zewnętrznej, czyli, nie wiem, jakieś... Partnerzy nasi biznesowi, czy jakieś firmy, nie wiem, startupy i tak dalej, mogą nagle dostać się do naszych wewnętrznych danych, oczywiście spełniając pewne, nie wiem, kontrakty, zgody, dostępy i tak dalej, ale takie firmy są w stanie konsumować tę informację, którą my celowo dla nich będziemy wystawiać i dzięki temu też w ramach tego API Economy budujemy pewną nową wartość biznesową.

Otwieramy pewne nowe kanały komunikacji, sprzedaży, być może To prawda, jest taki mechanizm, nazywa się produkty i on rzeczywiście brzmi bardzo mocno SAS-owo. Natomiast jest to mechanizm, który bardzo często jest używany w ramach API Management, gdzie my Grupujemy pewne API i opisujemy to jako np. integracja z jakimiś tam typami systemów i taki produkt jest następnie może nie tyle kupowany, co po prostu podpinany dla danego konsumenta, dla danej firmy, dla danego projektu, który będzie gdzieś tam tego zestawu API różnych używał.

Notabene jeszcze taki side note. Te produkty mogą grupować te API w różnych, że tak powiem, konfiguracjach. To nie jest tak, że jedna API do jednego produktu tyle, albo w jednym produkcie mamy ileś API. Te same API mogą występować w różnych miejscach, tak żeby była jasność. No i teraz jak mamy te produkty, no to w sposób ustandaryzowany pozwalamy się tym konsumentom uwierzytelniać. Autoryzujemy ich w odpowiedni sposób. No i mamy to co Ty mówiłeś, czyli ta facada takiej powiedziałbym tłumaczenia pomiędzy tymi wystawionymi API w sposób standardowy, a tymi systemami wewnętrznymi, które mogą mieć różne interfejsy, jakieś sołpy, nie sołpy, no różne rzeczy tam bywają. Jasne, dobre Marku, ale powiedzmy, że w tym momencie mówimy w kontekście Azure API Management.

Mówimy też o organizacjach, które są duże. Część będzie miało, części z racji konieczności prawnych nawet, systemy, które są non-premie. Czyli co w tej sytuacji w ogóle? Czy idzie do odstawki, czy mamy jakieś możliwości? To jest dobre pytanie. I to rzeczywiście z naszego doświadczenia, kiedy my jako Protopia wdrażamy systemy API Management, to powiedziałbym w takim W trybie pół na pół wdrażamy to w modelu hybrydowym. Co to oznacza? To oznacza w dużym uproszczeniu, że cały czas w chmurze mamy tę część portal dewelopera i ten, nazwijmy to, content management, czy też control plane, czyli tam, gdzie konfigurujemy API. Tam możemy o tym jeszcze chwilę porozmawiać, o automatyzacji, jak to robimy. Natomiast samo wystawienie API może się odbywać zarówno w chmurze, i to jest tak zwany Cloud Gateway,

Albo w dowolnej lokalizacji on-premises czy w innej chmurce. I to się nazywa self-hosted gateway. Co to znaczy self-hosted? To jakby sama nazwa mówi już nam, że my musimy sami postawić ten gateway, czyli to wejście do naszych API. To jest zwykle hostowane w postaci kontenera, który to kontener, jego obraz jest dostępny bezpośrednio gdzieś tam w Microsoft. Możemy sobie taki obraz ściągnąć i taki kontener zwykle jest osadzany na W infrastrukturze wewnętrznej klienta i tak naprawdę zyskujemy jeszcze dodatkową rzecz, czyli nie tylko to, że integrujemy się z tymi systemami wewnętrznymi, nie mamy tych przeskoków sieciowych, bo nagle się okazuje, że zarówno aplikacja, która chce korzystać z tego API, jak i samo API znajdują się gdzieś tam

O tym będzie. Na pewno. Czyli tak, to co włapałem, co jest dla mnie bardzo istotne z perspektywy, to jest to, że API Management daje możliwość nam nie tylko wciągnięcia naszych, powiedzmy, chmurowych, nowoczesnych aplikacji, ale też tych on-premowych. I to w dwójaki sposób. Po pierwsze w komunikację na zewnątrz, ale po drugie to jest to, że je też wciągamy bardzo ładnie i możemy wykorzystywać w platformie, o której właśnie rozmawiał Łukasz Mikołaj. I w tym momencie mamy całą komunikację zrobioną bezpiecznie, compliance'owo i o nic się nie martwimy. To jest jeden punkt kontrolny, gdzie wszystko jest i dla nas Co więcej, jak mamy to API osadzone lokalnie, przepraszam, API Management, Gateway API Management, to możemy być zgodni z podejściem firmy, na przykład do tego, że jeżeli chcemy te API wystawić na zewnątrz, to nie wystawiamy je z chmury, gdzie ta chmura jest, nie wiem, jakiś West Europe, Amsterdam, czy może jakieś inne lokalizacje centrów danych, to wystawiamy je lokalnie, bo tak naprawdę, jeżeli mamy to schostowane na jakimś Kubernetesie czy maszynie wirtualnej, wystawiamy to na naszym, że tak powiem,

Od integracji do inteligencji API Management w transformacji nbsp AI. Od integracji do inteligencji API Management w transformacji nbsp AI. I to mnie interesuje, bo mówimy o różnych możliwościach, co można zrobić. A tak realnie, to jak klienci, którzy klienci, jak wykorzystują... Tutaj nas klientów pewnie zdradzać nie powinniśmy, natomiast na jednym z następnych nagrań będziemy mieć kolegę z jednej z organizacji, z którym będziemy rozmawiać na ten temat. Natomiast myślę, że istotne byłoby określić, jakie wartości ci klienci poszczególni uzyskują w ramach wdrożenia API Management.

Ciekawa rzecz jest taka, że już wspomniałem, agentów mamy do jakiegoś czasu, natomiast zwykle i historycznie to było tak, że istniała pewna potrzeba, nabrzmiała potrzeba, która polegała na tym, że mamy tych API całą masę i chcemy coś z tymi API zrobić, usystematyzować, ogarnąć. W jaki sposób wystawić je w sposób zcentralizowany? Tutaj często pojawia się taka funkcja albo taka grupa ludzi, którzy nazywają się zespołem integracyjnym, która potrzebuje sobie uprościć życie i pracę. To jedna rzecz. I rzeczywiście, patrząc na takie podejście API Management, Zapewniamy to, że firma wreszcie wie jakie API ma, czyli ma taki powiedziałbym inwentarz tych wszystkich elementów, które gdzieś tam produkowała przez rok, dwa, pięć, dziesięć i piętnaście.

I często gęsto oprócz samego API Management my jeszcze mamy Taki element, który się nazywa Azure API Center, czyli takie powiedziałbym, ja to nazywam CMDB dla API w jakiś sposób, albo taki powiedziałbym katalog, gdzie my te API mamy i one niekoniecznie muszą być wystawione na API managemencie, one mogą być wystawione bezpośrednio, one mogą być gdzieś, natomiast my jesteśmy w stanie je opisać, jesteśmy dostarczyć w stanie Pewne opisy maszynowe, tak jak Swagger czy Open API. No i ostatnia rzecz, jesteśmy w stanie wdrożyć pewne mechanizmy governance, czyli takiego powiedziałbym zarządzania typem API. I tutaj przykładem jest na przykład linting. Takie pojęcie dość techniczne, ale pewnie nasi słuchacze słyszeli w kontekście kodu na przykład, który jest tworzony w ramach programowania, że robimy analizę tego kodu.

Czyli prowadzisz po prostu cały czas walkę ze scenami wiki, które opisują co, jak, gdzie, się, z kim... No może ja nie, no bo my jako Protopia głównie wdrażamy, budujemy te procesy, czy też ten linting, czy APIOps, to sobie wstawię za chwileczkę, bo o tym też warto wspomnieć. Natomiast no to te zespoły integracyjne, to... Powiedziałbym, ci ludzie, te grupy, które chcą te API wystawiać, one mają tę odpowiedzialność, żeby jednak się dostosować. Masz rację, dajesz narzędzia, żeby walczyć ze sonamifiki. No i narzędzie APIOps. Ciekawa rzecz. Zdarzało nam się już parokrotnie coś takiego robić. Mianowicie, kiedy mówimy o API Management, możemy wdrożyć infrastrukturę, tak? To o tym już mówiliśmy.

W związku z tym promujemy takie podejście, które nazywa się w świecie API Management Microsoftu APIOps. Coś podobnego do GitOpsa w ramach Kubernetesa, czyli mamy repozytorium kodu, w którym te wszystkie polityki, integracje, całe API są Wspięte i skonfigurowane. I my tylko promujemy tę konfigurację w górę do kolejnych środowisk. Czyli wdrażamy taki proces dojrzałości niejako API. To samo, co powinniśmy mieć w procesach deweloperskich, bo też wychodzimy na poziomie API, że w tym momencie możemy pilnować i więcej, więcej mamy to w formie tekstu i wiemy, co się działo. I dajemy, tak, znaczy to, że to jest w Gitie i mamy historię zmian, kto, kiedy, gdzie i dlaczego to zmienił, to jest jedna rzecz. Natomiast troszkę zdejmujemy bagaż albo to obciążenie z tego zespołu integracyjnego, no bo oni w którymś momencie staliby się wąskim gardłem.

To brzmi jak dość dużo funkcji, które Bardzo mocno stanie odciążyć właśnie nasz zespół centralny, który staje się trochę centralnym i nagle to, co powiedziałeś, rozpraszamy tą wiedzę i oni stają się tylko weryfikatorami, a inni mogą te rzeczy prowadzać, czyli usuwamy to wąskie gardło, które jest bolączką chyba każdej dużej organizacji, która ma wspólne API. Pełna zgoda, natomiast też wydaje mi się, że dla naszych słuchaczy może to brzmieć troszkę przytłaczająco. Ile rzeczy my jesteśmy w stanie zrobić i chcemy zrobić? To też nie jest rzecz, którą się robi z dnia na dzień. To jest pewien proces, pewna droga, którą my chcemy przejść. No i przechodziliśmy ją wielokrotnie i nagle się okazuje, że po wdrożeniu tego API Management to wszystko, co było w przeszłości, mamy w przeszłości. Teraz mamy teraz agentów i nagle przychodzą ci agenci i on, taki agent, albo my tworzymy takiego agenta, który to na przykład ma opisać produkty, które są dostępne w ramach naszego, nie wiem, tam hurtowni na przykład, tak?

Albo potrzebuje złożyć zamówienie i nagle jak te API są wystawione, no to ten agent Zapytaj mi o listę produktów w kategorii takiej czy śmakiej. Dołóż mi taki do koszyka, sprzedaj mi taki. Zaczyna to działać. Patrzę na prawidłowość, że jeżeli raz wstawiliśmy API dobrze, to potem mogliśmy się łatwiej integrować. Przyszli agenci i powiedzieliśmy, że w sumie musimy wiele robić właściwie. API mnoży nam automatycznie MCP i właściwie API, to co robiliśmy wcześniej, możemy wykorzystać teraz tak naprawdę. Czyli jak nam przyjdzie kolejna rzecz, to właściwie API już mamy zrobione. Co więcej, to API wcześniej wystawiliśmy w postaci, nie wiem, REST'owej czy jakiejś innej i obecnie w API Management jest taki, powiedziałbym, checkbox, może to uproszczę, tak? Czyli na zasadzie wystaw też jako MCP.