Quando a infraestrutura existe só no painel do provedor, ninguém sabe explicar por que ela está assim.
Descrevemos o ambiente em código: replicável, versionado e auditável. Recriar a infraestrutura deixa de ser um exercício de memória e passa a ser um comando.
O que muda com IaC
O ambiente passa a ter uma descrição, e ela é a verdade.
Se está em código, dá para revisar antes de aplicar, reproduzir em outro lugar e saber exatamente o que mudou e quando.
Reproduzir no lugar de lembrar
Um ambiente novo nasce igual ao anterior, sem depender de quem configurou o original estar disponível.
Mudança revisada antes de aplicar
A alteração passa por revisão como qualquer código, sem ser aplicada direto no painel.
Custo com dono
Recurso etiquetado por ambiente e por área, o que torna possível saber quem gasta o quê.
O que a auditoria encontra
A nuvem foi montada clicando, e cada clique foi uma decisão que ninguém registrou.
Ambiente criado à mão funciona até precisar ser reproduzido, auditado ou corrigido às pressas. Aí a falta de registro vira o problema principal.
Homologação e produção deveriam ser iguais, mas ninguém garante isso, então erro em produção aparece sem aviso.
Existem recursos rodando que ninguém sabe para que servem, e ninguém se arrisca a desligar.
Uma permissão foi aberta para resolver um problema urgente há meses e continua aberta até hoje.
O que entra no provisionamento
Da descrição do que já existe até o ambiente que nasce pronto, com governança e segurança definidas na origem.
Infraestrutura descrita em código
Rede, servidores, banco, permissões e serviços gerenciados definidos em arquivos versionados, revisáveis e aplicáveis de forma previsível.
Ambientes que nascem iguais
Desenvolvimento, homologação e produção a partir da mesma descrição, com as diferenças declaradas e não acidentais.
Permissão mínima por padrão
Acesso definido por função, com o mínimo necessário, e credencial guardada em cofre em vez de circular por mensagem.
Governança e etiquetagem
Recursos identificados por ambiente, área e finalidade, o que torna possível atribuir custo e encontrar o que ficou órfão.
Quando faz sentido conversar
O ganho aparece quando o ambiente já é grande o bastante para ninguém guardar inteiro na cabeça.
Aplicação pequena com um servidor e pouca mudança não precisa disso. O IaC compensa quando há mais de um ambiente, mais de uma pessoa mexendo ou exigência de auditoria.
Existe mais de um ambiente e não há garantia de que sejam equivalentes.
Recriar a infraestrutura hoje dependeria da memória de uma pessoa específica.
Há recursos rodando que ninguém sabe explicar, e ninguém se arrisca a desligar.
A empresa precisa demonstrar controle de acesso e de mudança para cliente ou auditoria.
Como conduzimos um projeto de provisionamento
Ninguém reconstrói a nuvem do zero com a operação rodando. O caminho é trazer o que existe para código, aos poucos.
ETAPA 01
Imersão
Levantamos o que está rodando hoje, quanto custa, quem tem acesso e quais recursos ninguém consegue justificar.
ETAPA 02
Engenharia
Definimos a estrutura alvo: separação de ambientes, padrão de identificação, modelo de permissão e o que entra primeiro em código.
ETAPA 03
Construção
Trazemos o ambiente para código por etapas, começando pelo que muda mais e sem interromper o que está no ar.
ETAPA 04
Homologação
Validamos recriando o ambiente a partir da descrição, que é a única prova real de que o código representa a infraestrutura.
ETAPA 05
Gestão e Sustentação
O ambiente passa a ter gestão mensal: permissão revisada, recurso sem uso removido e mudança de infraestrutura aplicada sob processo.
O que muda quando a infraestrutura vira código
Ambiente que se recria em horas
Seja para criar homologação, seja para se recuperar de um incidente grave, reconstruir deixa de ser um projeto.
Mudança revisada antes de chegar em produção
Alteração de infraestrutura passa a ter o mesmo cuidado que alteração de código, o que reduz a classe de erro mais cara.
Custo com dono identificado
Com recurso etiquetado, a conta deixa de ser um número único e vira informação acionável por ambiente e por área.
Dúvidas mais comuns
O que perguntam antes de começar
“Vai parar a operação para migrar?”
Não. O caminho é descrever o que já existe e ir assumindo por etapas. Parar a operação para reescrever infraestrutura raramente se justifica.
“Preciso trocar de provedor?”
Não. O trabalho é sobre como o ambiente é gerenciado, não sobre onde ele roda. Se houver motivo para migrar, isso é outra conversa.
“Meu time vai conseguir mexer depois?”
Essa é a régua da entrega. Código de infraestrutura só compensa se o time interno conseguir ler e alterar, então documentação e transferência fazem parte.
“Minha infraestrutura é pequena. Compensa?”
Nem sempre. Com um servidor e pouca mudança, o esforço pode não se pagar. Dizemos isso quando for o caso.
“E os acessos que já estão abertos?”
Aparecem no levantamento, e quase sempre são a parte mais reveladora dele. Revisar permissão acumulada é um dos ganhos rápidos do projeto.
“Isso é o mesmo que DevOps?”
É a base dele. Provisionamento cuida de como o ambiente existe; DevOps cuida de como o código chega até ele. As duas frentes se apoiam.
Próximo passo
Se recriar a infraestrutura hoje dependeria da memória de alguém, esse é o risco que a auditoria mede primeiro.
O levantamento mapeia o que está rodando, quanto custa, quem acessa e o que pode ser desligado sem quebrar nada.
- Inventário do que está rodando e do custo atual
- Revisão de acessos e de recursos sem justificativa
- Plano de adoção de código por etapas, sem parar a operação