API Management jako brama agentów AI do systemów firmy

Pierwszego agenta można zintegrować z systemami bezpośrednio, bez API Management. Chodzi o agenta próbnego, testowego albo takiego, który ma przekonać zarząd, że agenci dają wartość.

Jeśli firma przeszła z twardych integracji po bazach danych na API, musi zadbać o bezpieczeństwo samych API. W dużym uproszczeniu OWASP API Security Top 10 układa zagrożenia według szkodliwości, częstości występowania i łatwości wykorzystania dziury. Jeśli wszystkie te czynniki są wysokie, zagrożenie trafia na szczyt listy.

Platformy razem z APIOps, lintingiem i standardami API nie wprowadza się z dnia na dzień. To proces, który Protopia przechodziła już wielokrotnie.

Marek Grabarz: Jeżeli potrzebujemy dynamiki, czyli dane pod spodem dynamicznie się zmieniają, a akcje, które będziemy wykonywać, też są dynamiczne, to API będzie elementem krytycznym i kluczowym. Kiedyś pracowałem w firmach, w których ktoś, kto chciał wystawić API, musiał się zapisać na architecture review board za dwa tygodnie, a oni to rozpatrywali. Podczas tego rozpatrywania dawali długą listę życzeń: to do zmiany, to do poprawy. Ten proces trwa dwa, trzy, cztery miesiące, a mówimy tylko o prostej iteracji. I okazuje się, że głównym miejscem, przez które ktoś może nie tyle włamać się do infrastruktury, co po prostu wykorzystać nasze systemy, nabić sobie punkty czy gdzieś się dostać, jest właśnie API.

Szymon Warda: Cześć. Witamy w Powered by Protopia. Jestem Szymon Warda, ze mną jest Marek Grabarz. Porozmawiamy dzisiaj o API Management.

Marek Grabarz: Cześć wszystkim.

Szymon Warda: To drugi odcinek naszej serii o agentach. Marku, w poprzednim odcinku Łukasz i Mikołaj rozmawiali o agentach: jak je ustawić, po co są, cały kontekst agentowy. I nagle mamy przeskok i mówimy o API Management. Czemu interesujemy się tym tematem i czemu wprowadzamy go tak wcześnie?

Marek Grabarz: W poprzednim odcinku Łukasz podkreślił, że API Management jest sercem wszystkich systemów i platform agentowych. W rzeczywistości mamy do czynienia ze źródłami danych. Agent sam w sobie, czy też LLM, przede wszystkim generuje treści na podstawie danych, które mu dostarczymy. Żeby zrobić krok dalej, będziemy chcieli podłączyć się do źródeł informacji dostępnych w firmie i automatyzować kroki czy akcje, które wynikają z tego, co agent chce zrobić. Pojawia się pytanie, jak dostarczamy te źródła danych i jak automatyzujemy następne kroki. Preferowaną formą komunikacji agenta z wewnętrznymi systemami jest ustandaryzowana komunikacja przez API, czyli Application Programming Interface.

Szymon Warda: Dobrze, ale żeby nadać kontekst: o jakiej skali mówimy? Czy API jest wymagane, jeżeli mamy jednego, dwóch, trzech agentów? W jakim kontekście ma sens?

Marek Grabarz: Oczywiście API samo w sobie nie będzie wymagane, jeżeli budujemy jednego agenta. Dane, których potrzebuje, być może jesteśmy w stanie wyekstrahować z systemów i dostarczyć w formie statycznej. Jeżeli potrzebujemy dynamiki, czyli dane pod spodem się zmieniają, a akcje też są dynamiczne, to API będzie elementem krytycznym i kluczowym. To jeden aspekt. Drugi to to, czy budujemy jednego agenta, dwóch, czy całą masę, czyli fabrykę agentów, która będzie służyć organizacji. W tym drugim przypadku elementem kluczowym będzie platforma API Management, o której dzisiaj porozmawiamy. Dlaczego? Bo dostarczamy API do agentów w sposób ustandaryzowany i usystematyzowany.

Szymon Warda: Dopytam Cię jeszcze. Standaryzujemy API w kontekście fabryki agentów, czyli większej skali. Z czego płynie wartość? Z tego, że mogę wyabstrahować i ukryć złożoność systemów, z którymi komunikują się agenci? Skąd bierze się wartość wprowadzenia API Management?

Marek Grabarz: Wejdziemy jeszcze w to, jak API Management działa i jak jest zbudowany. Wyprzedzając szczegóły: API Management robi to w sposób standardowy. Za każdym razem, kiedy chcemy się zintegrować z danym API, na przykład budujemy coś w e-commerce i potrzebujemy danych produktów, moglibyśmy integrować się z tym API z poziomu każdego agenta. To może skończyć się tym, że poszczególne grupy twórców agentów wykonują tę samą mrówczą pracę, czyli tę samą integrację, i wyciągają te same dane w różnych miejscach. API to systematyzuje, a API Management sprawia, że możemy reużywać tego API w różnych miejscach. To jeden z argumentów. Jest jednak cała masa dodatkowych rzeczy istotnych szczególnie dla dużych firm, enterprise'ów: wspólna fasada bezpieczeństwa i wspólna, zamknięta warstwa sieciowa. API nie są wystawione raz tu, raz tam, do publicznego internetu albo do wnętrza firmy. Mamy API Management, który wystawia je w sposób ustandaryzowany pod względem sieci i bezpieczeństwa.

