Reestruturação modular de uma infra Terraform multi-cloud
+30módulos Terraform consolidados
A infra Terraform de uma plataforma de IA em produção tinha-se tornado um bloco monolítico, pesado de fazer evoluir.
Reparti-a em módulos reutilizáveis e portei eu próprio uma dúzia de componentes — Kubernetes, VPC, bases de dados, observabilidade — para AWS, GCP e Scaleway.
Cada peça evolui agora por si, sem arriscar partir outra.
A segurança vem nos mesmos módulos que o resto: rede privada, papéis IAM dedicados e direitos no mínimo necessário para cada ambiente, em vez de uma camada acrescentada no fim.
O caminho de destruição é distinto do de criação e volta a passar pelo plano de controlo: nada desaparece por efeito secundário.
Reestruturar uma infra crítica mete medo enquanto não se puder provar que nada se mexe.
Contribuí para um script — Bash e pipeline Jenkins — que compara o plano Terraform de dois ramos, com diff dos resource_changes fase a fase e escolha do ambiente na altura.
O suficiente para validar uma migração sem a implantar às cegas.
Testar o mais perto possível da produção exigia dados realistas, sem nunca expor dados de clientes.
Escrevi um script — Docker e Bash — que copia a base RDS de produção para os ambientes de teste, anonimizando-a pelo caminho; infraestrutura provisionada em Terraform com papéis IAM restritos, executada através de GitHub Actions.
Os ambientes de teste refletem fielmente a produção, o que torna os bugs reproduzíveis — sem risco para a confidencialidade.
As notas de versão eram escritas à mão e a equipa de produto só sabia das entregas tarde.
Em cada merge para main, um pipeline Jenkins lê o histórico Git, gera o changelog, atualiza a página de release pela API do Notion e notifica o canal Slack de produto.
Ninguém precisa de pensar nisso, e toda a gente sabe o que foi para produção.
Os acessos às bases RDS tinham de ser controlados e registados, sem deixar permissões permanentes abertas.
Construí um sistema de aprovação dinâmica via Slack, assente em AWS SSM, Lambda, CloudTrail e EventBridge, com ligações protegidas por túneis SSH/VPN e autenticação SSO.
Cada pedido é aprovado, vigiado em tempo real por CloudWatch e New Relic, e deixa um registo completo.
Diagnosticar um incidente obrigava a saltar de ferramenta em ferramenta.
Centralizei as métricas — recolhidas pelo Prometheus, visualizadas no Grafana — e os logs no OpenObserve, com alertas Slack contextualizados que remetem diretamente para o runbook em causa.
O estado das instâncias lê-se em tempo real e chega-se à causa muito mais depressa.
StackPrometheus · Grafana · OpenObserve · Slack
Monitorização full-stack com New Relic
Pouca visibilidade em tempo real sobre a saúde da infra AWS e das aplicações.
Integrei o New Relic de ponta a ponta: agente de infraestrutura em ECS, APM em EC2, Browser agent no front-end, ligado aos serviços AWS — RDS, ECS — por API.
Dashboards e alertas em tempo real sobre CPU, memória e desempenho das bases, enviados para o Slack, para detetar e tratar incidentes mais depressa.
Ninguém sabia bem de onde vinha a fatura da cloud.
Construí um painel que consulta o AWS Cost Explorer, agrega os dados em Python e apresenta-os no Grafana, com alertas quando o consumo por serviço ou por equipa descarrila.
Serviu sobretudo para desencantar recursos órfãos e snapshots esquecidos que pagávamos sem saber.
StackAWS Cost Explorer · Python · Grafana
Open source · GitHub
Projetos open source
Projetos pessoais de código público, do FinOps aos agentes de IA.
wasteless.io
O meu projeto de referência em FinOps, open source e auto-alojado: tornar o desperdício AWS visível antes de chegar à fatura.
Nove famílias de detetores — EC2 e RDS inativos, volumes EBS órfãos, IP elásticos, snapshots e AMI esquecidos, load balancers, gateways NAT e VPC sem uso, gp2 a migrar para gp3. Cada recomendação traz a sua prova, um índice de confiança e um custo mensal estimado.
Seguro por construção: a recolha passa por um papel IAM só de leitura, qualquer escrita exige um segundo papel opcional e falha sem ele, e o modo de simulação está ativo por omissão.
Ciclo fechado: três caminhos de execução — ação AWS direta, pull request Terraform ou tarefa manual — e depois verificação. Um acompanhamento no Cost Explorer confirma a poupança real passados sete dias de faturação.
Organizar uma caixa de correio à mão é repetitivo e consome tempo.
Cinco agentes Python, orquestrados atrás de uma API FastAPI, passam o testemunho na caixa Gmail: leitura e classificação das mensagens, redação de uma resposta, aprovação antes do envio.
Um campo de ensaio para orquestrar vários agentes à volta de uma tarefa concreta.
StackPython · FastAPI · Gmail API · React · Docker