Dlaczego architektura AI różni się od klasycznych aplikacji
Systemy AI mają specyficzne wymagania, które odróżniają je od typowych aplikacji webowych. Modele językowe wymagają znacznych zasobów obliczeniowych, ale nie zawsze i nie wszędzie. Różne komponenty systemu mają diametralnie różne profile obciążenia: moduł inferencji GPU jest wąskim gardłem zasobów, warstwa API musi obsługiwać tysiące równoległych żądań, a procesy trenowania działają wsadowo i mogą trwać godziny. Architektura musi to uwzględniać.
Argumenty za monolitem na starcie
Większość projektów AI powinna zaczynać jako monolit. Powody są prozaiczne: monolityczna architektura jest prostsza w debugowaniu, łatwiejsza do zrozumienia przez nowy zespół i szybsza w iterowaniu. Gdy system jest w fazie eksperymentalnej i granice między komponentami jeszcze się kształtują, przedwczesny podział na mikrousługi przynosi więcej szkód niż korzyści.
Klasycznym błędem jest projektowanie dziesiątek mikrousług zanim system obsługuje pierwszego rzeczywistego użytkownika. Nieznane wzorce użycia przekładają się na błędne granice serwisów, które potem generują ogromne koszty refaktoryzacji.
Kiedy mikrousługi są właściwym wyborem
Migracja do mikrousług ma sens, gdy pojawiają się konkretne, mierzalne problemy z monolitem:
- Różne wymagania skalowania — moduł OCR wymaga 10x więcej zasobów podczas kampanii, reszta systemu pozostaje stabilna.
- Niezależne cykle wdrożeń — zespół modeli ML wdraża nowe wersje kilka razy dziennie, a zmiany w module raportowania raz na miesiąc.
- Izolacja awarii — błąd w jednym komponencie nie powinien przerywać pracy pozostałych.
- Różne stosy technologiczne — moduł przetwarzania obrazów wymaga bibliotek Python niedostępnych w głównym stosie.
Strategie migracji z monolitu
Bezpieczna migracja opiera się na wzorcu Strangler Fig: stopniowym wycinaniu funkcjonalności z monolitu i zastępowaniu ich niezależnymi serwisami, przy zachowaniu działającego systemu przez cały czas. Kluczem jest identyfikacja naturalnych granic domenowych — nie sztuczne cięcie po liniach technicznych, ale podział zgodny z logiką biznesową.
Pierwszym kandydatem do wydzielenia powinien być komponent, który: jest dobrze zdefiniowany funkcjonalnie, ma wyraźne i stabilne API, generuje najwięcej problemów z powodu różnic w wymaganiach skalowania. Zazwyczaj jest to właśnie moduł inferencji modeli AI.
Orkiestracja wieloagentowa a architektura serwisów
Systemy wieloagentowe ESKOM.AI operują na warstwie powyżej tradycyjnych mikrousług — poszczególne agenty AI mogą korzystać zarówno z monolitycznej aplikacji biznesowej, jak i z ekosystemu mikrousług. Kluczowe jest zaprojektowanie interfejsów tak, by wewnętrzna architektura docelowego systemu nie ograniczała możliwości integracji z logiką agentową.