Estratégia multi-cloud: como evitar o vendor lock-in sem sobre-engenharia

A maioria das conversas sobre vendor lock-in começa pela pergunta errada: se vale a pena correr em duas clouds. A pergunta útil é mais concreta e mais difícil: quanto custaria sair do teu fornecedor atual num prazo de doze meses, quanto tempo levaria e o que partiria primeiro.

Poucas equipas sabem responder, porque o lock-in não é uma coisa só. É uma pilha de dependências separadas, cada uma com o seu próprio custo de saída. Uma segunda cloud resolve algumas delas e, em troca, duplica a tua superfície operacional. Conhecer o teu custo de saída, e testá-lo, resolve todas com muito menos esforço.

O lock-in é uma pilha, não um risco único

Pontua cada camada pelo seu custo de saída: o tempo de engenharia para a reconstruir noutro lado, mais o dinheiro pontual (como a transferência de dados), mais o risco do cutover. As classificações abaixo são pontos de partida típicos, não veredictos.

• Computação: normalmente baixo. Cargas de trabalho em contentores sobre Kubernetes mudam com poucas alterações. As imagens de máquina, as chamadas aos metadados da instância nos scripts de arranque e as anotações do balanceador de carga, não.
• Bases de dados geridas: de baixo a alto. PostgreSQL ou MySQL gerido é um motor standard; os dados saem com um dump ou com replicação lógica. Uma base de dados proprietária, com o seu próprio modelo de dados e a sua própria API de consulta, obriga a reescrever todas as consultas.
• Filas e event buses: médio. O código que fala um protocolo aberto (AMQP, MQTT, o protocolo do Kafka) muda com pouco custo. Uma API de filas proprietária obriga a reescrever o adaptador, e a semântica (garantias de entrega, ordenação, novas tentativas) difere mais do que as APIs.
• Identidade e IAM: alto, e o mais subestimado. Cada role, política e binding de service account está escrito na linguagem de políticas de um fornecedor e não se traduz. Se a tua equipa inicia sessão através do diretório do fornecedor em vez do teu próprio fornecedor de identidade, todas as contas de utilizador também têm de mudar.
• Rede: médio. As sub-redes e as regras de firewall são reconstruídas. A parte dolorosa está fora do teu ambiente: os parceiros que puseram os teus IPs de saída numa allowlist.
• Observabilidade: de baixo a médio. Com agentes nativos do fornecedor, cada dashboard e cada alerta são reconstruídos à mão. Com OpenTelemetry e métricas compatíveis com Prometheus, mudas o endpoint de um exporter.
• Serverless proprietário: alto. O código das funções costuma ser portável. Os triggers, a ligação de eventos e as definições de workflows à volta dele não são, e é nessa cola que se acumula a lógica de negócio.
• Dados e egress: cresce todos os meses. Cada terabyte que acrescentas encarece a transferência e alarga a janela de cutover, mesmo que a arquitetura nunca mude.

Constrói o inventário do teu próprio ambiente

Três fontes dão-te uma lista completa num dia. Primeiro, a fatura: exporta um ano de dados de faturação agrupados por serviço. Cada serviço que lá aparece é uma dependência, incluindo os esquecidos.

Segundo, o teu estado de Terraform. Conta os tipos de recurso de cada estado:

terraform state list \
  | sed -E 's/\[[^]]*\]//g' \
  | awk -F. '{print $(NF-1)}' \
  | sort | uniq -c | sort -rn

O prefixo de cada tipo indica o fornecedor e o resto indica o serviço. O que está na fatura mas falta aqui foi criado à mão, e isso já é uma descoberta por si só.

Terceiro, o código: procura nos teus repositórios importações de SDKs do fornecedor. Cada uma é lógica de negócio a falar com um fornecedor em vez de com uma interface que controlas.

Regista cada dependência num ficheiro guardado no Git ao lado do código:

- layer: managed-database
  service: managed PostgreSQL 16
  used_by: [orders-api, billing-worker]
  portable_target: any PostgreSQL 16
  blockers:
    - two provider-only extensions
    - database login through provider IAM
  data_volume_tb: 1.4
  cost_to_leave: "3 engineer-weeks, one-off egress, one maintenance window"
  owner: platform-team
  last_reviewed: 2026-10-01

Expressa o custo de saída em semanas de engenharia e em dinheiro, não como baixo, médio ou alto. Um número pode ser contestado e corrigido depois de um teste.

O plano de saída é um documento que se mantém

Uma estratégia de saída que vive na cabeça de alguém é uma esperança. Escrita, ocupa poucas páginas por sistema crítico:

• Gatilhos. O que daria início a uma saída (uma subida de preço acima do teu limiar, um litígio contratual, uma instrução do regulador) e quem decide.
• Um destino por camada. Para onde iria cada entrada do inventário, com precisão: "PostgreSQL autogerido em Kubernetes", não "outro lado qualquer".
• O plano de dados. Volumes, formatos, método e tempo de transferência, custo de egress e como se sincronizam as alterações enquanto os dois lados correm.
• Sequência e rollback. A ordem em que os sistemas mudam, o período em paralelo e o ponto de não retorno.
• Termos do contrato. Prazos de pré-aviso e condições de recuperação de dados, tirados do contrato assinado.
• Dependências externas. Allowlists de IPs em parceiros, endpoints hard-coded em clientes, certificados, delegações de DNS.
• O último teste. Data, resultado e descobertas em aberto do teste de portabilidade mais recente.

