Infrastructure as Data (IaaD): A Evolução do IaC?

Você conhece o conceito de Infrastructure as Data (IaaD)?

Se você tem mais de dez anos de experiência em TI ou está aprendendo como as infraestruturas mais recentes funcionam, provavelmente já usou o formato de dados que ele propõe. Mas o que diferencia o IaaD do nosso conhecido Infrastructure as Code (IaC)?

A proposta do IaaD é uma nova maneira de criar e gerenciar a infraestrutura, descrevendo uma abordagem onde a configuração e o estado desejado da infraestrutura são tratados primariamente como dados, e não como código de aplicação tradicional.

Nota: Embora o nome do blog seja infraascode.com.br, é fundamental entender que o IaaD pode ser visto como uma filosofia mais restrita e poderosa dentro do domínio do IaC, buscando resolver algumas de suas complexidades. É uma abordagem que vale muito a pena conhecer!

O Conceito IaaD: Separação de Lógica e Descrição

Para criar uma infraestrutura por meio do modelo IaaD, é preciso descrever o ambiente utilizando formatos de dados estruturados, como YAML e JSON.

O que realmente difere o IaaD do IaC tradicional é o foco: a principal ideia é descrever o estado final da infraestrutura (o “o quê”) em um formato de dados simples, legível e puramente declarativo.

A complexidade e a lógica do provisionamento não estão no seu arquivo de descrição. Em vez disso, um sistema de provisionamento (o engine ou controller) fica inteiramente responsável por:

1. Descobrir as etapas necessárias para atingir esse estado.
2. Monitorar ativamente a infraestrutura.
3. Garantir que o estado real sempre corresponda ao estado desejado (o que chamamos de reconciliação).

Esse modelo propõe uma separação clara entre o que é a descrição da infraestrutura (os dados) e a lógica para provisioná-la (o mecanismo de provisionamento).

O objetivo é minimizar o débito técnico e a complexidade que surgem ao tratar a infraestrutura como um software complexo com Domain-Specific Languages (DSLs). A descrição em formato de dados tende a ser mais simples e focada no resultado, facilitando o versionamento e a rastreabilidade.

IaaD vs. IaC: Onde a Lógica Mora?

O Infrastructure as Code (IaC) é o conceito mais estabelecido, onde usamos práticas de desenvolvimento de software (controle de versão, testes, CI/CD) para gerenciar a infraestrutura. O problema surge quando o IaC evolui para um “DSL Complexo” cheio de loops, condicionais e lógica embutida, transformando seus arquivos de infraestrutura em código de software difícil de manter.

O IaaD é uma filosofia que argumenta que a lógica complexa de provisionamento deve ser abstraída e gerenciada por um engine dedicado.

Comparando as duas abordagens utilizando um exemplo prático criação de um buck S3:

Infrastructure as Code (IaC) - Exemplo: Terraform

No IaC com Terraform, você utiliza o HashiCorp Configuration Language (HCL). Embora seja declarativo, o HCL é uma linguagem de domínio específico que combina a descrição do recurso com um certo nível de lógica:

• Linguagem Dedicada: Você escreve em uma linguagem com suas próprias regras de sintaxe, blocos e expressões.
• Lógica no Código de Infraestrutura: Se precisar de lógica complexa (como criar múltiplos recursos com base em uma lista, ou condicionais), você a embutirá no HCL (com for_each, count, ou expressões if/else).
• O “Código” é a Infraestrutura.

1resource "aws_s3_bucket" "meu_bucket" {
2  bucket = "meu-projeto-iac-bucket-s3"
3  acl    = "private"
4
5  tags = {
6    Nome     = "BucketIaC"
7    Ambiente = "Dev"
8  }
9}

Infrastructure as Data (IaaD) - Exemplo: Crossplane

No IaaD com Crossplane (que se integra ao ecossistema Kubernetes), você não está escrevendo um DSL de infraestrutura, mas sim um arquivo de dados estruturados (YAML) que se conforma ao esquema de uma API do Kubernetes (CRD).

• Definição como Data: Você preenche um objeto de dados (YAML) em um formato API padrão.
• Lógica Separada (no Engine): A lógica complexa (como gerenciar dependências, retry failures, e reconciliar continuamente o estado) é totalmente encapsulada e gerenciada pelo Controller (o “engine” do Crossplane), que é um software rodando em segundo plano.
• O “Data” Descreve a Infraestrutura.

 1apiVersion: s3.aws.crossplane.io/v1beta1
 2kind: Bucket
 3metadata:
 4  name: meu-projeto-iaad-bucket
 5spec:
 6  forProvider:
 7    region: us-east-1
 8    acl: private
 9    tags:
10      - key: Nome
11        value: BucketIaaD
12      - key: Ambiente
13        value: Dev

Comparativo Detalhado

O ponto chave é onde a lógica reside e como o drift de ambiente é gerenciado:

Característica	IaC - Terraform	IaaD - Crossplane
Foco Principal	Descrição do Estado + Lógica de Provisionamento	Descrição puramente de Dados (Estado Final)
Linguagem	DSL dedicado (HCL, Python/CDK, JSON/ARM)	Formato de dados estruturados (YAML/JSON)
Lógica	Embutida no código de infraestrutura (loops, condicionais)	Totalmente abstraída e gerenciada pelo Engine/Controller
Gerenciamento de Drift	Execução pontual (apply no CI/CD). Requer monitoramento externo.	Reconciliação Contínua (Controller ativo). O sistema repara o drift automaticamente.
Aplicações	Provisionamento inicial, gerenciamento de recursos complexos.	Gerenciamento de estado contínuo, Plataformas de Nuvem Interna (ICPs).

---

Conclusão

IaC é o termo mais antigo e abrangente, englobando quase todas as práticas modernas de provisionamento em nuvem. Ele oferece grande flexibilidade para criar lógica complexa e extensível, mas impõe o custo de gerenciar essa complexidade de código. IaaD é uma filosofia poderosa dentro do IaC. É uma abordagem mais simples e restritiva que argumenta que a lógica de provisionamento deve ser movida para um mecanismo que interpreta os dados, mantendo as definições de infraestrutura como dados simples e legíveis.

Em resumo, enquanto o IaC é sobre gerenciar a infraestrutura com código, o IaaD sugere que a melhor forma de código para infraestrutura é a sua descrição pura em formato de dados, delegando a complexidade do como para um engine dedicado. Acho que vale a pena ficar de olho nisso.

Abraços!

Vida longa e próspera a todos!!

Referências

• https://developer.hashicorp.com/terraform/docs
• https://aws.amazon.com/pt/cloudformation/
• https://docs.aws.amazon.com/pt_br/cloudformation/
• https://docs.crossplane.io/
• https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/

Entre em contato:

NewsLetter - https://engineeringmanager.com.br/
Linkdin - linkedin.com/in/leonardoml/
Twitter: @infraascode_br

Te convido a ver os outros posts do blog Infra-as-Code garanto que tem coisas legais lá!!

--- --- IMPORTANTE --- --- As opiniões aqui expressas são pessoais e de responsabilidade única e exclusiva do autor, elas não refletem necessariamente a posição das empresas que eu trabalho(ei) e/ou presto(ei) serviço.