Mentionsy

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ą.

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.

Ja jestem Szymon Warda, ze mną jest Marek Grabasz i porozmawiamy dzisiaj o API Management.

Nagle mamy taki przeskok i mówimy nagle o API Management.

Na poprzednim odcinku Łukasz podkreślił, że API Management jest de facto sercem tych wszystkich systemów agentowych, tych platform agentowych.

Jest ustandaryzowana, powiedziałbym, komunikacja przez właśnie API, Application Programming Interface.

Czy API jest wymagane, jeżeli mamy tych agentów 1, 2, 3?

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.

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ć.

Bo tak naprawdę mamy w sposób ustandaryzowany, usystematyzowany, dostarczamy te API do agentów, tak?

No bo ustandaryzujemy to API.

Gdzie wartość wynika wprowadzenia API w management?

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.

API to systematyzuje, a API Management sprawia, że możemy reużywać tego API w różnych miejscach.

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.

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.

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.

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?

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.

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.

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?

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.

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.

I trzecia rzecz to jest samo to API.

Systemy takie jak API Management istnieją już od lat.

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.

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.

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,

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.

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ć.

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ą.

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ł.

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 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.

I to rzeczywiście z naszego doświadczenia, kiedy my jako Protopia wdrażamy systemy API Management, to powiedziałbym w takim

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.

Natomiast samo wystawienie API może się odbywać zarówno w chmurze, i to jest tak zwany Cloud Gateway,

To jakby sama nazwa mówi już nam, że my musimy sami postawić ten gateway, czyli to wejście do naszych API.

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

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ź.

API Management daje możliwość nam nie tylko wciągnięcia naszych, powiedzmy, chmurowych, nowoczesnych aplikacji, ale też tych on-premowych.

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.

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ąć.

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.

Zautomatyzowane w procesie Continuous Integration, Continuous Delivery, że te API są opisane tak, jak byśmy chcieli i wtedy je dopiero wystawiamy.

Ok, czyli tak naprawdę w tym momencie wchodzimy krok wcześniej przed API i upewniamy się, czy nasi deweloperzy, nasze procesy wytwórcze są zgodne wewnętrznie, są bezpieczne, są też potencjalnie aktualne, jeżeli chodzi o standardy i przez to cały czas też zapewniamy, że jeżeli eksperymenty będą wykryte, to my cały czas weryfikujemy to API, czy ono jest dobre i mamy taki trochę

Beach Page, który pilnuje, żeby to API były dobre i bezpieczne cały czas.

Natomiast realnie jest tak, że tych API mamy wiele już dziś i teraz.

No i to się wiąże z pewnym jakimś tam, nie wiem, naprężeniem, że w którymś momencie te osoby, czy też te poszczególne departamenty będą musiały się nagiąć, żeby wystawić te API do świata, czy też do wewnętrza naszej organizacji.

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ć.

Powiedziałbym, ci ludzie, te grupy, które chcą te API wystawiać, one mają tę odpowiedzialność, żeby jednak się dostosować.

No i narzędzie APIOps.

Mianowicie, kiedy mówimy o API Management, możemy wdrożyć infrastrukturę, tak?

Natomiast pytanie jest takie, a co by było, gdybym ja na przykład chciał mieć takie podejście znane ze świadka programistycznego, czyli na przykład wystawić pewne API, nie wiem, w środowisku deweloperskim, ktoś tam integruje, wykonuje tę pracę, żeby się dostosować, czyli...

No i później takie API, czy też jakieś konkretne rewizje, wersje, zmiany na tym API będą stopniowo promowane przez jakieś środowisko integracyjne, łatowe, preprodukcyjne.

No i teraz takie ręczne rekonfigurowanie API w różnych miejscach wiązałoby się potencjalnie z tym, że po pierwsze dokładamy sobie więcej pracy, ale też błądzić rzeczą ludzką, jak to się mówi.

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ą

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.

Czyli mamy tam, nie wiem, 5-10 osób i cała firma do nich przychodzi, zintegruj moje API.

Oni zadają pytanie, co to za API?

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ą.

Natomiast tutaj mamy takie troszkę empowerment jest to słowo, czyli oddajemy troszkę sterowanie tym deweloperom, czyli oni sobie tworzą branżę w APIopsie, wykodowują tę integrację, którą chcą.

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.

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.

Albo potrzebuje złożyć zamówienie i nagle jak te API są wystawione, no to ten agent

Patrzę na prawidłowość, że jeżeli raz wstawiliśmy API dobrze, to potem mogliśmy się łatwiej integrować.

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?

A to tak jeszcze, bo zakładam, że o całym API-mie można by mówić dużo.

Bo dużo się mówi w tym momencie w kontekście bezpieczeństwa na temat API.

Natomiast patrząc na jakieś statystyki, nie wiem, włamań, podatności i tak dalej, okazuje się, że większość takiego, powiedziałbym, nowoczesnego świata, tych takich, powiedziałbym, big techów, jakieś Netflixy czy jakieś inne Ubery, tak naprawdę wszystko jest po API, gdzieś tam pod spodem.

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.

