Od integracji do inteligencji API Management w transformacji AI

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. Kiedyś pracowałem w takich firmach, gdzie rzeczywiście było tak, że jeżeli ktoś chce API na przykład wystawić, to musi się jakiś tam architecture review board zapisać za dwa tygodnie i oni to rozpatrzą. Podczas tego rozpatrywania taką długą, że tak powiem listę życzeń dadzą Że to do zmiany, to do poprawy i ten proces trwa dwa, trzy, cztery miesiące, a mówimy o tylko prostej iteracji, tak? I okazuje się, że głównym takim powiedziałbym miejscem, gdzie ktoś tam się może nie tyle włamuje do infrastruktury, co po prostu wykorzystuje nasze systemy, próbuje sobie tam nabić jakieś punkty, czy gdzieś tam się dostać, to jest właśnie to API.

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.

Natomiast, żeby wyjść troszkę dalej, wykonać krok do przodu, będziemy chcieli podłączyć się do pewnych źródeł informacji dostępnych w ramach firmy, w ramach organizacji. I będziemy się starali również automatyzować pewne kroki czy też akcje, które wynikają z tego, co ten agent będzie chciał podjąć. No i teraz pojawia się pytanie, w jaki sposób dostarczamy te źródła danych i w jaki sposób automatyzujemy te następne kroki. I powiedziałbym taką preferowaną formą komunikacji agenta z wewnętrznymi systemami Jest ustandaryzowana, powiedziałbym, komunikacja przez właśnie API, Application Programming Interface. Ok, ale tak żeby dać kontekst, bo o jakiej skali mówimy? Czy API jest wymagane, jeżeli mamy tych agentów 1, 2, 3? Czyli w jakim kontekście ono ma sens?

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.

Tutaj taki powiedziałbym doświadczenie z pola bitwy w Protopii jest takie, że my staramy się wręcz LLM-ami Poprosić LLM-a, żeby opisał endpointy w sposób zrozumiały dla siebie, czyli dla agenta, żeby później taki agent, mając opisy poszczególnych końcówek, wiedział dokładnie, którą i w jaki sposób użyć. Czyli ja mogę, dzięki API-mowi, zacząć używać moje stare systemy, nie modyfikując ich, i dodać im możliwość komunikacji się, żeby te systemy komunikowały się z agentami, poprzez właśnie protokół MCP, nie ruszając ich sam w ogóle, tak naprawdę. Za pomocą API-ma jest to moją warstwą integracji, która tłumaczy potencjalnie różne stare, może nowsze, różne systemy, do tego, żeby uczestniczyły w mojej fabryce agentów i były używane.

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.

Tych polityk jest cała masa dostępnych, więc control plane to jest miejsce, gdzie wystawiamy API. Albo raczej definiujemy. Z drugiej strony mamy coś, co się nazywa Developer Portal, czyli jest to taka, powiedziałbym, zwizualizowana forma tego, co my w ramach tych API określiliśmy i wystawiliśmy. I każdy pracownik, czy też może jakiś programista, czy członek zespołu, który będzie z tym API się integrował, ma prawo tam wejść. I zrobić takie powiedziałbym discovery, czyli poodnajdywać te API, które tam się znajdują, zobaczyć jak one są opisane, jakie mają końcówki, jaką wartość biznesową są w stanie dostarczyć, w jaki sposób musimy się do tego uwierzytelnić, w jaki sposób to zawołać, ile razy możemy i tak dalej i tak dalej. Czyli taki powiedziałbym wizualny portal.

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.

Dokładnie wiemy, co, gdzie, w jednym miejscu. Odkrywalność, wiemy jak, opisy, dokumentacja, definicje, wszystko jest zgromadzone w jednym miejscu. Mamy translację wszystkich API, czyli nie martwimy się jak, do którego systemu musimy się dobić, tylko nas informuje to, że jak się komunikujemy za PIM-em, więc możemy iść, podnosić możliwości układu wyżytelniania, itd., itd., zostawiając te starsze systemy potencjalnie w spokoju i już nie martwimy się tym. Czyli mamy ujednolicone, każdy komunikuje się tak samo, my wiemy. Widać też interesujące rzeczy, mianowicie, że deweloper, który chce się integrować, On musi powiedzieć kto, kim jest, jak się będzie integrował, dzięki czemu widzimy kto do tego systemu korzysta. Czyli nawet w kontekście wewnętrznego użycia wiemy kto jaką konsumpcję... Ma wewnętrzną. I w tym momencie też widzimy cały monitoring, rate limiting i wszystko, czyli kontrolujemy, co się dzieje wewnątrz naszej organizacji, że nie mamy komunikacji każde z każdym, tylko mamy jedną bramkę, gdzie mamy wszystkie informacje o tego, co się w ogóle dzieje z naszymi systemami.

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

W prywatnym centrum danych. Gdybyśmy mieli bramkę chmurową, to wywołanie byłoby tak, aplikacja do chmury, chmura dzwoni do API, API zwraca do naszego API Gateway, a z powrotem z chmury leci nam odpowiedź. Mając tę bramkę lokalnie, możemy tę komunikację, powiedziałbym, zostawić lokalnie, czyli mamy latency, ograniczamy koszty transferu danych gdzieś tam do chmury z powrotem. No i ostatnia rzecz, która jest niezwykle istotna, to jest ten compliance, ta zgodność z tymi, że na przykład dane, nie wiem, bankowe, dane... Medyczne. Medyczne, dane ubezpieczeniowe nie opuszczają w żaden sposób tego prywatnego data center, ta komunikacja zostaje wewnętrznie, a tam tylko mamy monitoring, ewentualnie jakieś observability, które ty pewnie lubisz, bo to jest twój temat.

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.