Da Guerra Contra o Terraform Drift ao GitOps de Infraestrutura: Como o Crossplane Mudou Nossa Estratégia

Uma história real sobre governança, consistência e eliminação de drifts complexos em ambientes Kubernetes de larga escala.

Durante anos, o Terraform foi a ferramenta padrão para o gerenciamento de infraestrutura em nuvem. E com razão. É uma ferramenta madura, poderosa e amplamente adotada pelo mercado. Mas, à medida que os ambientes crescem, começam a aparecer problemas que não estão necessariamente relacionados ao Terraform em si, mas sim à forma como a infraestrutura evolui e se desgasta ao longo do tempo.

Mudanças realizadas diretamente pelo console da AWS, equipes diferentes gerenciando os mesmos recursos, imports incompletos, state files distribuídos, pipelines independentes e recursos criados fora do controle do IaC (Infrastructure as Code) acabam gerando um inimigo comum e silencioso: o drift.

Em nosso ambiente, administramos uma plataforma Kubernetes distribuída em dezenas (talvez +100) de contas AWS, múltiplos clusters EKS e centenas de aplicações executando serviços críticos de negócio. Com o passar do tempo, o desafio deixou de ser a criação de infraestrutura. O verdadeiro problema passou a ser manter a infraestrutura consistente.

Quando o estado deixa de representar a realidade

Um exemplo clássico desse cenário é um banco de dados criado há anos. Durante o seu ciclo de vida, podem acontecer dezenas de alterações operacionais:

• Aumento de storage corporativo;
• Troca de tipo de instância para tuning;
• Ajustes finos nas janelas de backup;
• Alterações de parâmetros globais (param groups);
• Mudanças emergenciais na madrugada para conter incidentes de produção.

Depois de algum tempo, surge aquela situação familiar para qualquer equipe de Operações: o Terraform afirma que uma coisa existe, a AWS mostra outra totalmente diferente, e ninguém sabe ao certo qual delas é a correta.

A consequência disso normalmente aparece no pior momento possível — durante um deploy. Ao rodar um simples terraform plan, a ferramenta retorna dezenas de alterações inesperadas e destrutivas, mesmo quando ninguém da equipe pretendia mudar nada no código. Nesse cenário, o risco deixa de ser apenas técnico e passa a ser operacional. As equipes começam a perder a confiança na própria automação.

A necessidade de uma abordagem diferente

Durante uma iniciativa de modernização da nossa plataforma, começamos a discutir uma pergunta simples: E se a infraestrutura fosse gerenciada exatamente da mesma forma que as aplicações Kubernetes?

A ideia fazia total sentido. Hoje, o fluxo para aplicações já é consolidado e transparente:

[ Git ] ──> [ ArgoCD ] ──> [ Kubernetes ]

Por que a infraestrutura subjacente deveria seguir um fluxo completamente diferente, reativo e desconectado desse ciclo de vida? Foi nesse momento que decidimos avaliar o Crossplane.

O que é o Crossplane?

O Crossplane transforma recursos da nuvem em recursos nativos do Kubernetes. Em vez de criar um banco PostgreSQL via Terraform e gerenciar arquivos de estado locais ou remotos, você declara esse banco como um Custom Resource (CRD) dentro do próprio cluster.

Veja um exemplo simplificado de como passamos a declarar nossa infraestrutura:

YAML

apiVersion: rds.aws.upbound.io/v1beta1
kind: Instance
metadata:
  name: carrinho-db
spec:
  forProvider:
    engine: postgres
    region: us-east-1
    instanceClass: db.t4g.large

Com essa abordagem, o fluxo de entrega de infraestrutura foi unificado ao de software:

[ Git ] ──> [ ArgoCD ] ──> [ Crossplane ] ──> [ AWS ]

A partir desse momento, tudo passa a ser reconciliado continuamente pelo plano de controle do Kubernetes.

O verdadeiro benefício não é o provisionamento

Muitas pessoas enxergam o Crossplane apenas como mais uma ferramenta para criar recursos na nuvem. Na prática, o maior ganho que encontramos foi outro: o controle absoluto de drift.

Ao importar recursos existentes para o Crossplane, passamos a ter uma visão muito mais precisa da realidade operacional. Sempre que ocorre alguma alteração não prevista via AWS Console, CLI ou qualquer mudança manual, o Crossplane identifica a divergência imediatamente.

Dependendo da estratégia adotada, a ferramenta pode atuar de forma ativa:

• Reconciliando o recurso automaticamente para o estado correto;
• Sinalizando a inconsistência através de eventos nativos;
• Bloqueando alterações não desejadas;
• Restaurando o estado exato definido no Git.

Pela primeira vez, tivemos uma forma consistente, automatizada e sistêmica de detectar e combater o drift em escala, sem depender de cronjobs de pipelines de IaC.

O fim dos procedimentos manuais

Outro ganho enorme foi a padronização do processo de mudança. Antes da migração, tínhamos vários caminhos possíveis e concorrentes para alterar o ambiente (seja por terraform apply local, cliques no console, scripts avulsos ou CLI).