Szymon Warda: Czyli chcesz powiedzieć, że integrację dla każdego API robimy raz, a dobrze? API daje nam wspólny interfejs, mimo że systemy pod spodem rozmawiają różnymi protokołami i mają różne sposoby uwierzytelniania. A nasza fabryka agentów ma jeden spójny protokół komunikacji.

Marek Grabarz: Tu pojawia się ciekawy aspekt. Platforma taka jak API Management potrafi wystawić API nie tylko w typowej formie, na przykład REST czy gRPC, ale też w sposób zrozumiały dla agentów, czyli w postaci tak zwanych serwerów MCP. Naszym zadaniem jest wystawić API na fasadzie i opisać wszystkie endpointy, operacje, akcje czy wywołania w sposób zrozumiały dla agentów. Zadajmy sobie pytanie: gdybym wystawił API GetCustomer, GetProduct i tak dalej, brzmi to dość naturalnie dla mnie i dla Ciebie. Jeżeli jednak operacje biznesowe wystawiane przez API są bardziej skomplikowane, to ani ja, ani Ty nie określimy na podstawie samej nazwy endpointu, co on robi. Jeśli opiszemy to w API Management i dostarczymy agentowi nie tylko końcówki API, ale też pełny opis zrozumiały dla agenta, to działa. 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. Dzięki temu agent, mając opisy poszczególnych końcówek, wie dokładnie, której użyć i jak.

Szymon Warda: Podsumuję, bo poruszyłeś bardzo ważny obszar. Dzięki APIM-owi mogę zacząć używać moich starych systemów bez ich modyfikowania i dodać im możliwość komunikacji z agentami przez protokół MCP, w ogóle nie ruszając systemu. APIM jest moją warstwą integracji, która tłumaczy różne systemy, starsze i nowsze, tak żeby uczestniczyły w mojej fabryce agentów.

Marek Grabarz: W dużym stopniu to prawda. Warto jednak pamiętać, że API Management jest fasadą, punktem wejścia, w którym mamy wspólny monitoring, wspólne bezpieczeństwo i rozliczanie. Nie zawsze API Management wchodzi głęboko do SAP-a, do bazy danych i tak dalej. Do tego wciąż potrzebujemy pod spodem czegoś, co w nomenklaturze chmurowej nazywamy Integration Platform as a Service. O tym jeszcze dzisiaj powiemy. Rzeczywiście jednak to wspólny punkt wejścia i ustandaryzowany sposób komunikacji agentów z naszymi wewnętrznymi systemami.

Szymon Warda: Zacząłeś mówić o tym, że APIM to nie tylko agenci. Jaką jeszcze wartość daje wdrożenie API Management w organizacji?

Marek Grabarz: Od około 10 lat jest z nami pojęcie API Economy, czyli ekonomia API. To typowo zarządcze, managerskie określenie tego, co API może nam dostarczać. Na systemy możemy patrzeć jak na wartość, która została zbudowana wewnątrz organizacji. Tę wartość chcielibyśmy monetyzować. Nie mam na myśli wystawiania API jako software as a service na zewnątrz i sprzedawania go za użycie. Bardziej chodzi o monetyzację wewnętrzną. Koncepcja API Economy opisuje to tak: wystawiamy pewne dane i budujemy na nich kolejne systemy i nadbudówki, które tworzą dodatkową wartość wewnątrz firmy, a także na zewnątrz.

Szymon Warda: Żeby to wybrzmiało: skoro komunikujemy się z serwisem, który dostarcza w organizacji pewną wartość i wiedzę, to czemu mamy korzystać z API Management, a nie z tego serwisu bezpośrednio? Jaką wartość niesie API Management?

Marek Grabarz: Zanim odpowiem, powiem, czym jest API Management, bo to kluczowe, żeby zrozumieć, co wnosi. W dużym uproszczeniu usługa Azure API Management składa się z trzech głównych komponentów. Pierwszy to portal do zarządzania, który technicznie nazywamy Control Plane. To miejsce, w którym definiujemy API, a raczej je importujemy i konfigurujemy, bo te API już istnieją w firmie. Dokładamy je tam i opisujemy za pomocą polityk. Na przykład, że można wejść tylko wtedy, gdy jest się w danej grupie Active Directory, albo że są zabezpieczone w określony sposób. Definiujemy tam monitoring i mechanizmy rate limitingu, czyli ile razy w ciągu minuty czy sekundy dany system może wywołać API. Takich polityk jest cała masa. Control Plane to więc miejsce, w którym definiujemy API. Drugi komponent to Developer Portal, czyli zwizualizowana forma tego, co w ramach API określiliśmy i wystawiliśmy. Każdy pracownik, programista czy członek zespołu, który będzie się integrował z API, może tam wejść i zrobić discovery. Może odnaleźć API, zobaczyć, jak są opisane, jakie mają końcówki, jaką wartość biznesową dostarczają, jak się uwierzytelnić, jak je wywołać, ile razy można i tak dalej. Trzeci komponent to samo API. Tu mówimy o tym, że wystawiamy końcówkę, a korzystają z niej systemy agentowe, ale nie tylko. O agentach mówimy raptem od roku, a systemy takie jak API Management istnieją od lat.

