Per què l'arquitectura d'IA és diferent de les aplicacions clàssiques
Els sistemes d'IA tenen requisits específics que els distingeixen de les aplicacions web típiques. Els models de llenguatge requereixen recursos computacionals significatius, però no sempre ni a tot arreu. Diferents components del sistema tenen perfils de càrrega diametralment oposats: el mòdul d'inferència GPU és el coll d'ampolla de recursos, la capa d'API ha de gestionar milers de peticions paral·leles, i els processos d'entrenament funcionen per lots i poden durar hores. L'arquitectura ho ha de tenir en compte.
Arguments a favor del monòlit a l'inici
La majoria de projectes d'IA haurien de començar com a monòlit. Les raons són prossaiques: l'arquitectura monolítica és més senzilla de depurar, més fàcil d'entendre per a un nou equip i més ràpida per iterar. Quan el sistema és en fase experimental i els límits entre components encara s'estan definint, la divisió prematura en microserveis causa més perjudicis que beneficis.
Un error clàssic és dissenyar desenes de microserveis abans que el sistema atengui el primer usuari real. Els patrons d'ús desconeguts es tradueixen en límits incorrectes dels serveis, que després generen enormes costos de refactorització.
Quan els microserveis són l'elecció correcta
La migració a microserveis té sentit quan apareixen problemes concrets i mesurables amb el monòlit:
- Requisits d'escalat diferents — el mòdul OCR requereix 10x més recursos durant les campanyes, la resta del sistema roman estable.
- Cicles de desplegament independents — l'equip de models ML desplega noves versions diverses vegades al dia, i els canvis al mòdul d'informes un cop al mes.
- Aïllament de fallades — un error en un component no hauria d'interrompre el treball dels altres.
- Stacks tecnològics diferents — el mòdul de processament d'imatges requereix biblioteques Python no disponibles en l'stack principal.
Estratègies de migració des del monòlit
La migració segura es basa en el patró Strangler Fig: retirar gradualment funcionalitats del monòlit i substituir-les per serveis independents, mantenint el sistema en funcionament durant tot el procés. La clau és identificar els límits de domini naturals — no tallar artificialment per línies tècniques, sinó dividir segons la lògica de negoci.
El primer candidat a ser extret hauria de ser el component que: està ben definit funcionalment, té una API clara i estable, i genera més problemes a causa de les diferències en els requisits d'escalat. Normalment, aquest és precisament el mòdul d'inferència de models d'IA.
Orquestració multiagent i arquitectura de serveis
Els sistemes multiagent d'ESKOM.AI operen per sobre de la capa de microserveis tradicionals — els agents d'IA individuals poden utilitzar tant una aplicació de negoci monolítica com un ecosistema de microserveis. El fonamental és dissenyar les interfícies de manera que l'arquitectura interna del sistema objectiu no limiti les possibilitats d'integració amb la lògica dels agents.