Analizując wpływ sztucznej inteligencji na dostarczanie i bezpieczeństwo aplikacji, można dostrzec pewną analogię do mechaniki kwantowej i słynnego kota Schrödingera. Bez zagłębiania się w szczegóły tego eksperymentu myślowego, rola AI w tym kontekście wydaje się równie paradoksalna. Dlaczego? Otóż jednocześnie prawdziwe jest twierdzenie, że sztuczna inteligencja zmienia wszystko - i że nie zmienia nic. Przyjżyjmy się temu pozornemu paradoksowi.
Aplikacje AI mają dwie kluczowe cechy, które budzą zamieszanie. Po pierwsze, opierają się na najnowszych technologiach, które dopiero wchodzą na rynek. Po drugie, są silnie uzależnione od interfejsów API. W efekcie dostarczanie i zabezpieczanie takich aplikacji w wielu przypadkach nie różni się znacząco od obsługi już istniejących systemów. Te same usługi zabezpieczeń API mogą chronić API AI, a podstawowe technologie bazują na dobrze znanych protokołach. Można je zabezpieczyć zarówno przed atakami DDoS (Distributed Denial of Service - rozproszona odmowa dostępu do usługi), jak i za pomocą klasycznych zapór aplikacyjnych WAF (chroniących aplikacje webowe przed atakami i niepożądanym ruchem). A co z botami? Mechanizmy obrony przed botami również tu znajdują zastosowanie.
Czy w takim razie potrzebne są nowe funkcje zabezpieczeń API? Tak - w szczególności w kontekście pracy z danymi nieustrukturyzowanymi. Czy usługi dostarczania aplikacji, takie jak balansowanie obciążenia, muszą się dostosować do specyfiki wnioskowania AI? Również tak, choć w ograniczonym zakresie. Jednak fundamentalne zasady działania tych usług pozostają niemal niezmienne.
Ale tutaj ujawnia się drugi „stan kwantowy” - wdrożenie aplikacji AI zazwyczaj wiąże się ze zmianą architektury. Dlatego AI jednocześnie zmienia wszystko i nic.
Serwery wnioskowania AI to nie tylko serwery webowe czy aplikacyjne - stosują one wzorce architektoniczne, które rozszerzają nowoczesną architekturę aplikacji o nową warstwę poświęconą wnioskowaniu AI. Zmiany dotyczące komponentów i ich lokalizacji wpływają bardziej na dostarczanie aplikacji niż na ich bezpieczeństwo.
Przykładowo, analizując potencjalne miejsca w architekturze rozwiązania, które mogłyby posłużyć dla usług dostarczania i bezpieczeństwa aplikacji, widać, że głębsze warstwy architektury wymagają mniej tradycyjnych „usług wejściowych”, takich jak globalne balansowanie obciążenia, ochrona przed DDoS czy sieciowanie multicloud. Na „drzwiach wejściowych” niewiele się zmienia.
Warstwa wnioskowania będzie wymagała inteligentnego balansowania obciążenia. To właśnie kluczowy element dostarczania aplikacji. Dobrym pomysłem może być także AI gateway, który monitoruje i chroni wychodzący ruch AI, nie omijając również treści zapytań i odpowiedzi (tzw „warstwy L8” modelu ISO/OSI).
Przeprowadziliśmy badanie rynku, które precyzyjnie określiło, jakiego rodzaju usługi chcą stosować użytkownicy i gdzie chcą je wdrażać. W przypadku dostarczania i bezpieczeństwa w punkcie wstawiania N-S AI, 44% badanych wskazuje na AI Gateway, 21% na zabezpieczenia API, 13% na balansowanie obciążenia, natomiast obronę przed botami wskazało 29%. Takie same usługi, choć w innych proporcjach, wskazano przy punktach wstawiania „N-S Front Door”.
W tym miejscu pojawia się zamieszanie. Zainteresowani rozumieją, że aplikacje AI to nowoczesne rozwiązania zależne od API. Dlatego obecne usługi dostarczania i bezpieczeństwa będą działały równie dobrze dla AI, jak dla innych nowoczesnych aplikacji i API. Jednocześnie klienci zdają sobie sprawę, że AI zmienia architekturę, wprowadzając nowe punkty wstawiania, gdzie te usługi mogą być lepiej wdrażane. To właśnie architektura jest największą zmianą wprowadzoną przez AI.
Nie jest to drobna kwestia. Zmiany architektoniczne wpływają na wszystko - od dostarczania i bezpieczeństwa aplikacji, po monitoring, automatyzację i sieciowanie. Oznacza to, że nawet jeśli usługi dostarczania aplikacji i bezpieczeństwa nie zmieniają się znacząco, to miejsce i sposób ich wdrażania - bardzo. Przyjęcie tego faktu jest ważną składową gotowości do skalowania sztucznej inteligencji w znaczący sposób.
Autor: Lori MacVittie, F5 Distinguished Engineer w F5
