Migrando Funções em TypeScript do AWS Lambda para o OCI Functions: Uma Análise Estratégica

A transição de cargas de trabalho serverless, especificamente funções em TypeScript rodando no AWS Lambda para o OCI Functions, é um movimento que muitas empresas brasileiras estão avaliando em busca de otimização de custos e maior eficiência de performance. O objetivo não é uma reescrita completa da lógica de negócio, mas sim entender o que deve ser adaptado para garantir que a transição ocorra de forma resiliente e dentro das boas práticas de infraestrutura moderna.

O que muda e o que permanece

A lógica de negócio, em essência, permanece preservada. A complexidade da migração concentra-se nas "bordas" da aplicação: a forma como os eventos são tratados e como a função interage com as dependências externas.

1. Handler/Event Shapes: O payload de eventos do AWS (API Gateway, S3) difere nativamente do formato do OCI. Você precisará de uma camada de tradução (adapter layer) para reformatar os inputs sem alterar a integridade do Async/Await.
2. SDK Integrations: Aqui reside uma escolha estratégica: substituir chamadas da AWS SDK pelos serviços equivalentes no OCI (Object Storage, NoSQL, Streaming) ou manter uma camada híbrida, ciente da latência e dos custos de egressa.
3. Packaging e Deployment: Diferente do modelo ZIP + Layers da AWS, o OCI Functions adota uma arquitetura baseada em container images. Isso exige uma mudança no seu pipeline de CI/CD para envolver o trabalho com o OCI Container Registry e o CLI do Fn Project.
4. IAM e Networking: Embora os conceitos sejam similares (policies, compartments, VCN), a implementação de políticas de segurança e a gestão de segredos via OCI Vault exigem uma revisão atenta para evitar o over-permissioning.

Exemplo de adaptação de handler:

Copiar/**
 * Handler original para AWS Lambda
 */
export const handler = async (event: OrderEvent): Promise<string> => {
	...
}

/**
 * Handler adaptado para OCI, utilizando o FDK
 */
handle(handler, { inputMode: 'json' })

Evitando armadilhas operacionais

Packaging: Fuja do modelo ZIP
Tratar o OCI Functions como um runtime de arquivos ZIP é um erro comum que gera overheads desnecessários. A estratégia correta é a conteinerização.

• Utilize multi-stage Docker builds para manter as imagens lean.
• Execute a compilação do TypeScript no build e garanta que npm ci --omit=dev seja aplicado.
• Monitore o cold start como KPI fundamental.

O perigo do over-permissioning
É tentador conceder permissões amplas para "fazer funcionar rápido", mas isso cria débitos técnicos de segurança. Desenhe políticas baseadas no princípio do privilégio mínimo, utilizando Dynamic Groups no OCI para que a função acesse recursos sem a necessidade de chaves estáticas.

Observabilidade como pilar
Sem um Single Source of Truth para logs, você encontrará dificuldades para diagnosticar falhas em um ambiente distribuído. Implemente logs estruturados (JSON) com correlação de requestId e, sempre que possível, utilize APM para rastreamento distribuído, garantindo que timeouts e latências sejam monitorados proativamente.

Passo a passo da implementação

O processo envolve instanciar o ambiente no OCI CloudShell, configurar o fn context para a região home (garantindo que a arquitetura x86/ARM seja compatível entre o build e o runtime) e configurar as policies de escrita no Object Storage.

Lembre-se: o auth-token gerado é essencial para o docker login no seu registry. Erros de 403 aqui são frequentemente subestimados durante o processo de migração.

Conclusão

O OCI Functions é uma ferramenta robusta para arquiteturas modernas, permitindo focar em código em vez de gestão de servidores. No entanto, o sucesso dessa migração depende da robustez dos seus processos de Observabilidade, FinOps e da correta orquestração dos seus containers.

---

Artigo originalmente publicado em cloud-infrastructure.