Infraestrutura como workflow: além do Terraform estático

SchemaBridge Team · 2026-01-18 · IaC, DevOps, Cloud Automation

Gerenciando as operações de nuvem do Day 2: tratando a infraestrutura como um processo de negócio com estado e de longa duração.

O limite da "Infraestrutura como Código": Day 1 vs. Day 2

Nós adoramos Terraform (IaC). Ele resolveu o problema do provisionamento do "Day 1". Você descreve o estado desejado (10 instâncias EC2, 1 RDS, 1 VPC), executa terraform apply e o provedor de nuvem faz acontecer. Isso é perfeito para recursos estáticos. É declarativo, idempotente e versionado. É a base do DevOps moderno.

Mas a realidade das operações de nuvem é que a complexidade mora no Day 2. O Day 1 é a cerimônia de casamento; o Day 2 é o casamento. O Day 2 trata de processos, não só de recursos. Trata do ciclo de vida vivo do sistema à medida que ele muda ao longo do tempo.

Considere o ciclo de vida de um upgrade crítico de banco de dados. Isso não é um evento estático; é um workflow:

1. Preparação: Tirar um snapshot do BD primário para o S3, por segurança.

2. Espera: É preciso esperar o snapshot terminar. Em um banco grande, de vários TB, isso pode levar de 30 a 45 minutos.

3. Provisionamento: Subir uma nova instância de BD a partir do snapshot usando a nova versão do engine.

4. Espera: Esperar a nova instância ficar "Available" e "Healthy".

5. Migração: Conectar à nova instância e executar um script de migração de schema (Flyway ou Liquibase). Isso pode levar 1 hora.

6. Verificação: Executar um conjunto de smoke tests contra o novo BD para garantir a integridade dos dados.

7. Virada: Se tudo der certo, atualizar o CNAME do DNS para apontar para o novo BD.

8. Rollback: Se qualquer etapa falhar, é preciso reverter o DNS e destruir a instância com problema.

O Terraform não é adequado para isso. Ele é declarativo, não imperativo. Existem time_sleep e os provisioners local-exec como válvulas de escape para "esperar 30 minutos" ou "executar um script SQL e verificar o código de saída", mas o Terraform não tem um modelo de processo durável, retomável e com aprovações. Para lidar com isso, as equipes costumam embrulhar o Terraform em pipelines do Jenkins, jobs do CircleCI ou scripts Python. Voltamos à "Glue Code Crisis" discutida antes nesta série, só que agora para infraestrutura. Esses scripts são frágeis, sem estado e impossíveis de depurar quando falham no meio de uma operação de 4 horas.

Tratando operações como workflows duráveis

Na SchemaBridge, acreditamos que operações de infraestrutura são workflows de negócio. Elas têm os mesmos requisitos de um fluxo de processamento de pagamentos: confiabilidade, auditabilidade, gestão de estado e recuperação de erros.

Ao levar suas operações do Day 2 para a SchemaBridge, você ganha o poder de um orquestrador durável para a sua nuvem:

O padrão "plano de controle": integrando com AWS, K8s e Terraform

A SchemaBridge não substitui o Terraform; ela o orquestra. Usamos o padrão de plano de controle para unificar os mundos estático e dinâmico.

1. O gatilho: Um desenvolvedor faz commit ou dispara um workflow "Provision Dev Env" a partir do seu portal de desenvolvedores chamando a URL do webhook do workflow.

2. O provisionamento: A SchemaBridge chama a API do Terraform Cloud (ou o endpoint HTTP do seu próprio runner) para iniciar a execução que cria os recursos físicos. A SchemaBridge não invoca terraform via shell: os scripts de workflow rodam em um sandbox GraalVM sem acesso a processos nem ao sistema de arquivos, por design.

3. A espera: Uma etapa Delay durável espera e, em seguida, uma etapa Gateway verifica o status da execução do Terraform. Workflows são grafos acíclicos; então, em vez de um loop de polling infinito, você encadeia um número limitado de etapas de espera e verificação, ou faz o workflow se relançar após um Delay — a mesma recursão que o nosso próprio workflow de sistema de rollout gradual usa.

4. O pós-provisionamento (a "camada de lógica"): Quando a infraestrutura já existe, a SchemaBridge chama os endpoints que executam as migrações de BD, carregam os dados de teste e disparam os testes de aceitação — a API do seu sistema de CI, ou um pequeno serviço de operações que você controla dentro do novo cluster.

Esse padrão permite manter seus recursos definidos em HCL (HashiCorp Configuration Language) enquanto sua lógica operacional fica definida em um grafo visual.

Ambientes efêmeros: o Santo Graal da velocidade de desenvolvimento

Toda equipe de engenharia moderna quer ambientes efêmeros — uma réplica completa de produção para cada Pull Request (PR). Isso permite isolamento real e evita bugs antes que sejam mesclados na main.

As abordagens tradicionais falham porque a limpeza é difícil. Você sobe recursos para o PR-123, mas o desenvolvedor esquece de fechar o PR, ou o script de limpeza falha. Sua conta de nuvem explode com "instâncias RDS zumbis" e "load balancers órfãos".

Com a SchemaBridge, um ambiente é um workflow com ciclo de vida definido.

1. Início: Subir os recursos (RDS, um cache, serviços ECS) pela sua API de provisionamento.

2. Espera: Uma etapa Delay durável arma a desmontagem já na criação — por exemplo, com um TTL de 24 horas. A espera não ocupa nenhum worker nem contêiner; o horário de despertar é persistido.

3. Limpeza: Quando o timer expira, o workflow acorda e chama sua API de provisionamento para destruir o ambiente. Para "desmontar assim que o PR for mesclado", aponte o webhook de merge do seu provedor Git para um workflow de desmontagem separado e torne a desmontagem idempotente, para que não cause dano se ambos dispararem.

