Infraestrutura como Workflow: Além do Terraform Estático

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

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

O Limite da "Infraestrutura como Código": Dia 1 vs. Dia 2

Adoramos o Terraform (IaC). Ele resolveu o problema do provisionamento de "Dia 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. É o alicerce do DevOps moderno.

Mas a realidade das operações de nuvem é que é no Dia 2 que a complexidade vive. O Dia 1 é o casamento; o Dia 2 é a vida de casado. O Dia 2 trata de Processos, não apenas de Recursos. Trata do ciclo de vida vivo e pulsante do sistema à medida que ele muda ao longo do tempo.

Considere o ciclo de vida de uma atualização crítica 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: Você precisa esperar o snapshot ser concluído. Para um banco de dados de múltiplos 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 motor.

4. Espera: Esperar a nova instância se tornar "Disponível" e "Saudável".

5. Migração: Conectar-se à 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 (Switchover): Se bem-sucedido, atualizar o CNAME do DNS para apontar para o novo BD.

8. Rollback: Se qualquer passo falhar, você precisa reverter o DNS e destruir a instância com problema.

O Terraform não consegue expressar isso. Ele é declarativo, não imperativo. Ele não sabe como "Esperar 30 minutos" ou "Executar um script SQL e verificar o código de saída". Para lidar com isso, as equipes geralmente recorrem a envolver o Terraform em pipelines do Jenkins, jobs do CircleCI ou scripts Python. Voltamos à "Crise do Código de Cola" (Parte 1), mas 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 que um fluxo de processamento de pagamento: confiabilidade, auditabilidade, gerenciamento de estado e recuperação de erros.

Ao migrar suas operações de Dia 2 para a SchemaBridge, você ganha o poder de um Orquestrador Durável para sua nuvem:

O Padrão "Control Plane": Integrando com AWS, K8s e Terraform

A SchemaBridge não substitui o Terraform; ela o orquestra. Usamos o Padrão Control Plane para unificar os mundos estático e dinâmico.

1. O Gatilho: Um desenvolvedor faz commit de código ou dispara manualmente um workflow de "Provisionar Ambiente de Dev" a partir do portal interno de desenvolvedores (Backstage).

2. O Provisionamento: A SchemaBridge chama a API do Terraform Cloud (ou executa um terraform apply em um Worker Seguro) para criar os recursos físicos.

3. A Espera: O workflow faz polling na API do Terraform até que a execução seja "Aplicada" com segurança. Ele lida com a natureza assíncrona da nuvem.

4. O Pós-Provisionamento (a "Camada de Lógica"): Uma vez que a infraestrutura existe, a SchemaBridge se conecta ao novo cluster Kubernetes e executa as migrações de BD, popula os dados de teste e roda os testes de aceitação.

Esse padrão permite que você mantenha seus recursos definidos em HCL (HashiCorp Configuration Language) enquanto mantém sua lógica operacional definida em um Grafo Visual.

Ambientes Efêmeros: O Santo Graal da Velocidade do Desenvolvedor

Toda equipe de engenharia moderna quer Ambientes Efêmeros — uma réplica completa de produção para cada Pull Request (PR). Isso permite isolamento verdadeiro e previne bugs antes que eles sejam mesclados na branch principal.

Abordagens tradicionais falham porque são difíceis de limpar. Você sobe recursos para o PR-123, mas o desenvolvedor esquece de fechar o PR, ou o script de limpeza falha. Sua fatura de nuvem explode com "Instâncias RDS Zumbis" e "Load Balancers Órfãos".

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

1. Início: Sobe os recursos (RDS, Redis, Serviços ECS).

2. Espera: O workflow entra em um Estado de Espera. Ele aguarda o PR ser mesclado OU um TTL predefinido (ex.: 24 horas) expirar.

3. Limpeza: Quando o sinal chega ou o timer expira, o workflow automaticamente acorda e executa terraform destroy.

Como a lógica de limpeza faz parte da mesma instância de workflow durável que a lógica de criação, é impossível esquecer. Mesmo que todo o cluster da SchemaBridge reinicie, ele vai se lembrar que precisa destruir o ambiente do PR-123 às 17h. Isso é "Coleta de Lixo para a Nuvem".

