Pulumi: infraestrutura como código com linguagens de programação reais

O que é Pulumi e como difere do Terraform

IaC com linguagens de programação completas

Pulumi é uma plataforma de Infrastructure as Code que permite usar TypeScript, JavaScript, Python, C#, Go e Java em vez de uma DSL própria como HCL. Isso significa que você usa loops, condicionais, funções, classes, abstrações e toda a expressividade de uma linguagem de programação real para descrever infraestrutura. O modelo de execução do Pulumi é similar ao Terraform: registra recursos em um grafo de dependências, calcula o diff em relação ao estado atual e aplica as mudanças. A diferença fundamental é que o programa Pulumi é código real que o runtime executa, e os recursos declarados durante a execução formam o "plan" implícito. Isso torna o Pulumi especialmente poderoso para infraestrutura dinâmica e altamente parametrizável.

Stacks — ambientes no Pulumi

Isolamento de estado por ambiente ou contexto

No Pulumi, Stacks são instâncias independentes do mesmo programa de infraestrutura — análogas aos workspaces do Terraform, mas com maior flexibilidade de configuração. Um stack dev aponta para uma conta AWS de desenvolvimento com instâncias menores; o stack prod aponta para produção com instâncias maiores e réplicas habilitadas. Cada stack tem seu próprio state file armazenado no Pulumi Cloud, S3 ou outro backend. Stacks podem referenciar outputs de outros stacks via StackReference — o stack de aplicação lê o VPC ID criado pelo stack de rede. A configuração por stack é gerenciada com pulumi config set, permitindo que o mesmo código se comporte diferentemente em cada ambiente sem condicionais no código.

Usando TypeScript para infraestrutura

O poder de uma linguagem real aplicado à infra

TypeScript é a linguagem mais popular no ecossistema Pulumi. Um programa TypeScript para infraestrutura importa o SDK do provider (@pulumi/aws, @pulumi/kubernetes) e instancia recursos como objetos. const bucket = new aws.s3.Bucket("meu-bucket", { versioning: { enabled: true } }) cria um bucket S3 com versionamento. O tipo de retorno é um objeto Pulumi Resource com Outputs — valores tipados que representam atributos do recurso após a criação (bucket.id, bucket.bucketDomainName). Outputs são wrappers assíncronos: você os usa com pulumi.interpolate ou .apply() para derivar novos valores. O TypeScript fornece autocomplete, type checking e refatoração automática — vantagens impossíveis com HCL.

Resources e providers no Pulumi

O ecossistema de providers do Pulumi

O Pulumi tem providers para praticamente todos os serviços cloud, gerados automaticamente a partir dos schemas dos Terraform providers via Pulumi Terraform Bridge. Isso significa que qualquer resource disponível no Terraform também está disponível no Pulumi, com a mesma semântica mas com a API da linguagem de programação escolhida. Além dos providers cloud padrão (AWS, GCP, Azure, Kubernetes), há providers para SaaS como Datadog, Cloudflare, MongoDB Atlas e GitHub. Custom Resources permitem criar providers próprios para APIs internas. O Pulumi Automation API permite que programas Pulumi sejam incorporados em aplicações TypeScript ou Python, criando plataformas de self-service de infraestrutura onde desenvolvedores provisionam recursos via API HTTP sem escrever código Pulumi diretamente.

State e backends do Pulumi

Onde e como o Pulumi rastreia a infraestrutura criada

O Pulumi armazena state em backends configuráveis: Pulumi Cloud (padrão, gerenciado), S3, GCS, Azure Blob ou filesystem local. O Pulumi Cloud adiciona funcionalidades de colaboração — histórico de updates, diff visual, concurrency control e secrets encryption gerenciada. Para backends de objeto (S3, GCS), o locking é implementado via locks no próprio objeto, sem necessidade de DynamoDB externo como no Terraform. O state do Pulumi é estruturado de forma mais granular que o Terraform, rastreando cada propriedade de cada recurso. Secrets no state são criptografados automaticamente pelo Pulumi Cloud ou via passphrase/KMS quando usando backends alternativos, resolvendo por padrão o problema de valores sensíveis no state file.

Componentes reutilizáveis com classes e funções

Abstrações de alto nível para infraestrutura complexa

ComponentResource é a abstração do Pulumi para criar componentes reutilizáveis que agrupam múltiplos recursos em uma unidade lógica. Uma classe WebApplication extends ComponentResource pode encapsular um ALB, um ECS service, um target group, IAM roles e security groups, expondo apenas os inputs relevantes (imagem Docker, porta, número de réplicas). Isso é radicalmente mais expressivo que módulos HCL: herança, composição, geração de recursos em loops tipados, validação de inputs com TypeScript e testes unitários com mocks. O Pulumi Registry hospeda componentes prontos da comunidade. Componentes internos são publicados como pacotes npm, pip ou NuGet para reutilização entre times.

Pulumi vs Terraform — quando escolher cada um

Trade-offs reais entre as duas abordagens

Terraform é melhor quando o time tem expertise consolidada em HCL, quando a infraestrutura é relativamente estática e bem definida, e quando a integração com o ecossistema Terraform (Atlantis, Spacelift, Terraform Cloud) já está estabelecida. Pulumi é melhor quando a infraestrutura é altamente dinâmica ou parametrizável, quando o time já domina TypeScript, Python ou C# e quer aplicar abstrações de programação reais, ou quando a Automation API é necessária para criar plataformas de self-service. Migrar de Terraform para Pulumi é possível via pulumi convert que transpila HCL para a linguagem Pulumi de destino. Para projetos novos com times de engenharia proficientes em programação, Pulumi reduz significativamente o boilerplate de infraestrutura complexa.

Testing de infraestrutura no Pulumi

Testes unitários e de integração nativos

O Pulumi oferece três camadas de teste. Testes unitários usam mocks do SDK para simular recursos sem provisionar nada, verificando que o código gera os recursos e configurações esperados — ideal para validar lógica de negócio como naming conventions e tags obrigatórias. Policy as Code com CrossGuard define regras que o programa deve satisfazer antes do deploy — por exemplo, toda instância EC2 deve ter tag de custo, nenhum bucket S3 pode ser público. Testes de integração com pulumi up em ambiente efêmero criam infra real, executam assertions (o endpoint responde? o banco aceita conexão?) e destroem tudo com pulumi destroy. Essa progressão de testes dá confiança crescente sem precisar criar infra real para cada mudança.

Pulumi Cloud e automação

Plataforma completa para times de engenharia

Pulumi Cloud é o SaaS que adiciona colaboração, governança e automação ao Pulumi open-source. Deployments integra com GitHub, GitLab e Bitbucket para executar pulumi preview em PRs e pulumi up após merge, com logs, diff visual e histórico completo de cada stack. Escaping Slinky — o recurso de drift detection do Pulumi Cloud — compara periodicamente o estado no backend com a infraestrutura real e alerta sobre divergências. Organizações podem definir políticas de acesso por stack, exigindo aprovação de engenheiros sênior para mudanças em produção. Para times que migram do Terraform Cloud, o Pulumi Cloud oferece experiência equivalente com a vantagem das linguagens de programação reais como base.

Conclusão

Pulumi como evolução natural de IaC para times de desenvolvimento

Continue em: Fundamentos obrigatórios antes de produção.