Szymon Warda: I wdrażaliśmy je.

Marek Grabarz: Wdrażaliśmy je niejednokrotnie, w różnych branżach. Mamy aplikacje mobilne, wewnętrzne aplikacje line of business, portale, a nawet aplikacje desktopowe, które wywołują API i przez nie dostają albo wytwarzają jakąś wartość.

Szymon Warda: Czyli wartość, którą daje nam API Management, to widoczność tego, co jest w naszych systemach. Wiemy dokładnie, co jest gdzie, w jednym miejscu.

Marek Grabarz: Dla developerów to odkrywalność: opisy, dokumentacja, definicje, wszystko zgromadzone w jednym miejscu.

Szymon Warda: Mamy translację wszystkich API, więc nie martwimy się, jak dobić się do którego systemu, tylko komunikujemy się z APIM-em. Możemy na przykład podnosić poziom uwierzytelniania, zostawiając starsze systemy w spokoju. Wszystko jest ujednolicone, każdy komunikuje się tak samo. Wspomniałeś też o ciekawej rzeczy: developer, który chce się zintegrować, musi powiedzieć, kim jest i jak będzie się integrował. Dzięki temu widzimy, kto korzysta z danego systemu, nawet przy użyciu wewnętrznym. Widzimy też cały monitoring, rate limiting, czyli kontrolujemy, co dzieje się w organizacji. Nie mamy komunikacji każdy z każdym, tylko jedną bramkę, w której mamy wszystkie informacje o tym, co dzieje się z naszymi systemami.

Marek Grabarz: Widzę jeszcze jeden powtarzający się wzorzec użycia API Management. Firmy, z którymi współpracujemy, często są z branży regulowanej i mają mocno skonfigurowane i dokręcone zasady bezpieczeństwa i zasady sieciowe. Co to oznacza? Jeżeli mamy systemy w jednym miejscu, a API w innym, to trudno przejść całą ścieżkę dyskusji z działem bezpieczeństwa, sieci, compliance i tak dalej o tym, kto z kim może rozmawiać w naszej siatce połączeń. Kiedy wystawimy wspólną część między nimi, możemy dość łatwo i z wyprzedzeniem zbudować przejścia sieciowe, zgody i kontrakty bezpieczeństwa. Dzięki temu mówimy: agenci do APIM, APIM do poszczególnych API. I te dwie ścieżki są wytrasowane.

Szymon Warda: Czyli to taki whitelisting naszych wewnętrznych API: kto z kim może się komunikować.

Marek Grabarz: W pewnym sensie tak.

Szymon Warda: I jaki zestaw danych może konsumować, kto co widzi. Compliance w organizacji staje się bardzo prosty, bo jest w jednym miejscu.

Marek Grabarz: Mamy rozliczanie, widoczność, monitoring i zgodę bezpieczeństwa na to, jak to jest wystawione. To jeden przypadek. Drugi jest wtedy, gdy API Management, może nie całościowo, ale częściowo, wystawiamy również na zewnątrz. To otwiera w organizacji inne perspektywy. Wystawiamy API do integracji zewnętrznej, więc partnerzy biznesowi, inne firmy czy startupy mogą dostać się do naszych wewnętrznych danych. Oczywiście spełniając kontrakty, zgody i warunki dostępu, ale mogą konsumować informacje, które celowo dla nich wystawiamy. Dzięki temu w ramach API Economy budujemy nową wartość biznesową i otwieramy nowe kanały komunikacji i sprzedaży, być może produktów, które jako organizacja będziemy chcieli budować.

Szymon Warda: Dodajmy, że wystawiając API dla konkretnego konsumenta zewnętrznego, możemy określić podzbiór tego, co on widzi. To nie jest mapowanie jeden do jednego. Znowu mamy bardzo granularną, pełną kontrolę.

