Varför AI-arkitektur skiljer sig från klassiska applikationer
AI-system har specifika krav som skiljer dem från typiska webbapplikationer. Språkmodeller kräver betydande beräkningsresurser, men inte alltid och inte överallt. Olika systemkomponenter har diametralt olika belastningsprofiler: GPU-inferensmodulen är resursflaskhalsen, API-lagret måste hantera tusentals parallella förfrågningar, och träningsprocesser körs batchvis och kan ta timmar. Arkitekturen måste beakta detta.
Argument för monolit vid start
De flesta AI-projekt bör starta som monolit. Skälen är prosaiska: monolitisk arkitektur är enklare att felsöka, lättare att förstå för ett nytt team och snabbare att iterera. När systemet är i experimentfasen och gränserna mellan komponenter fortfarande formas medför för tidig uppdelning i mikrotjänster mer skada än nytta.
Ett klassiskt misstag är att designa tiotals mikrotjänster innan systemet betjänar sin första riktiga användare. Okända användningsmönster leder till felaktiga tjänstegränser som sedan genererar enorma refaktoreringskostnader.
När mikrotjänster är rätt val
Migrering till mikrotjänster är meningsfull när konkreta, mätbara problem med monoliten uppstår:
- Olika skalningskrav — OCR-modulen kräver 10x mer resurser under kampanjer, resten av systemet förblir stabilt.
- Oberoende releasecykler — ML-modelteamet driftsätter nya versioner flera gånger om dagen, medan ändringar i rapporteringsmodulen sker en gång i månaden.
- Felisolering — ett fel i en komponent ska inte störa övrigas arbete.
- Olika teknikstackar — bildbehandlingsmodulen kräver Python-bibliotek som inte är tillgängliga i huvudstacken.
Migreringsstrategier från monolit
Säker migrering bygger på Strangler Fig-mönstret: stegvis utbrytning av funktionalitet från monoliten och ersättning med oberoende tjänster, med bibehållet fungerande system under hela processen. Nyckeln är att identifiera naturliga domängränser — inte konstgjorda tekniska snitt utan uppdelning i enlighet med affärslogik.
Den första kandidaten för utbrytning bör vara den komponent som: är funktionellt väldefinierad, har ett tydligt och stabilt API, och orsakar flest problem på grund av skillnader i skalningskrav. Detta är vanligtvis just AI-modellinferensmodulen.
Multi-agentorkestrering och tjänstearkitektur
Multi-agentsystem från ESKOM.AI opererar på ett lager ovanför traditionella mikrotjänster — enskilda AI-agenter kan använda såväl en monolitisk affärsapplikation som ett mikrotjänstekosystem. Avgörande är att designa gränssnitt så att målsystemets interna arkitektur inte begränsar möjligheterna till integration med agentlogik.