Como o timer de desmontagem é armado na mesma execução que criou o ambiente, ele é difícil de esquecer. Mesmo que todo o cluster da SchemaBridge reinicie, o timer persistido ainda dispara e o ambiente do PR-123 ainda é destruído no horário previsto. Isso é "Garbage Collection para a nuvem".

Cenário ilustrativo: deploy blue/green sem intervenção para um serviço sensível à latência

Considere uma equipe que opera um motor de matching sensível à latência e precisa atualizar seu serviço principal sem um microssegundo de indisponibilidade.

O desafio

Um rolling update padrão do Kubernetes não seria seguro o suficiente se fosse preciso verificar a precisão da nova versão com dados reais por 10 minutos antes de virar o tráfego. Seria necessário um deploy complexo em "Shadow Mode".

A abordagem com SchemaBridge

A equipe poderia construir um "Blue/Green Deployment Workflow" na SchemaBridge:

1. Deploy do Green: Subir a nova versão do motor ao lado da antiga (Green).

2. Tráfego espelhado: Configurar o API Gateway para enviar uma cópia genérica do tráfego real para o Green (fire-and-forget). As respostas do Green não são enviadas aos usuários, mas são capturadas.

3. Verificar: Após um Delay de 10 minutos, o workflow busca via HTTP uma amostra das respostas capturadas do Green e das respostas correspondentes do Blue (em produção), e usa JSONata para compará-las.

4. Ponto de decisão: Arestas condicionais roteiam com base no resultado da comparação:

5. Virar: O workflow atualiza o load balancer para direcionar o tráfego real dos usuários para o Green.

6. Limpar: Ele espera mais uma hora (para facilitar o rollback) e então destrói o Blue.

O resultado

Um workflow desse tipo poderia reduzir substancialmente o risco de deploy. Uma equipe de SRE poderia disparar um deploy e se afastar, sabendo que o workflow executaria a verificação e o caminho de limpeza explícito que ela projetou — transformando releases arriscados e infrequentes em releases mais seguros e rotineiros.

Gestão de custos: o "workflow" do FinOps

A otimização de custos de nuvem (FinOps) costuma ser um processo manual de cobrar os desenvolvedores para desligarem as coisas. A SchemaBridge permite automatizar essa governança.

O padrão Night Watchman

Você pode implantar um workflow "Night Watchman" que roda toda noite às 20h.

1. Varrer: Peça à sua API de operações (por exemplo, uma pequena Lambda ou um serviço interno que encapsula o SDK da sua nuvem) todos os recursos marcados como não produtivos. A SchemaBridge conversa com ela via HTTP; ela não tem um conector nativo de AWS.

2. Verificar atividade: Faça o mesmo endpoint informar o uso de CPU da última hora e mantenha apenas os recursos abaixo de 5%.

3. Desligar: Se estiver ocioso, chame o endpoint para parar a instância (não encerrá-la).

4. Notificar: Envie uma mensagem no Slack para o responsável: "Pausamos sua máquina de dev para economizar."

5. Retomar: Um workflow separado "start my box", disparado pelas suas ferramentas de operações via a URL do webhook dele, liga a instância de novo pela manhã.

Um workflow simples assim pode reduzir de forma significativa o gasto com ambientes de dev ociosos, cortando o custo contínuo de recursos não produtivos esquecidos e sempre ligados.

Comparação: Jenkins/GitLab CI vs. operações com SchemaBridge

| Recurso | Pipelines de CI/CD (Jenkins) | Operações com SchemaBridge |

| :--- | :--- | :--- |

| Estado | Preso a um executor; esperas longas retêm recursos | Durável (persistido no PostgreSQL; sobrevive a reinícios) |

| Duração | Minutos/horas | Horas/dias (timers duráveis) |

| Lógica | Scripts (Bash/Groovy) | Visual (grafo) |

| Aprovação | Etapa de input no pipeline | Etapa de Approval (UI ou API), com timeout |

| Recuperação | Reinício a partir de um stage | Reexecução a partir da etapa que falhou |

| Paralelismo | Limitado pelos executors | Fan-out (Spawner) com workers com autoescala |

Checklist de especialista para automação de operações

Para modernizar sua stack operacional, siga estas heurísticas:

1. Não escreva esperas em script: Se você está escrevendo sleep 60 em bash para esperar um ALB, está fazendo errado. Use uma etapa Delay durável seguida de uma verificação de status.

2. Automatize a exclusão primeiro: Escreva a lógica de limpeza antes da lógica de criação. Garanta que todo evento de criação tenha um caminho de destruição correspondente.

3. Use portões de aprovação: Não tenha medo de colocar um humano no loop para ações de alto risco. Um "Pause for Approval" é uma funcionalidade, não um bug.

4. Audite o operador: Registre quem disparou o ambiente e por quê. Faça o gatilho passar o ID do solicitante no payload e carimbe-o em cada recurso que você criar.

5. Trate operações como código: Versione seus workflows operacionais assim como o código da sua aplicação. Exporte-os como bundles, mantenha-os no seu repositório para revisão e faça o deploy pela página Deployments (planejar, revisar, aplicar) ou por uma importação de configuração.

Conclusão: a nuvem é uma máquina de estados

Sua infraestrutura não é uma pilha estática de servidores; é um componente vivo do seu negócio. Ao tratá-la como uma máquina de estados, você pode automatizar as complexas coreografias operacionais de várias etapas que hoje consomem a vida da sua equipe de SRE. Você pode passar de "operações baseadas em tickets" para "operações self-service", com segurança e durabilidade embutidas.

Veja também: O mito do cold start: otimizando a JVM para eventos — por que workers de longa duração superam cold starts por evento.

Explorar