Marek Grabarz: To prawda. Jest mechanizm, który nazywa się produkty, i rzeczywiście brzmi bardzo SaaS-owo. Bardzo często używa się go jednak w API Management do grupowania API i opisywania ich na przykład jako integracja z określonymi typami systemów. Taki produkt jest następnie nie tyle kupowany, co podpinany dla danego konsumenta, firmy czy projektu, który będzie używał tego zestawu API. Na marginesie: produkty mogą grupować API w różnych konfiguracjach. To nie jest tak, że jedno API należy do jednego produktu. Te same API mogą występować w różnych miejscach. Mając produkty, w ustandaryzowany sposób pozwalamy konsumentom się uwierzytelniać i odpowiednio ich autoryzujemy. I mamy to, o czym mówiłeś, czyli fasadę, tłumaczenie między API wystawionymi w standardowy sposób a systemami wewnętrznymi, które mogą mieć różne interfejsy, jakieś SOAP-y i różne inne rzeczy.

Szymon Warda: Dobrze, Marku, ale mówimy o Azure API Management i o dużych organizacjach. Część z nich, nawet z powodów prawnych, będzie miała systemy on-premise. Co w takiej sytuacji? Czy API Management idzie do odstawki, czy mamy jakieś możliwości?

Marek Grabarz: Nie. To dobre pytanie. Z naszego doświadczenia wynika, że kiedy jako Protopia wdrażamy API Management, to mniej więcej pół na pół wdrażamy go w modelu hybrydowym. Co to oznacza? W dużym uproszczeniu w chmurze cały czas mamy Developer Portal i Control Plane, czyli miejsce, w którym konfigurujemy API. Możemy jeszcze porozmawiać o tym, jak to automatyzujemy. Samo wystawienie API może się natomiast odbywać w chmurze, i to jest tak zwany cloud gateway, albo w dowolnej lokalizacji on-premise czy w innej chmurze, i to nazywa się self-hosted gateway. Sama nazwa mówi, że musimy sami postawić gateway, czyli wejście do naszych API. Zwykle jest hostowany jako kontener, którego obraz udostępnia Microsoft, więc możemy go po prostu pobrać. Taki kontener jest zwykle osadzony na wewnętrznej infrastrukturze klienta. Zyskujemy dodatkową rzecz: nie tylko integrujemy się z systemami wewnętrznymi, ale też nie mamy przeskoków sieciowych. Często okazuje się, że zarówno aplikacja, która chce korzystać z API, jak i samo API są w prywatnym centrum danych. Z bramką chmurową wywołanie wyglądałoby tak: aplikacja woła chmurę, chmura woła API, API odpowiada bramce, a odpowiedź wraca z chmury. Mając bramkę lokalnie, możemy zostawić tę komunikację lokalnie. Mamy lepsze latency i ograniczamy koszty transferu danych do chmury i z powrotem. Ostatnia, niezwykle istotna rzecz to compliance, czyli zgodność z tym, że na przykład dane bankowe, dane…

Szymon Warda: Medyczne.

Marek Grabarz: Medyczne, dane ubezpieczeniowe w żaden sposób nie opuszczają prywatnego data center. Komunikacja zostaje wewnątrz, a do chmury trafia tylko monitoring i ewentualnie observability, które Ty pewnie lubisz, bo to Twój temat.

Szymon Warda: O którym jeszcze będzie.

Marek Grabarz: Na pewno.

Szymon Warda: Wyłapałem rzecz bardzo istotną z mojej perspektywy. API Management pozwala nam włączyć nie tylko chmurowe, nowoczesne aplikacje, ale też te on-premise, i to na dwa sposoby. Po pierwsze w komunikacji na zewnątrz, a po drugie wciągamy je do platformy, o której rozmawiali Łukasz i Mikołaj. Całą komunikację mamy wtedy zrobioną bezpiecznie i zgodnie z compliance. To jeden punkt kontrolny, w którym jest wszystko.

Marek Grabarz: Co więcej, jeśli mamy gateway API Management osadzony lokalnie, możemy być zgodni z podejściem firmy do wystawiania API na zewnątrz. Nie wystawiamy go wtedy z chmury, na przykład z regionu West Europe w Amsterdamie czy z innej lokalizacji centrów danych, tylko lokalnie. Jeżeli mamy to hostowane na Kubernetesie czy maszynie wirtualnej, wystawiamy to na naszym endpoincie, na naszym firewallu, zgodnie z wewnętrznymi zasadami firmy, i to nigdy nie wychodzi do chmury. Taki model.

Szymon Warda: Z tego, co mówisz, przebija jedna ważna rzecz. Nie ukrywajmy, możemy się pochwalić dość szerokim doświadczeniem rynkowym we wdrożeniach API Management. Mówimy o różnych możliwościach, ale interesuje mnie, jak klienci realnie wykorzystują tę wartość.

