Waarom AI-architectuur verschilt van klassieke applicaties
AI-systemen hebben specifieke eisen die ze onderscheiden van typische webapplicaties. Taalmodellen vereisen aanzienlijke rekenbronnen, maar niet altijd en niet overal. Verschillende systeemcomponenten hebben diametraal verschillende belastingsprofielen: de GPU-inferentiemodule is het bronnenknelpunt, de API-laag moet duizenden parallelle verzoeken afhandelen, en trainingsprocessen draaien batchgewijs en kunnen uren duren. De architectuur moet hier rekening mee houden.
Argumenten voor een monoliet bij de start
De meeste AI-projecten zouden als monoliet moeten beginnen. De redenen zijn prozaïsch: monolithische architectuur is eenvoudiger te debuggen, makkelijker te begrijpen voor een nieuw team en sneller te itereren. Wanneer het systeem in de experimentele fase is en de grenzen tussen componenten nog vorm krijgen, levert premature opsplitsing in microservices meer schade dan voordeel op.
Een klassieke fout is het ontwerpen van tientallen microservices voordat het systeem de eerste echte gebruiker bedient. Onbekende gebruikspatronen vertalen zich in verkeerde servicegrenzen, die vervolgens enorme refactoringkosten genereren.
Wanneer microservices de juiste keuze zijn
Migratie naar microservices heeft zin wanneer er concrete, meetbare problemen met het monoliet optreden:
- Verschillende schaalvereisten — de OCR-module vereist 10x meer bronnen tijdens campagnes, de rest van het systeem blijft stabiel.
- Onafhankelijke releasecycli — het ML-modelteam deployt meerdere keren per dag nieuwe versies, terwijl wijzigingen in de rapportagemodule maandelijks plaatsvinden.
- Fout-isolatie — een fout in één component mag het werk van de overige niet verstoren.
- Verschillende technologiestacks — de beeldverwerkingsmodule vereist Python-bibliotheken die niet beschikbaar zijn in de hoofdstack.
Migratiestrategieën vanuit monoliet
Veilige migratie is gebaseerd op het Strangler Fig-patroon: geleidelijke uitsnijding van functionaliteit uit het monoliet en vervanging door onafhankelijke services, met behoud van een werkend systeem gedurende het hele proces. De sleutel is het identificeren van natuurlijke domeingrenzen — geen kunstmatige technische sneden, maar een verdeling conform bedrijfslogica.
De eerste kandidaat voor afsplitsing zou de component moeten zijn die: functioneel goed gedefinieerd is, een duidelijke en stabiele API heeft, en de meeste problemen veroorzaakt door verschillen in schaalvereisten. Dit is doorgaans juist de AI-model-inferentiemodule.
Multi-agent orkstratie en servicearchitectuur
Multi-agentsystemen van ESKOM.AI opereren op een laag boven traditionele microservices — individuele AI-agenten kunnen zowel een monolithische bedrijfsapplicatie als een microservices-ecosysteem benutten. Cruciaal is het ontwerpen van interfaces zodat de interne architectuur van het doelsysteem de mogelijkheden voor integratie met agentlogica niet beperkt.