Como transformar aplicações legadas em plataformas SaaS no OCI: Uma visão estratégica

No cenário atual de cloud-first, empresas e ISVs (Independent Software Vendors) no Brasil enfrentam o desafio de modernizar aplicações tradicionais para o modelo de software-as-a-service (SaaS). O objetivo central dessa jornada é a implementação de um modelo de deployment multi-tenant, que permite a múltiplos clientes compartilharem a mesma infraestrutura, mantendo rigorosos padrões de segurança, performance e, sobretudo, eficiência de custos (FinOps).

O Oracle Cloud Infrastructure (OCI) oferece um conjunto de serviços nativos que simplificam essa transição, seja através de tenancies compartilhadas ou abordagens híbridas. Para o gestor de TI, o desafio não é apenas técnico, mas operacional: como crescer a base de clientes sem explodir a complexidade do gerenciamento.

Entendendo o conceito de Tenancy no contexto SaaS

É comum haver confusão entre a infraestrutura do provedor e a arquitetura da aplicação. No ecossistema OCI, precisamos distinguir dois conceitos:

• OCI Tenancy: É a conta raiz que sua empresa recebe ao contratar o OCI. É o limite lógico de isolamento de recursos, governança e faturamento global.
• Tenant (no contexto SaaS): Refere-se ao cliente do seu software. Se você é um ISV que hospeda um ERP no OCI, cada empresa que assina seu serviço é um "Tenant".

Em resumo, a OCI Tenancy é o seu contêiner de infraestrutura, enquanto o Tenant é a entidade de negócio que consome sua aplicação.

Arquitetura de Referência

Abaixo, apresentamos uma visão de alto nível de uma aplicação multi-tenant no OCI, focada em flexibilidade e isolamento.

Esta arquitetura é estruturada em três camadas críticas:

1. Autenticação Inicial (OCI IAM): Verifica a identidade global e emite um JSON Web Token (JWT).
2. Middleware de Autenticação: Valida a identidade por requisição e extrai o contexto do tenant e do usuário do JWT.
3. Camada de Acesso a Dados (ou Hooks de ORM): Garante o isolamento de dados, filtrando queries automaticamente pelo tenant_id.

1. Autenticação e Estabelecimento de Contexto

O processo começa quando o usuário faz login em uma URL específica (ex: cliente.sua-app.com.br). O OCI IAM (especificamente em um Identity Domain dedicado) valida as credenciais e confirma se o usuário pertence ao grupo do tenant em questão.

Após a validação, é emitido um JWT contendo claims essenciais:

• sub: Identificador único do usuário.
• groups: OCIDs dos grupos IAM (chave para identificar o tenant).
• Custom claims: IDs de tenant personalizados para facilitar a lógica de aplicação.

2. Middleware de Autenticação – A camada do "Quem"

O backend deve extrair o contexto do tenant de forma segura. Recomendamos o uso do OCI API Gateway como ponto de entrada, pois ele pode validar o JWT e descarregar essa carga processual do código da aplicação. Se optar pelo OCI Load Balancer, o middleware da aplicação deverá realizar essa validação manualmente por meio das chaves públicas do OCI IAM.

3. Camada de Acesso a Dados (ORM) – A camada do "O quê"

Aqui é onde evitamos o vazamento de dados entre clientes. O sistema deve injetar automaticamente o ID do tenant em cada query SQL. Por exemplo, um método buscarVendas() deve ser transformado em SELECT * FROM vendas WHERE tenant_id = :tenant_id de forma transparente para o desenvolvedor, utilizando hooks de ORM (como Hibernate ou Prisma).

Estratégias de Isolamento de Dados

Existem três caminhos principais, cada um com impactos diretos no seu SLA e custo operacional:

1. Coluna Discriminadora (Shared Database): Adiciona-se um tenant_id em todas as tabelas. É a opção com melhor custo-benefício e facilidade de escala, mas exige rigor extremo no desenvolvimento para evitar falhas de isolamento.
2. Schema por Tenant: Cada cliente tem seu próprio schema no mesmo banco de dados. Oferece um isolamento lógico superior e facilita processos de backup/restore individuais.
3. Banco de Dados por Tenant: Isolamento físico total. É o modelo ideal para clientes Enterprise com requisitos de compliance severos, permitindo inclusive o uso de chaves de criptografia próprias (Bring Your Own Keys).

Desafios Operacionais: Atualizações e Deployments

Em um modelo SaaS de instância única, você não atualiza um cliente sem atualizar todos. Para mitigar riscos e evitar downtime, estratégias modernas de DevOps são obrigatórias:

• Blue-Green Deployment: Mantém dois ambientes idênticos. O tráfego só vira para a nova versão após testes rigorosos no ambiente "Green".
• Canary Deployment: Libera a nova versão para uma pequena parcela de usuários, monitorando a estabilidade antes do rollout total.
• Versionamento de Banco de Dados: É crucial manter a compatibilidade retroativa (backward compatibility) nos schemas para permitir rollbacks instantâneos sem corrupção de dados.

Considerações Finais

A transição para SaaS no OCI exige um equilíbrio entre isolamento (Segurança) e compartilhamento de recursos (Eficiência). Para empresas brasileiras, o uso de OCI API Gateway e Kubernetes (OKE) com quotas de recursos por namespace permite um controle granular de custos (FinOps) e performance por cliente.

O próximo passo na modernização é avaliar as lacunas de prontidão da sua arquitetura atual e mapear como os serviços gerenciados do OCI podem acelerar esse time-to-market.

---

Artigo originalmente publicado por Gururaj Mohan em cloud-infrastructure.