Marek Grabarz: Nazw klientów pewnie zdradzać nie powinniśmy. W jednym z następnych nagrań będziemy jednak rozmawiać na ten temat z kolegą z jednej z takich organizacji. Myślę, że istotne jest określenie, jakie wartości klienci uzyskują we wdrożeniu API Management. Ciekawe jest to, że jak już wspomniałem, agentów mamy od niedawna. Historycznie zwykle istniała nabrzmiała potrzeba: mamy całą masę API i chcemy coś z nimi zrobić, usystematyzować je, ogarnąć, wystawić w sposób scentralizowany. Często pojawia się tu grupa ludzi nazywana zespołem integracyjnym, która chce sobie uprościć życie i pracę. To jedna rzecz. Wdrażając API Management, zapewniamy, że firma wreszcie wie, jakie API ma. Ma inwentarz wszystkich elementów, które produkowała przez rok, dwa, pięć, dziesięć i piętnaście lat. Często oprócz samego API Management mamy jeszcze element, który nazywa się Azure API Center. Ja nazywam go CMDB dla API albo katalogiem, w którym mamy nasze API. Nie muszą one być wystawione na API Management, mogą być wystawione bezpośrednio albo gdzie indziej. Jesteśmy w stanie je opisać i dostarczyć opisy maszynowe, takie jak Swagger czy OpenAPI. Ostatnia rzecz: możemy wdrożyć mechanizmy governance, czyli zarządzania API. Przykładem jest linting. To pojęcie dość techniczne, ale słuchacze pewnie słyszeli o nim w kontekście kodu: analizujemy kod pod kątem bezpieczeństwa, poprawnego nazewnictwa, struktury, podatności czy błędów. Robiąc linting, możemy automatycznie wymusić w procesie Continuous Integration i Continuous Delivery, że API są opisane tak, jak chcemy, i dopiero wtedy je wystawiamy.

Szymon Warda: Czyli wchodzimy krok wcześniej, przed API, i upewniamy się, czy nasi developerzy i procesy wytwórcze są zgodne z wewnętrznymi zasadami, bezpieczne i aktualne pod względem standardów. Jeśli pojawią się nieprawidłowości, ciągle weryfikujemy, czy API jest dobre. Mamy trochę taki bicz, który pilnuje, żeby API były cały czas dobre i bezpieczne.

Marek Grabarz: Trochę tak. Realnie jednak API mamy już dziś wiele. Budując standardy, skłaniamy organizację, żeby zaczęła je akceptować, oczywiście dla wspólnego dobra w przyszłości. Wiąże się to z pewnym napięciem, bo w którymś momencie ludzie czy departamenty będą musieli się nagiąć, żeby wystawić API na zewnątrz czy do wnętrza organizacji. Tak jak podkreślałem kilka razy, wystawiają je wtedy w sposób usystematyzowany i ustandaryzowany.

Szymon Warda: Czyli cały czas prowadzisz walkę ze stronami wiki, które opisują, co się dzieje, jak i z kim?

Marek Grabarz: Może nie, bo my jako Protopia głównie wdrażamy i budujemy procesy, linting czy API Ops. O API Ops powiem za chwilę, bo o tym też warto wspomnieć. Natomiast to zespoły integracyjne i grupy, które chcą wystawiać API, mają odpowiedzialność, żeby się dostosować.

Szymon Warda: Masz rację, dajesz narzędzia do walki ze stronami wiki.

Marek Grabarz: I narzędzia API Ops. Kilka razy już coś takiego robiliśmy. Przy API Management możemy wdrożyć infrastrukturę, o tym już mówiliśmy. Pytanie brzmi jednak: co, gdybym chciał podejścia znanego ze świata programistów? Na przykład wystawić API w środowisku deweloperskim, gdzie ktoś się integruje i wykonuje pracę, żeby spełnić standardy dopiero przed wystawieniem. Potem to API, a konkretnie jego rewizje, wersje i zmiany, byłyby stopniowo promowane przez środowisko integracyjne, UAT, preprodukcyjne, a środowisk możemy mieć tyle, ile chcemy. I na końcu produkcja. Ręczne rekonfigurowanie API w różnych miejscach oznaczałoby po pierwsze więcej pracy, a po drugie błądzić jest rzeczą ludzką. Pojawiają się ludzkie błędy: ktoś źle przeklikał, źle przeniósł, nie ustawił czegoś w politykach, orkiestracjach i tak dalej. Dlatego promujemy podejście, które w świecie API Management Microsoftu nazywa się API Ops. To coś podobnego do GitOpsa w Kubernetesie. Mamy repozytorium kodu, w którym wszystkie polityki, integracje i całe API są skonfigurowane, a my tylko promujemy tę konfigurację w górę, do kolejnych środowisk.

Szymon Warda: Czyli wdrażamy na poziomie API ten sam proces dojrzałości, który powinniśmy mieć w procesach developerskich. Możemy pilnować zmian, a co więcej, mamy je w formie tekstu i wiemy, co się działo.

Marek Grabarz: Tak. To, że wszystko jest w Gicie i mamy historię zmian: kto, kiedy, gdzie i dlaczego coś zmienił, to jedna rzecz. Druga to to, że zdejmujemy ciężar z zespołu integracyjnego, który w którymś momencie stałby się wąskim gardłem. Mamy tam pięć, dziesięć osób, a cała firma przychodzi do nich z prośbą: zintegruj moje API. Oni pytają: co to za API? Nie wiem, jak działa, nie wiem, czy to wystawić, a do tego wersje, kolejne iteracje i tak dalej. Moim zdaniem zaczyna się robić grubo.