Após a adoção do GitOps para infraestrutura, o processo foi reduzido a um único caminho soberano:

[ Pull Request ] ──> [ Merge ] ──> [ ArgoCD ] ──> [ Crossplane ]

Toda e qualquer mudança passou a seguir rigorosamente o mesmo fluxo de aprovação. Isso trouxe melhorias imediatas e significativas em auditoria, rastreabilidade, governança, previsibilidade e, principalmente, segurança operacional.

Aplicações e infraestrutura falando a mesma língua

Um dos benefícios mais interessantes está na experiência do desenvolvedor e da equipe de plataforma. Antes, tínhamos uma quebra de contexto brutal: as aplicações rodavam no Kubernetes, mas a infraestrutura dependia de Terraform, acessos à AWS e arquivos de estado apartados.

Com a mudança, unificamos o plano de controle. Tudo passou a ser consultado utilizando exatamente as mesmas ferramentas do dia a dia do ecossistema Kubernetes:

kubectl get instances.rds.aws.upbound.io
kubectl describe instance carrinho-db
kubectl get events --watch

Isso reduziu drasticamente a complexidade operacional. Quando um banco RDS passa a existir dentro do cluster como recursos declarativos, a curva de aprendizado diminui.

Esse modelo trouxe um ganho gigantesco de autonomia inclusive para os nossos DBAs. No cenário anterior com Terraform, a equipe de banco de dados muitas vezes não conseguia atuar diretamente na infraestrutura devido à complexidade de gerenciar state files compartilhados ou pipelines de IaC que não faziam parte do dia a dia deles. Com o Crossplane, essa barreira sumiu: a mesma equipe que opera as aplicações e os especialistas que cuidam dos dados conseguem entender e alterar a saúde da infraestrutura usando os mesmos conceitos, a mesma observabilidade e o mesmo ferramental.

Recursos legados sem recriação (Brownfield)

Uma preocupação muito comum — e legítima — que surgiu no início da nossa jornada foi: “Vamos precisar recriar tudo do zero?”

A resposta é um sonoro não. Um dos pontos fortes do Crossplane é a sua capacidade de adotar (management policies) recursos já existentes na nuvem. Em vez de destruir um banco de dados produtivo e criá-lo novamente, nós importamos esse recurso para dentro do modelo declarativo do Kubernetes.

O recurso continuou existindo na AWS exatamente onde estava. Sem downtime, sem migração de dados e sem corte de serviço. Ele apenas passou a ser gerenciado por um novo mecanismo de controle. Essa característica foi fundamental para conduzirmos nossa estratégia de migração em lotes, sem causar impactos para as aplicações que já estavam gerando valor para o negócio.

Observabilidade de infraestrutura em tempo real

Com o Crossplane, a infraestrutura ganhou o mesmo nível de telemetria que os nossos microsserviços. Passamos a monitorar e criar alertas diretamente para indicadores como:

• Synced & Ready: Estados de sincronismo com o provedor de nuvem;
• Conditions: Detalhes de falhas de conectividade ou permissões de IAM;
• Reconcile Errors & Pending Modifications: Gargalos na API da AWS ou parâmetros inválidos;
• Drift Detection: Alertas de quando o estado em nuvem divergiu do Git.

Tudo isso foi integrado ao ecossistema de monitoramento que já utilizávamos na plataforma, reduzindo consideravelmente o tempo gasto investigando problemas de infraestrutura. Em vez de navegar entre múltiplas ferramentas e estados distribuídos, as equipes passaram a ter uma visão consolidada em um único painel.

Lições aprendidas no caminho

A adoção do Crossplane não é uma solução mágica e exige maturidade. Durante a jornada, enfrentamos desafios importantes que merecem atenção:

• A curva de aprendizado para times que não estão habituados com a arquitetura de controladores do Kubernetes;
• A necessidade de modelar boas abstrações (Compositions) para não expor complexidade desnecessária aos desenvolvedores;
• A definição clara de governança e ownership de recursos compartilhados entre times de plataforma e times de engenharia de software.

No entanto, para o nosso cenário — onde múltiplas equipes compartilham recursos, a governança é uma exigência constante e o GitOps já faz parte da cultura organizacional — , os ganhos compensaram amplamente o investimento.

Conclusão

Ao longo dessa jornada, percebemos algo crucial: o maior desafio da engenharia de plataforma nunca foi criar infraestrutura. Ferramentas de mercado já fazem isso muito bem há anos. O verdadeiro desafio é garantir que a infraestrutura continue consistente à medida que o ambiente escala, novas equipes entram em cena e mudanças inevitáveis acontecem no dia a dia.

Com o Crossplane, conseguimos aproximar a infraestrutura do modelo operacional que nos deu velocidade nas aplicações. O Git tornou-se a fonte única de verdade, o ArgoCD tornou-se o mecanismo central de reconciliação e o Crossplane tornou-se a ponte definitiva entre o Kubernetes e a AWS.

O resultado foi simples de medir: menos drift, eliminação de mudanças manuais às cegas, maior governança e muito mais previsibilidade para evoluir a nossa plataforma com segurança.