No i teraz jest problem, że jeżeli my przeszliśmy z tego świata powiedziałbym takich twardych integracji gdzieś tam po bazach danych i SAP-ach do tych API, teraz musimy też zadbać o bezpieczeństwo tych API.

I w kontekście bezpieczeństwa API powstał w ramach OWASP-u już chyba druga edycja, pierwsza była w 2017, teraz było odświeżenie jakiś czas temu, tak zwane OWASP Security Top 10 for APIs czy tam API Security Top 10.

No i patrząc na API Management, możemy nawet w dokumentacji bardzo łatwo znaleźć, jak API Management adresuje albo jak Microsoft na przykład w kontekście API Management i innych narzędzi jak API Defender

Defender for APIs czy może jakiś anty-DDoS i tak dalej, bo tych różnych potencjalnych mechanizmów jest więcej.

Jak te nasze API odpowiednio zabezpieczyć, żeby adresowały te poszczególne zagrożenia z API Top 10.

Czyli kolejny właśnie argument po to, że nie robić integracji 1 do 1 bezpośredniej, tylko właśnie przepuszczać to przez API Management jest to, że...

I teraz my, mając ten API Management, wspólnie z działem bezpieczeństwa w organizacji, jesteśmy w stanie określić pewne zasady zachowania i pewne zasady bezpieczeństwa, które obowiązują dla wszystkich tych API, które zostały przez platformę wystawione.

A skoro wszyscy się integrują przez API Management,

Dla mnie jest ważne to, że ten whitelisting, że wiemy, że jak API jest w API Managemencie, to wiemy, że możemy, wiemy, że również jest bezpieczny, jeżeli chodzi o sieciowo, jeżeli chodzi o uwierzytelnianie, wiemy kto, co, jak, wiemy, które API możemy się skomunikować.

API Center daje nam pełen opis, nawet niekoniecznie wystawiając to przez API Management, mamy pełen opis, co się dzieje w naszej organizacji i jak z tego korzystać.

Dla mnie jeszcze istotnym elementem, który poruszę jeszcze w dyskusji z Łukaszem, bo w pierwszym odcinku Łukasz mówił o agentach, podkreślił, że API Management jest sertem de facto tych platform i systemów agentowych.

Z drugiej strony ja dzisiaj opisuję API Management, rozmawiając z tobą.

No i trzecim, tak powiedziałbym, klamrą nad tym wszystkim jest, jak taka idealna platforma agentowa miałaby wyglądać, kiedy już mamy tych agentów, mamy API Management, mamy systemy źródłowe i docelowe.

Bo też, bądźmy szczerzy, API Management nie jest takim, powiedziałbym, samograjem, który robi wszystko.

Robi dużo, ale na koniec dnia on służy do wystawiania pewnych API.

Wymaga pewnej dodatkowej jeszcze takiej powiedziałbym pracy integracyjnej, czyli budujemy to wtedy w sposób taki, że mamy API Management, który wystawia pewne rzeczy.

Na przykład agent woła do API, który ma zamówić produkt.

Do API Management.

I API Management zamiast bezpośrednio zawołać do API, jeszcze wywołuje pewien workflow, który to na przykład wyśle maila do klienta, że zamówiłeś to czy tamto, albo zmienił się status twojego zamówienia.

Nie możemy oczekiwać od platformy wystawiającej API, że wykona wysyłkę SMS.

Chyba, że mamy takie API.

Taką orkiestrację tych API, co się dzieje kiedy, w jakiej kolejności.

API Management daje prostą orkiestrację, ja zawsze klientom odradzam, żeby nie robili dużej orkiestracji w ramach API Management.

Nie zapisujesz tego stanu.

Ale zadanie tego w API Management brzmi dobrze.

I jeżeli ten nasz stary system wystawia coś po API, jest okej, bo jesteśmy w stanie wystawić to na API Managemencie.

No to nie jest API, to jest select do bazy.

Podstawą organizacji, a tymi wystawionymi API, która wystawia API w sposób taki właśnie workflow'owy.

To jest kwestia widoczności tego serwisu, bo ktoś tą potrzebę już miał, żeby się zapisać.

W kontekście API i w kontekście też łączenia tego z agentami, bo trochę powiedzieliśmy więcej o API, a tutaj agenci dalej są na rzeczy.

I moje takie wrażenie jest takie, że jeżeli robimy platformę dla jednego, dwóch agentów, to to może niekoniecznie, ale w sumie jeżeli robimy realną platformę w organizacji, to nie mamy wyjścia, żeby to zrobić dobrze, bo i tak ten koszt poświęcimy tak naprawdę integracji tych API.

Ale to też jest ważne, co nauczyłeś, że wdrażając API Management, my nie wdrażamy tylko zabawki technicznie, tylko wdrażamy, idziemy z samymi procesami i wdrażamy to całościowo de facto.

No i ja podkreślę, że mówimy dzisiaj o agentach, natomiast API Managementu wdrożyliśmy już całą masę, zanim ktokolwiek mówił o LLM-ach jeszcze, także one się przydają tak czy siak.

To jest jakaś inicjatywa właśnie działów integracyjnych albo osób w roli CTO, które widzą taką potrzebę, widzą jak świat ewoluuje, jak ta ekonomia API jest kluczowa dla sukcesu firmy w przyszłości.