Szymon Warda: Brzmi jak zespół Enterprise Service Bus sprzed wielu lat.

Marek Grabarz: Wielka tragedia. Kiedyś pracowałem w firmach, w których ktoś, kto chciał wystawić API, musiał się zapisać na architecture review board za dwa tygodnie, a oni to rozpatrywali. Podczas rozpatrywania dawali długą listę życzeń: to do zmiany, to do poprawy. Ten proces trwa dwa, trzy, cztery miesiące, a mówimy tylko o prostej iteracji.

Szymon Warda: A wdrożenie będzie za pół roku.

Marek Grabarz: Tutaj mamy empowerment, czyli oddajemy trochę sterowania developerom. Tworzą brancha w API Ops i kodują integrację, której potrzebują. Oczywiście muszą mieć podstawową wiedzę, co wiąże się ze szkoleniami wewnątrz firmy i budowaniem świadomości. Kiedy przygotują integrację, zgłaszają pull request, czyli zmianę, a ktoś z działu integracyjnego ogląda ją i ewentualnie komentuje w miejscu, co trzeba zmienić, poprawić i czy to jest zgodne. Do tego dochodzi automatyzacja, o której mówiłem. Pull request nie tylko pozwala zatwierdzić wdrożenie na poszczególne środowiska, ale też uruchamia kroki automatyczne, czyli linting: czy zmiana jest zgodna ze standardem X, Y, Z, czy nie.

Szymon Warda: To sporo funkcji, które mocno odciążają zespół centralny. Jak powiedziałeś, rozpraszamy wiedzę: zespół centralny staje się weryfikatorem, a inni mogą wprowadzać zmiany. Usuwamy wąskie gardło, które jest bolączką chyba każdej dużej organizacji ze wspólnymi API.

Marek Grabarz: Pełna zgoda. Dla słuchaczy może to jednak brzmieć przytłaczająco, ile rzeczy jesteśmy w stanie i chcemy zrobić. Tego nie robi się z dnia na dzień. To proces i droga, którą przechodziliśmy wielokrotnie. Po wdrożeniu API Management wszystko, co było w przeszłości, zostaje w przeszłości, a teraz mamy agentów. Przychodzą agenci, na przykład tworzymy agenta, który ma opisać produkty dostępne w naszej hurtowni albo złożyć zamówienie, a API są już wystawione. Mówimy agentowi: podaj mi listę produktów z takiej czy innej kategorii, dodaj ten do koszyka, sprzedaj mi go. I to zaczyna działać.

Szymon Warda: Widzę tu prawidłowość: jeżeli raz dobrze wystawiliśmy API, potem łatwiej się integrujemy. Przyszli agenci, a my w zasadzie nie musimy wiele robić, bo API Management daje nam automatycznie MCP. To, co zrobiliśmy wcześniej, możemy wykorzystać teraz. Jak przyjdzie kolejna rzecz, API już mamy.

Marek Grabarz: Co więcej, to API wystawiliśmy wcześniej w postaci REST-owej czy innej, a obecnie w API Management jest, upraszczając, taki checkbox: wystaw też jako MCP. API Management sam wykona translację, a agent po prostu to wchłonie.

Szymon Warda: Czyli to future proofing naszych systemów wewnątrz organizacji.

Marek Grabarz: W pewnym sensie tak.

Szymon Warda: Rozumiem. O całym APIM-ie można by mówić długo. Co jeszcze może nam się przydać wewnątrz organizacji?

Marek Grabarz: W mojej ocenie dużą wartością, obok wspólnego monitoringu, o którym już mówiliśmy, jest bezpieczeństwo. W kontekście bezpieczeństwa dużo mówi się teraz o API. Oczywiście możemy wałkować temat dziurawych systemów, podatności w aplikacjach, phishingu i tak dalej. Aspektów bezpieczeństwa jest całe szerokie spektrum. Patrząc jednak na statystyki włamań i podatności, okazuje się, że w nowoczesnym świecie big techów, Netflixów czy Uberów wszystko działa pod spodem na API. I okazuje się, że głównym miejscem, przez które ktoś może nie tyle włamać się do infrastruktury, co po prostu wykorzystać nasze systemy, nabić sobie punkty czy gdzieś się dostać, jest właśnie API. Problem polega na tym, że skoro przeszliśmy ze świata twardych integracji przez bazy danych do API, musimy też zadbać o bezpieczeństwo tych API. W ramach OWASP powstała, już chyba w drugiej edycji, bo pierwsza była w 2017 roku, a jakiś czas temu ją odświeżono, lista OWASP API Security Top 10. Zdefiniowano w niej poszczególne zagrożenia. Moglibyśmy wejść w szczegóły, jak OWASP je klasyfikuje. W dużym uproszczeniu liczą się szkodliwość zagrożenia wynikającego z danej dziury, częstość występowania i łatwość wykorzystania. To trzy suwaki. Jeżeli wszystkie są mocno podkręcone, zagrożenie ląduje na samym szczycie OWASP Top 10. W dokumentacji łatwo znaleźć, jak Microsoft adresuje te zagrożenia za pomocą API Management i innych narzędzi, takich jak Defender for APIs czy ochrona przed DDoS, bo takich mechanizmów jest więcej. Czyli jak odpowiednio zabezpieczyć nasze API przed poszczególnymi zagrożeniami z API Top 10. W dużym uproszczeniu. To na pewno istotny element.

