Por que a arquitetura de AI difere das aplicações clássicas
Os sistemas de AI têm requisitos específicos que os distinguem das aplicações web típicas. Os modelos de linguagem requerem recursos computacionais significativos, mas não sempre e não em todo o lado. Diferentes componentes do sistema têm perfis de carga diametralmente diferentes: o módulo de inferência GPU é o gargalo de recursos, a camada API deve processar milhares de pedidos paralelos, e os processos de treino correm em batch e podem durar horas. A arquitetura deve ter isto em conta.
Argumentos a favor do monólito no arranque
A maioria dos projetos de AI deveria começar como monólito. As razões são prosáicas: a arquitetura monolítica é mais simples de depurar, mais fácil de compreender por uma equipa nova e mais rápida de iterar. Quando o sistema está em fase experimental e os limites entre componentes ainda se estão a definir, a divisão prematura em microsserviços traz mais prejuízos do que benefícios.
Um erro clássico é projetar dezenas de microsserviços antes de o sistema servir o primeiro utilizador real. Padrões de utilização desconhecidos traduzem-se em limites de serviço errados, que depois geram custos enormes de refatorização.
Quando os microsserviços são a escolha certa
A migração para microsserviços faz sentido quando surgem problemas concretos e mensuráveis com o monólito:
- Requisitos de escalabilidade diferentes — o módulo OCR requer 10x mais recursos durante campanhas, o resto do sistema permanece estável.
- Ciclos de lançamento independentes — a equipa de modelos ML faz deploy várias vezes por dia, enquanto alterações no módulo de relatórios são mensais.
- Isolamento de falhas — um erro num componente não deve interromper o trabalho dos restantes.
- Stacks tecnológicos diferentes — o módulo de processamento de imagem requer bibliotecas Python não disponíveis no stack principal.
Estratégias de migração a partir do monólito
Uma migração segura baseia-se no padrão Strangler Fig: extração gradual de funcionalidades do monólito e substituição por serviços independentes, mantendo o sistema a funcionar durante todo o processo. A chave é identificar limites de domínio naturais — não cortes artificiais por linhas técnicas, mas divisão conforme a lógica de negócio.
O primeiro candidato a ser separado deve ser o componente que: é funcionalmente bem definido, tem uma API clara e estável, e gera mais problemas devido a diferenças de requisitos de escalabilidade. Geralmente, este é precisamente o módulo de inferência de modelos AI.
Orquestração multi-agente e arquitetura de serviços
Os sistemas multi-agente da ESKOM.AI operam numa camada acima dos microsserviços tradicionais — os agentes de AI individuais podem utilizar tanto uma aplicação empresarial monolítica como um ecossistema de microsserviços. O crucial é projetar interfaces de modo a que a arquitetura interna do sistema alvo não limite as possibilidades de integração com a lógica dos agentes.