Estudo de Caso: Deploy Blue/Green Zero-Touch para High-Frequency Trading

Trabalhamos com uma empresa de negociação de alta frequência (high-frequency trading) que precisava atualizar seu motor de matching principal sem um microssegundo de downtime.

O Desafio

Uma atualização gradual (rolling update) padrão do Kubernetes não era segura o suficiente, porque eles precisavam verificar a precisão financeira da nova versão em dados ao vivo durante 10 minutos antes de trocar o tráfego. Eles precisavam de um deploy complexo em "Modo Sombra" (Shadow Mode).

A Solução SchemaBridge

Eles construíram um "Workflow de Deploy Blue/Green" na SchemaBridge:

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

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

3. Verificação: O workflow observou os logs do Green por 10 minutos. Ele usou JSONata para comparar as saídas financeiras do Green vs. do Blue (a versão ao vivo).

4. Ponto de Decisão:

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

6. Limpeza: Esperou mais uma hora (para facilitar o rollback) e então destruiu o Blue.

O Resultado

Eles reduziram seu risco de deploy para praticamente zero. A equipe de SRE podia disparar um deploy e ir almoçar, sabendo que o workflow cuidaria automaticamente da verificação complexa, do monitoramento e da lógica de rollback. Eles passaram de 1 deploy por semana para 10 deploys por dia.

Gestão de Custos: O "Workflow" do FinOps

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

O Padrão "Vigia Noturno"

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

1. Varredura: Isolar todos os recursos marcados como não produtivos.

2. Verificar Atividade: Checar métricas do CloudWatch em busca de uso de CPU < 5% na última hora.

3. Desligamento: Se ocioso, parar a instância (sem terminá-la).

4. Notificação: Enviar uma mensagem no Slack ao dono: "Pausamos sua máquina de dev para economizar dinheiro. Clique aqui para Retomar."

5. Retomada: Quando o desenvolvedor clica no botão pela manhã, um sinal (Parte 7) acorda o workflow para iniciar a instância novamente.

Esse workflow simples economizou $40.000 por mês em custos de AWS EC2 para um de nossos clientes enterprise.

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

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

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

| Estado | Efêmero (Perdido ao reiniciar) | Durável (Sobrevive por anos) |

| Duração | Minutos/Horas | Dias/Semanas/Meses |

| Lógica | Roteirizada (Bash/Groovy) | Visual (Grafo) |

| Aprovação | Básica (botão de UI) | Rica (Slack/E-mail/Webhooks/Mobile) |

| Recuperação | Retentar do início | Retomar do ponto de falha |

| Paralelismo | Limitado por Executors | Escalonamento Serverless (Parte 3) |

Checklist de Especialista para Automação de Operações

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

1. Não roteirize esperas: Se você está escrevendo sleep 60 em bash para esperar um ALB, está fazendo errado. Use um loop de polling em um workflow durável.

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 "Pausar para Aprovação" é uma funcionalidade, não um defeito.

4. Audite o Operador: Registre quem disparou o ambiente e por quê. Use o contexto do workflow para marcar recursos com o User_ID do solicitante.

5. Trate Operações como Código: Faça controle de versão dos seus workflows operacionais assim como faz com o código da sua aplicação. Use a integração git da SchemaBridge para revisar mudanças na sua lógica de deploy.

Conclusão: A Nuvem É uma Máquina de Estados

Sua infraestrutura não é uma pilha estática de servidores; é um componente vivo e pulsante do seu negócio. Ao tratá-la como uma máquina de estados, você pode automatizar as danças operacionais complexas e de múltiplos passos que atualmente consomem a vida da sua equipe de SRE. Você pode passar de "Operações Baseadas em Ticket" para "Operações Self-Service", com segurança e durabilidade incorporadas.

Na Parte 12, veremos o "Mito do Cold Start" e como alcançar latência sub-milissegundo em uma arquitetura de eventos serverless sem manter servidores aquecidos.

Explorar