Szymon Warda: Czyli kolejny argument za tym, żeby nie robić bezpośrednich integracji jeden do jednego, tylko przepuszczać ruch przez API Management. Nawet klientowi wewnętrznemu nie do końca możemy ufać, bo nie znamy do końca jego intencji i możliwości. Znowu robimy future proofing, tym razem bezpieczeństwa. To nasz punkt odcięcia, filtrowania i badania ruchu.

Marek Grabarz: Szymon, wyobraź sobie, że mamy w firmie dziesięć departamentów, a w nich różne grupy developerów. Są to nasi wewnętrzni pracownicy, zewnętrzni kontraktorzy, firmy zewnętrzne, które coś zrobiły i dostarczyły. A może kupiliśmy SaaS-a i mamy go takim, jaki jest, jak black box, którego nie możemy nawet zmodyfikować. Każda z tych grup może się pomylić. Każda ma inne doświadczenia, inne umiejętności i inne podejście do bezpieczeństwa. Mając API Management, razem z działem bezpieczeństwa możemy określić zasady zachowania i bezpieczeństwa, które obowiązują dla wszystkich API wystawionych przez platformę. A skoro wszyscy integrują się przez API Management, to szpachlujemy potencjalną dziurę, która mogłaby się gdzieś pojawić.

Szymon Warda: Dobrze. Podsumujmy powoli wartości, które mamy. Na pewno wybija się future proofing. Wybija się to, że wiemy, kto z kim i gdzie się komunikuje, i mamy jedno miejsce, co jest dla mnie ważne. Przede wszystkim whitelisting: jeśli API jest w API Management, wiemy, że routing jest bezpieczny sieciowo i pod względem uwierzytelniania, wiemy kto, co i jak, i z którym API możemy się komunikować. Po prostu cała komunikacja w jednym miejscu. API Center daje nam pełny opis tego, co dzieje się w organizacji i jak z tego korzystać, nawet bez wystawiania przez API Management. Usuwamy strony wiki z opisami, które są mniej lub bardziej, pewnie mniej, aktualne i…

Marek Grabarz: Nigdy nie są aktualne. Są aktualne co najwyżej w dniu pisania.

Szymon Warda: Nawet to jest wątpliwe, wiele rzeczy widzieliśmy. Usuwamy informacje o tym, kto z kim ma się dogadać. Dajemy pełną widoczność i mamy bezpieczeństwo. Czy ominąłem coś dużego?

Marek Grabarz: Dla mnie istotny jest jeszcze jeden element, który poruszę w rozmowie z Łukaszem. W pierwszym odcinku Łukasz mówił o agentach i podkreślił, że API Management jest sercem platform i systemów agentowych. Ja dzisiaj opisuję API Management w rozmowie z Tobą. Trzecią klamrą nad tym wszystkim jest to, jak powinna wyglądać idealna platforma agentowa, kiedy mamy już agentów, API Management oraz systemy źródłowe i docelowe. Tu pojawia się potrzeba iPaaS-a, czyli Integration Platform as a Service: przepływów, workflow, orkiestracji, która ma się wykonać. Bądźmy szczerzy, API Management nie jest samograjem, który robi wszystko, czyli wysyła maile, powiadomienia, SMS-y…

Szymon Warda: Brzmi, jakby robił dużo.

Marek Grabarz: Robi dużo, ale na koniec dnia służy do wystawiania API. Procesy i logika biznesowa, być może inicjowane przez agentów, wymagają dodatkowej pracy integracyjnej. Budujemy to wtedy tak, że mamy API Management, który wystawia pewne rzeczy, mamy systemy, ale gdzieś pomiędzy jest jeszcze integracja. Na przykład agent woła przez API Management API, które ma zamówić produkt, a API Management, zamiast bezpośrednio zawołać API, wywołuje workflow. Ten workflow wysyła klientowi maila, że zamówił to czy tamto albo że zmienił się status zamówienia, czyli wykonuje dodatkowe kroki. Nie możemy oczekiwać od platformy wystawiającej API, że wyśle SMS-a, chyba że mamy takie API. Z drugiej strony cała integracja na pięć czy dziesięć kroków, z cofaniem się w krokach i stanami, musi gdzieś przechowywać ten stan, odtwarzać go i być przewidywalna.

Szymon Warda: Czyli orkiestracja tych API. Co się dzieje, kiedy…

