Hvorfor AI-arkitektur adskiller sig fra klassiske applikationer
AI-systemer har specifikke krav, der adskiller dem fra typiske webapplikationer. Sprogmodeller kræver betydelige beregningsressourcer, men ikke altid og ikke overalt. Forskellige systemkomponenter har diametralt forskellige belastningsprofiler: GPU-inferensmodulet er ressourceflaskehalsen, API-laget skal håndtere tusindvis af parallelle forespørgsler, og træningsprocesser kører batchvis og kan tage timer. Arkitekturen skal tage hensyn til dette.
Argumenter for monolit ved start
De fleste AI-projekter bør starte som monolit. Årsagerne er prosaiske: monolitisk arkitektur er enklere at fejlsøge, lettere at forstå for et nyt team og hurtigere at iterere. Når systemet er i eksperimentelfasen, og grænserne mellem komponenter stadig er under formation, medfører for tidlig opdeling i microservices mere skade end gavn.
En klassisk fejl er at designe snesevis af microservices, før systemet betjener sin første reelle bruger. Ukendte brugsmønstre fører til forkerte tjenestegrænser, der efterfølgende genererer enorme refaktoreringsomkostninger.
Hvornår microservices er det rette valg
Migrering til microservices giver mening, når der opstår konkrete, målbare problemer med monolitten:
- Forskellige skaleringskrav — OCR-modulet kræver 10x flere ressourcer under kampagner, resten af systemet forbliver stabilt.
- Uafhængige udgivelsescyklusser — ML-modelteamet deployer nye versioner flere gange dagligt, mens ændringer i rapporteringsmodulet er månedlige.
- Fejlisolation — en fejl i én komponent bør ikke afbryde de øvriges arbejde.
- Forskellige teknologistakke — billedbehandlingsmodulet kræver Python-biblioteker, der ikke er tilgængelige i hovedstakken.
Migreringsstrategier fra monolit
Sikker migrering bygger på Strangler Fig-mønstret: gradvis udskæring af funktionalitet fra monolitten og erstatning med uafhængige tjenester, med bibeholdelse af et fungerende system gennem hele processen. Nøglen er at identificere naturlige domænegrænser — ikke kunstige tekniske snit, men opdeling i overensstemmelse med forretningslogikken.
Den første kandidat til udskilning bør være den komponent, der: er funktionelt veldefineret, har et klart og stabilt API, og forårsager flest problemer på grund af forskelle i skaleringskrav. Det er typisk netop AI-modelinferensmodulet.
Multi-agentorkestrering og tjenestearkitektur
Multi-agentsystemer fra ESKOM.AI opererer på et lag oven over traditionelle microservices — individuelle AI-agenter kan anvende både en monolitisk forretningsapplikation og et microservices-økosystem. Det afgørende er at designe grænseflader, så målsystemets interne arkitektur ikke begrænser mulighederne for integration med agentlogik.