Dá-lhe um único responsável com nome, normalmente quem lidera a infraestrutura ou a plataforma, com aprovação de quem gere o risco de fornecedores. Atualiza o inventário todos os trimestres, revê o plano quando a arquitetura mudar e testa-o pelo menos uma vez por ano. Um plano nunca testado é um rascunho.

Um teste de portabilidade que podes fazer num sprint

Reconstrói o teu ambiente de staging a partir do código, noutra conta ou região, e cronometra. Fazê-lo noutro fornecedor é a versão completa, mas uma conta nova já expõe a maioria dos problemas. Quatro regras mantêm o resultado honesto:

1. 1Começa com uma conta vazia, sem nada criado à mão.
2. 2Só conta o que está no Git. Cada clique na consola ou valor copiado fica registado como descoberta.
3. 3Restaura os dados a partir dos backups, não da base de dados em produção, para testares também os backups.
4. 4Para o cronómetro quando os smoke tests passarem, não quando o último apply terminar.

Aponta o mesmo código para um novo backend de estado e um novo ficheiro de variáveis:

terraform init -reconfigure -backend-config=backends/portability-test.hcl
time terraform apply -var-file=env/portability-test.tfvars

Depois faz o deploy pelo teu pipeline habitual e restaura os dados. As falhas repetem-se de equipa para equipa:

• Identificadores hard-coded. IDs de conta, nomes de região e nomes de bucket embutidos no código, nos values do Helm e nas variáveis do pipeline. Corre antes grep -rnF -e "$ACCOUNT_ID" -e "$REGION" --exclude-dir=.git . em cada repositório.
• Recursos que nunca estiveram no código. Um registo DNS ou uma role corrigidos na consola durante um incidente. O apply corre bem; a aplicação falha.
• O bootstrap dos segredos. O novo cofre de segredos está vazio e ninguém tem a lista completa do que lá vai dentro.
• Chaves de encriptação. Backups encriptados com uma chave que só a conta original pode usar não se restauram em mais lado nenhum.
• Quotas e ordem. Uma conta nova começa com as quotas por omissão, e as dependências escondidas por anos de applies incrementais aparecem no primeiro apply a partir do zero.
• Imagens. Puxadas de um registry a que a conta nova não chega, ou referenciadas por tags mutáveis.

Regista dois números: horas desde a conta vazia até os smoke tests passarem, e número de passos manuais. Corrige as principais descobertas e repete até ambos descerem.

Queres uma segunda opinião antes de o fazer? A nossa avaliação gratuita constrói o inventário por camadas a partir da tua exportação de faturação e do teu estado de Terraform, atribui um custo de saída a cada entrada e assinala o que partiria numa reconstrução a partir do zero. Pede uma avaliação gratuita de lock-in.

Gravidade dos dados e egress: faz as contas

É a gravidade dos dados: os jobs, os serviços e os backups que leem os teus dados acabam onde vivem os maiores conjuntos de dados, por isso o volume de dados dita o ritmo de qualquer saída. As contas cabem em três linhas:

one-off transfer cost = data_GB x egress_price_per_GB
transfer time (days)  = data_TB x 8000 / (link_Gbps x utilization x 86400)
monthly cross-cloud   = daily_cross_cloud_GB x 30 x egress_price_per_GB

Um exemplo prático; substitui os números pelos teus. Imagina que tens 40 TB em armazenamento de objetos e 2 TB em bases de dados, e usa 0,08 € por GB como preço de egress de exemplo. Não é uma cotação: as tabelas de preços reais são escalonadas e mudam.

• Transferência pontual: 42 000 GB x 0,08 € = 3360 €. É pouco comparado com as semanas de engenharia do teu inventário.
• Tempo de transferência: 42 TB numa ligação de 1 Gbit/s a 50% de utilização sustentada são 42 x 8000 / (1 x 0,5 x 86400), cerca de 7,8 dias a pagar os dois ambientes e a sincronizar cada alteração.
• Tráfego contínuo entre clouds: um desenho active-active que envia 500 GB por dia entre fornecedores custa 500 x 30 x 0,08 € = 1200 € por mês, enquanto essa arquitetura existir.

A linha pontual raramente bloqueia uma saída; a janela de transferência, sim. A linha mensal é o preço de correr em dois fornecedores por desenho, uma decisão diferente de manter a capacidade de sair.

Portabilidade pragmática: investe onde compensa

Compra portabilidade onde o custo de saída é alto ou não tem limite. Aceita o lock-in onde está delimitado e o serviço gerido te poupa trabalho todas as semanas.

Kubernetes para as cargas de trabalho, não como promessa

Deployments, Services e ConfigMaps mudam entre clusters conformes. As anotações de ingress, as storage classes e a identidade das cargas de trabalho não, por isso mantém-nas num overlay fino por ambiente (Kustomize ou values do Helm).