Marek Grabarz: Właśnie orkiestracja. API Management daje prostą orkiestrację. Ja zawsze klientom odradzam, żeby nie robili dużej orkiestracji w ramach API Management. Da się, ale na koniec dnia jest ona trudna w utrzymaniu, trudna w debugowaniu, trudno określić, co się w niej wykłada, a przede wszystkim nie jest stanowa, nie zapisujesz w niej stanu.

Szymon Warda: To narzędzie, które warto mieć, jeżeli nie ma innej możliwości. Starego systemu nie będziemy modyfikować, żeby wysyłał SMS-y, ale dodanie tego w API Management brzmi dobrze.

Marek Grabarz: I ostatnia rzecz, która mi się tu skojarzyła. Wyobraźmy sobie SAP-a. Nie chcę go demonizować, bo to kawał systemu, a firmy go mają. Jeżeli nasz stary system wystawia coś przez API, jest dobrze, bo możemy to wystawić w API Management. Ale jeżeli jego jedynym interfejsem jest select do bazy, to co wtedy? To nie jest API, to select do bazy. Musi więc istnieć warstwa pośrednicząca między podstawą organizacji a wystawionymi API, która wystawia API właśnie w sposób workflow'owy.

Szymon Warda: Jak jest select do bazy, to gwarantuję Ci, że jest też jakiś serwis, który wystawia to po HTTP. To kwestia widoczności tego serwisu, bo ktoś już miał taką potrzebę. Zaciekawiło mnie jeszcze to, że w kolejnych odcinkach będziesz rozmawiał z Łukaszem, a my porozmawiamy z jednym z naszych klientów…

Marek Grabarz: Z Krzysztofem.

Szymon Warda: Dokładnie tak. Jeszcze trzymamy trochę w tajemnicy, kto, co i jak.

Marek Grabarz: Zapraszamy na kolejne nagranie.

Szymon Warda: Zdradzę też, że w dalszych odcinkach będziemy mówić o observability, więc będzie się działo. Będzie dużo nowej wiedzy o API i o łączeniu go z agentami, bo dziś powiedzieliśmy więcej o API, a agenci dalej są na rzeczy. Mam wrażenie, że jeśli robimy platformę dla jednego czy dwóch agentów, to niekoniecznie. Jeśli jednak budujemy realną platformę w organizacji, to nie mamy wyjścia i musimy zrobić to dobrze, bo i tak ten wysiłek poświęcimy na integrację API.

Marek Grabarz: Oczywiście przy pierwszym podejściu, kiedy robimy pierwszego agenta, próbnego czy testowego, albo chcemy przekonać zarząd, że agenci dają wartość, to jest w porządku. Możemy podłączyć jednego bezpośrednio. My jednak zwykle staramy się zbudować platformę tak, żeby dało się ją reużywać w przyszłości. Zanim w ogóle przystąpimy do prac technicznych, nasze wdrożenia zwykle zaczynają się od warsztatów z klientem. Zbieramy architektów biznesowych i osoby odpowiedzialne za różne obszary w firmie i staramy się dowiedzieć, jakie procesy i elementy można usprawnić agentami. Mając taką długą listę, już wiemy, a klienci też bardzo szybko się orientują, że to nie skończy się na jednym, dwóch czy trzech agentach, tylko na 10, 30, i sky is the limit, jak to się mówi.

Szymon Warda: To dość ważne, bo mówisz o tym, jak wdrażamy.

Marek Grabarz: Wtedy budujemy platformę. Na początku nakład dla organizacji może być rzeczywiście trochę większy, bo musimy zbudować podwaliny, połączyć ze sobą pewne elementy i przejść wewnętrzną certyfikację przez działy bezpieczeństwa, zakupów i tak dalej. Na koniec dnia ta wartość jest jednak osiągnięta, a my tylko uzyskujemy więcej i więcej.

Szymon Warda: Ważne jest też to, co zaznaczyłeś: wdrażając API Management, nie wdrażamy technicznej zabawki, tylko idziemy z całymi procesami i wdrażamy to całościowo.

Marek Grabarz: Podkreślę, że dzisiaj mówimy o agentach, ale API Management wdrożyliśmy już całą masę, zanim ktokolwiek mówił o LLM-ach. Przydaje się tak czy inaczej.

Szymon Warda: Tak, i to były niezależne sukcesy. Uporządkowanie tego było dla organizacji celem samym w sobie.

Marek Grabarz: Tak jest. Zwykle to inicjatywa działów integracyjnych albo osób w roli CTO, które widzą taką potrzebę, widzą, jak świat ewoluuje, i wiedzą, że ekonomia API jest kluczowa dla przyszłego sukcesu firmy.

Szymon Warda: I future proofing: uodparniamy organizację na to, co będzie się działo w przyszłości. Dobrze, Marku, dziękuję pięknie za rozmowę.

Marek Grabarz: Dzięki za rozmowę, a Was zapraszam na kolejne nagranie z serii Powered by Protopia!

Szymon Warda: Dokładnie.

Marek Grabarz: Dzięki.

Szymon Warda: Cześć!