A evolução do provisionamento de infraestrutura veio de longe. Começou com a instalação física de hardware. Depois, com a virtualização, virou questão de alguns cliques numa interface. Em seguida, os provedores de nuvem passaram a oferecer APIs REST para provisionar serviços. Hoje, dá para definir de forma declarativa o estado final de um ambiente usando código. Foi assim que a infraestrutura como código se consolidou. Alguns exemplos são o Terraform, o Cloudformation, os ARM templates etc.
A questão da infraestrutura como código
Infraestrutura como código é ótima para reprodutibilidade. Reduz erros humanos e aumenta a imutabilidade. De quebra, ainda funciona como documentação. O Terraform permite provisionar e alterar a infraestrutura de forma incremental e armazena o estado de execução depois de cada rodada. Mas, quando colocada para valer num ambiente corporativo, essa abordagem começa a mostrar suas limitações.
Para começar, é difícil acrescentar qualquer inteligência na forma de instruções if. Com o tempo, a linguagem HCL do Terraform passou a oferecer suporte a instruções if e laços for, mas esses recursos parecem mais um remendo do que cidadãos de primeira classe da HCL. Os frameworks de infraestrutura como código também não têm recursos nativos de teste. HCL, Cloudformation e os templates do Azure Resource Manager têm, cada um, sua própria curva de aprendizado. E ainda prendem você aos respectivos ecossistemas.
O Pulumi é um meio-termo feliz
No outro extremo do espectro, existem SDKs de nuvem para várias linguagens de programação populares. Todos os grandes provedores de nuvem oferecem esses SDKs, chamados de CDKs, sigla para cloud development kit. Os CDKs são fantásticos porque trazem todos os benefícios de uma linguagem de programação; só que não têm o conceito de gerenciamento de estado como o Terraform tem. O gerenciamento de estado é o que torna as mudanças incrementais na infraestrutura previsíveis e fáceis de administrar.
É aí que entra o Pulumi, reunindo o melhor dos dois mundos. Ele oferece tanto uma linguagem de programação completa quanto gerenciamento de estado.
Por exemplo, um código JavaScript puro com várias condições if fica assim:
switch (ostype){
case 'linux':
Userdata = userdata
break;
case 'windows':
Userdata = windowsuserdata
break;
}
A mesma lógica expressa na HCL do Terraform fica assim:
Linux = var.ostype == "linux" ? true : false
Windows = var.ostype == "windows" ? true : false
Como você pode notar, a legibilidade fica muito melhor com a notação conhecida do JavaScript do que com a HCL da Hashicorp. A HCL é uma linguagem de domínio específico, sem a flexibilidade de uma linguagem de propósito geral. Por isso, dá para incorporar mais inteligência à infraestrutura como código quando se usa uma linguagem de propósito geral.
O Pulumi traz junto outros benefícios do ciclo de desenvolvimento de software: desenvolvimento orientado a testes, integração contínua, releases versionados, gerenciamento de pacotes etc.
Agora, o software da aplicação e o software da infraestrutura podem conviver lado a lado. Um repositório git pode hospedar os dois, escritos na mesma linguagem de programação.
Conceitos do Pulumi
O Terraform tem conceitos como provider, módulo, estado etc. Da mesma forma, o Pulumi reimaginou e simplificou esses conceitos:
Stacks:
Stacks são conjuntos de recursos de infraestrutura relacionados que compartilham as mesmas variáveis de ambiente. Funcionam como ambientes (dev, stage, prod), e cada stack tem seu próprio conjunto de variáveis. Essas variáveis são definidas exclusivamente em "Pulumi.dev.yaml", "Pulumi.stage.yaml" etc.
Projects:
Um Project é um agrupamento logicamente isolado de recursos de infraestrutura que engloba stacks. Os Projects podem ser mapeados por times, iniciativas ou tipos de infraestrutura (contêineres, serverless, redes etc.). Há espaço para interpretar qual tipo de agrupamento faz mais sentido para cada organização.
Backends:
Os backends armazenam o estado de execução do Pulumi em um sistema de armazenamento persistente. Eles podem ser de vários tipos:
1. Service backends: Pulumi cloud (SaaS) ou Pulumi auto-hospedado. Os service backends têm a vantagem de manter snapshots da infraestrutura em intervalos regulares, o que facilita o rollback e a recuperação de erros fatais durante o provisionamento.
2. Armazenamento de objetos autogerenciado (AWS S3, GCP GCS, Azure blobs etc.).
Providers
O Pulumi consegue provisionar infraestrutura e serviços em várias plataformas. Hoje, conta com providers para AWS, GCP, Azure, Kubernetes, Cloudflare e muitos outros.
Apêndice
Tabela comparativa
Em breve
A parte 2 deste artigo vai explorar recursos avançados do Pulumi que permitem a times autônomos provisionar e manter a própria infraestrutura junto com a aplicação. Também vamos analisar um codebase capaz de provisionar clusters EKS na AWS — clusters EKS que vão além do "hello world" e já vêm com uma boa dose de hardening e prontidão para produção. Fique ligado!
Para acompanhar nossos conteúdos, siga o DoiT Engineering Blog, o canal da DoiT no LinkedIn e o canal da DoiT no Twitter. Para conhecer as oportunidades de carreira, acesse https://careers.doit-intl.com.
Pode não haver grande paridade quando se entra nos detalhes técnicos da semântica entre a HCL e uma linguagem de propósito geral. Mas, quando a escolha é entre uma linguagem de programação de propósito geral madura e amplamente conhecida e uma linguagem declarativa de domínio específico, proprietária e novíssima, para chegar ao mesmo resultado — por que optar pela menos conhecida? Tanto a HCL quanto uma linguagem de propósito geral dão conta do recado. Mas, considerando os ecossistemas consolidados em torno das linguagens de propósito geral e o talento disponível no mercado, faz mais sentido usar um framework como o Pulumi em vez do Terraform.