Módulos de Terraform com uma interface estável

O HCL é igual em todos os fornecedores; os recursos não. O que ajuda é uma fronteira de módulo por componente (rede, cluster, base de dados), com o código específico do fornecedor lá dentro e outputs estáveis, para que um segundo destino seja uma nova implementação e não uma reescrita de tudo o que o chama:

module "orders_db" {
  source = "./modules/postgres/managed" # or ./modules/postgres/self-managed
  name   = "orders"
  tier   = "medium"
}

# callers only ever depend on this output
output "orders_db_host" {
  value = module.orders_db.host
}

Escreveres isto em HCL ou numa linguagem de uso geral importa menos do que essa fronteira; a nossa comparação Terraform vs Pulumi trata dessa escolha, e desenhar interfaces de módulo que sobrevivam a uma mudança de fornecedor é uma parte central da nossa consultoria de Terraform.

Formatos abertos e identidade portável

Guarda uma cópia dos dados críticos num formato que qualquer destino consiga ler, e restaura-a periodicamente: um dump de PostgreSQL em formato de diretório para as bases de dados, Parquet para os dados analíticos.

pg_dump --format=directory --jobs=4 --file=/backup/orders "$DATABASE_URL"

A tua equipa inicia sessão no teu próprio fornecedor de identidade, federado em cada cloud por SAML ou OIDC; o CI usa federação OIDC em vez de chaves de longa duração. As políticas não se traduzem, por isso documenta a intenção (que serviço lê que dados) no repositório.

Quando a abstração custa mais do que o lock-in

Imagina que autogerir o PostgreSQL para evitar um serviço gerido custa meio dia por semana em patches, backups e simulacros de failover: cerca de 25 dias de engenharia por ano. Imagina que mudar um PostgreSQL gerido para outro fornecedor é um projeto delimitado de 15 dias de que talvez nunca precises. Pagar 25 dias por ano para te protegeres contra um possível projeto de 15 dias é um mau negócio. A mesma lógica exclui abstrações caseiras sobre as filas de vários fornecedores. Põe o esforço onde o custo de saída não tem limite: modelos de dados proprietários e lógica de negócio enterrada na cola dos workflows.

Quando se justifica um segundo fornecedor

Um segundo fornecedor compensa o custo quando:

• A regulação ou a residência de dados exige dados ou processamento num país onde o teu fornecedor principal não tem região.
• Um cliente ou um contrato o exige: implementação no próprio tenant cloud do cliente, ou um concurso público que especifica um fornecedor que não usas.
• Uma aquisição traz uma empresa que corre noutro lado; integra primeiro a identidade e consolida segundo um calendário.
• Uma capacidade que só um fornecedor tem é central para o teu produto; isola-a atrás de uma interface que controlas.

Não compensa para "evitar o lock-in" em geral (um plano de saída e uma reconstrução testada fazem-no mais barato), para resiliência enquanto ainda corres numa só região (acrescenta primeiro uma região) nem como alavanca negocial (dividir a despesa enfraquece o compromisso que podes oferecer a cada fornecedor). Se ainda estás a escolher o teu fornecedor principal, a nossa comparação entre AWS, Azure e GCP cobre os critérios.

A perspetiva europeia: DORA e o EU Data Act

Se és uma entidade financeira da UE, o regulamento DORA (Digital Operational Resilience Act) aplica-se desde 17 de janeiro de 2025 e exige estratégias de saída para fornecedores terceiros de TIC críticos. É provável que o teu fornecedor cloud seja um deles. Uma estratégia de saída não é um segundo fornecedor a correr em paralelo; é uma saída documentada e testada, e o inventário, o plano e o teste acima são a sua substância. Se vendes a entidades financeiras, conta que o planeamento de saída delas te chegue sob a forma de cláusulas contratuais.

O EU Data Act aplica-se desde 12 de setembro de 2025. Obriga os fornecedores cloud a tornar possível a mudança de fornecedor, limita as taxas de mudança ao custo durante um período transitório e elimina-as a partir de 12 de janeiro de 2027. Isso reduz o que um fornecedor te pode cobrar para saíres. Não faz nada pelo teu custo de engenharia: as políticas de IAM, a cola serverless e os IDs de conta hard-coded são tão difíceis de mudar como antes.

O teu primeiro mês

• Semana 1: exporta a fatura, lista o teu estado de Terraform e constrói o inventário com um custo de saída por entrada.
• Semana 2: escreve a primeira versão do plano de saída e atribui-lhe um responsável.
• Semana 3: faz o teste de portabilidade em staging e regista cada passo manual.
• Semana 4: corrige as principais descobertas, faz as contas do egress com os teus volumes reais e decide se alguma coisa justifica um segundo fornecedor.

As nossas equipas de migração para a cloud e de infraestrutura podem fazer contigo essa primeira passagem. Pede uma avaliação gratuita de lock-in: revemos a tua exportação de faturação, o teu estado de Terraform e a encriptação dos teus backups, estimamos o custo de saída por camada, fazemos as contas do egress com os teus volumes e, se fores uma entidade financeira, comparamos o teu plano de saída com o que o DORA exige.